The Fall Product Mentorship Program is Open! Mentors and Mentees apply by Sept 24!
Twenty years ago, Sejal Parikh didn't know product management existed. Today she's building the infrastructure that lets AI agents talk to enterprise software.
In between: telecom engineering, software testing, four years out of the workforce, a pivot into technical writing, and a PM role she landed by raising her hand when the opportunity arose.
Sejal is now Group Product Manager for MCP and APIs at HubSpot, one of the most consequential product areas in enterprise tech right now. In this edition of Product Star Spotlight, she talks about what an unconventional path actually gives you, why curiosity is the only framework that's followed her across every role, and what it looks like to build products at the exact moment the industry is being rewired.
—---------------------------
The latest is that I've recently moved from Staff PM to Group Product Manager, which also means I've moved into people management. But yes, it's been a very unconventional path. I never thought I'd be a product manager one day; I didn't even know what product management was when I started my career. I don't think many people did, twenty years back.
I started out in telecom engineering, then moved into software testing, also in the telecom domain. Around that time I got interested in human rights and started volunteering a lot, eventually deciding to try it full-time through a fellowship. I joined a traveling fellowship in India, working with rural NGOs and volunteer organizations for about two years.
At some point I realized I was missing my regular work and that this wasn't something I wanted to do full-time. I decided to go part-time and head back to work, that was when I got pregnant with my baby, which delayed things further. My planned two-year break became four years, and I couldn't go back to telecom because the industry moves so fast; landlines became smartphones, and so much of the learning there happens on the job, with no formal courses to catch up through.
It was hard to re-enter after a break in India, so I moved into technical writing and communication instead. I started at Oracle, where I began building internal tracking tools and applications, effectively becoming an application developer. From there I moved to Salesforce and applied for a product management role, though I actually joined Salesforce as a technical writer first. Within the first three months, I was able to move into product management through an internal transfer, and I've been a PM ever since, about eight years now. I spent four years at Salesforce, then moved to HubSpot.
Throughout, I've stayed in highly technical product areas that require an understanding of code, with technical audiences. Now I work on connecting AI agents to HubSpot through MCP, APIs, and CLI.
At Salesforce, I was asking too many questions about API design and tooling. I was responsible for documenting APIs and the best practices and systems around them, and I kept pushing on deeper questions — about the experience side, the tooling side, customers' problems.
A position opened up, and the hiring manager told the recruiter, "I want to hire someone like Sejal." The recruiter reached out and asked if I had friends like myself, and I said, "Can I apply?" She said yes. That's when I thought, okay, I'm genuinely interested in this, I hadn't done product management before, but I was leaning toward that area and decided to try. It really was accidental — sheer chance that the hiring manager reached out and I came to know about the opportunity.
Communication! the right level of communication with customers. Until MCP and the AI Connector work came along, most of my products at HubSpot were built for developers, and the only way developers discover your features is through documentation. That's the front door for discovery, there's no UI to speak of; documentation is the end-to-end discovery mechanism. So that's been an enormously important part of the job. I still write a lot as a PM; dev docs, external-facing content and technical writing continues to be part of what I do.
Coincidentally, all three companies have worked on CRMs in different capacities — even Oracle has a CRM product, same as Salesforce.
At Oracle, I spent a lot of time tinkering with internal tools, so I had less customer-facing work except during my time as a technical writer. But it was my first SaaS company, so I learned a lot about what it means to work in SaaS; the different functions, how products actually get built. Before that I'd only worked at services companies or telecom operators, so it was all new to me.
Salesforce was the first company where I worked as a PM, so that's really where I learned product management. Salesforce invests heavily in training, really top-notch programs, including strong leadership training — so I got to learn the discipline properly, and the processes of a large company, while constantly meeting and learning from new people.
HubSpot has been different again, it's the smallest company I've worked at, even though it's still about 9,000 people, and it moves incredibly fast. HubSpot ships every day, you can ship anytime you're ready, which sets a pace that pushes you to actually ship and innovate faster. It's a different way of building products, and the learning curve is steeper because you're moving in such a fast-paced environment.
People assume it's a completely different job, but in both cases you're ultimately building for customers. The difference is how far from them you're sitting. With direct, UI-facing products, you get a lot more signal, you can see exactly how people are using the product and where the friction is. With developer products, there's a layer in between, you're one step removed. My team builds the platform itself: the APIs, the UI extensions, now MCP — the tools developers use to extend HubSpot. Developers use those tools to build apps, and those apps go to HubSpot's customers. So the developers are effectively our partners, and the person running their business on that app is using what the developer built, not what I built directly.
That means you go through developers to get to customer feedback, which is challenging — those partners often become the voice of your customer unless you're intentional about going around them to interview the end users of their apps directly. It can be hard to get a clear read on what's really happening.
On the other hand, developers are always fun to work with because they're passionate and inventive, give them anything and they'll find a way to push it further than you ever expected. That itself is useful feedback: if they're working that hard to build something difficult, it tells you where you need to make things easier. And because your engineers understand these users so well, sometimes better than you do, it takes some of the pressure off as a PM. You don't always have to go find problems for them to solve; they bring problems to you.
I won't comment on specific mistakes other companies make, but generally, I think the common mistake in this space is making platforms too restrictive. There's a real difference between a guardrail and a guideline, and sometimes we lean too far toward blocking and restricting — often for the right reasons, like security. But if you restrict developers too much, you never really find out what possibilities you're missing for your own product. You only learn the true potential of a platform by keeping it more open. That openness is something I've learned to value along the way.
It's funny — it's only been about a year, and already people don't need much of an introduction to MCP. That wasn't the case with APIs; it took a long time for people to understand what an API even was.
When we first built MCP for HubSpot, I actually ran an internal proof of concept myself, this was before Claude Code existed, I used Cursor at the time. I built a small POC with just one tool to show what was possible with an MCP server, to evangelize it internally, and we shipped an alpha within about ten to fifteen days. Around then I was still explaining to customers and internal audiences what MCP actually was. Thankfully, our founder, Dharmesh Shah, did a great job explaining it broadly, which made things easier and I think his framing has become pretty common across the industry now: MCP is like a USB-C port. You can connect any system to any system.
You could always build these connections through APIs — the APIs were always there, and they still are. MCP sits on top of them. But with APIs alone, every company wanting to connect, say, HubSpot to Claude had to build that integration themselves. It's the world before USB-C; a different proprietary cable for every pair of devices, and someone had to make each one. With MCP, the onus shifts; if a company exposes a USB-C port, you just plug your agent in instead of building the cable yourself.
From a product manager's standpoint, AI changes a lot of the routine, mundane tasks. The biggest thing I use it for is customer sentiment; pulling together feedback and signals from hundreds of different sources and making sense of it, then turning that into something more prioritized and actionable.
I use it constantly to understand what's happening in my product area, where the gaps are, where the strong signals are, and where we need to invest. It even helps with figuring out what to build; a lot of the technical details you can work through with something like Claude Code before you ever knock on your engineers' door. You can get a first pass on whether an idea is even technically feasible, or whether you're talking sense or it's all garbage. It's been genuinely helpful, like having an engineering thought partner.
I've gotten stuck on this myself in the past. Yes, it helps to have someone advocate for you, I'd say the bigger skill is not waiting for anyone else to do that, but learning how to advocate for yourself. Even wanting to move to the next level often comes down to whether people know your impact — business impact, customer impact — and whether you can talk about it clearly and back it up with evidence, and make sure people actually hear about it.
Part of that is making your manager your champion. If you equip them with the right context, they're much better positioned to advocate for you. I think we sometimes expect too much from a manager and end up disappointed, but a lot of that responsibility is actually on us to give them what they need so they can champion you effectively.
What worked for me might not work for everyone, but I'd say: show curiosity, and ask the right questions, get curious about the "why" behind things and really try to understand it. If a decision is handed to you and you don't understand it, keep asking “why”, especially from the customer or user's point of view. The more you become the voice of the end user in these conversations, and keep asking why from their perspective, the further it takes you. That's certainly where it took me in my own PM journey.
Again, being curious is the biggest one for me. Just staying curious has helped me at every step, in every role.
—---------------------------
Mentorship program and in-person event experiences are at an extra cost.
Join for free!Join the TPMA Slack Community with 1000+ members
Free Virtual TPMA events for the entire TPMA Season
Become the first to know about in-person events and networking opportunities
Twenty years ago, Sejal Parikh didn't know product management existed. Today she's building the infrastructure that lets AI agents talk to enterprise software.
In between: telecom engineering, software testing, four years out of the workforce, a pivot into technical writing, and a PM role she landed by raising her hand when the opportunity arose.
Sejal is now Group Product Manager for MCP and APIs at HubSpot, one of the most consequential product areas in enterprise tech right now. In this edition of Product Star Spotlight, she talks about what an unconventional path actually gives you, why curiosity is the only framework that's followed her across every role, and what it looks like to build products at the exact moment the industry is being rewired.
—---------------------------
The latest is that I've recently moved from Staff PM to Group Product Manager, which also means I've moved into people management. But yes, it's been a very unconventional path. I never thought I'd be a product manager one day; I didn't even know what product management was when I started my career. I don't think many people did, twenty years back.
I started out in telecom engineering, then moved into software testing, also in the telecom domain. Around that time I got interested in human rights and started volunteering a lot, eventually deciding to try it full-time through a fellowship. I joined a traveling fellowship in India, working with rural NGOs and volunteer organizations for about two years.
At some point I realized I was missing my regular work and that this wasn't something I wanted to do full-time. I decided to go part-time and head back to work, that was when I got pregnant with my baby, which delayed things further. My planned two-year break became four years, and I couldn't go back to telecom because the industry moves so fast; landlines became smartphones, and so much of the learning there happens on the job, with no formal courses to catch up through.
It was hard to re-enter after a break in India, so I moved into technical writing and communication instead. I started at Oracle, where I began building internal tracking tools and applications, effectively becoming an application developer. From there I moved to Salesforce and applied for a product management role, though I actually joined Salesforce as a technical writer first. Within the first three months, I was able to move into product management through an internal transfer, and I've been a PM ever since, about eight years now. I spent four years at Salesforce, then moved to HubSpot.
Throughout, I've stayed in highly technical product areas that require an understanding of code, with technical audiences. Now I work on connecting AI agents to HubSpot through MCP, APIs, and CLI.
At Salesforce, I was asking too many questions about API design and tooling. I was responsible for documenting APIs and the best practices and systems around them, and I kept pushing on deeper questions — about the experience side, the tooling side, customers' problems.
A position opened up, and the hiring manager told the recruiter, "I want to hire someone like Sejal." The recruiter reached out and asked if I had friends like myself, and I said, "Can I apply?" She said yes. That's when I thought, okay, I'm genuinely interested in this, I hadn't done product management before, but I was leaning toward that area and decided to try. It really was accidental — sheer chance that the hiring manager reached out and I came to know about the opportunity.
Communication! the right level of communication with customers. Until MCP and the AI Connector work came along, most of my products at HubSpot were built for developers, and the only way developers discover your features is through documentation. That's the front door for discovery, there's no UI to speak of; documentation is the end-to-end discovery mechanism. So that's been an enormously important part of the job. I still write a lot as a PM; dev docs, external-facing content and technical writing continues to be part of what I do.
Coincidentally, all three companies have worked on CRMs in different capacities — even Oracle has a CRM product, same as Salesforce.
At Oracle, I spent a lot of time tinkering with internal tools, so I had less customer-facing work except during my time as a technical writer. But it was my first SaaS company, so I learned a lot about what it means to work in SaaS; the different functions, how products actually get built. Before that I'd only worked at services companies or telecom operators, so it was all new to me.
Salesforce was the first company where I worked as a PM, so that's really where I learned product management. Salesforce invests heavily in training, really top-notch programs, including strong leadership training — so I got to learn the discipline properly, and the processes of a large company, while constantly meeting and learning from new people.
HubSpot has been different again, it's the smallest company I've worked at, even though it's still about 9,000 people, and it moves incredibly fast. HubSpot ships every day, you can ship anytime you're ready, which sets a pace that pushes you to actually ship and innovate faster. It's a different way of building products, and the learning curve is steeper because you're moving in such a fast-paced environment.
People assume it's a completely different job, but in both cases you're ultimately building for customers. The difference is how far from them you're sitting. With direct, UI-facing products, you get a lot more signal, you can see exactly how people are using the product and where the friction is. With developer products, there's a layer in between, you're one step removed. My team builds the platform itself: the APIs, the UI extensions, now MCP — the tools developers use to extend HubSpot. Developers use those tools to build apps, and those apps go to HubSpot's customers. So the developers are effectively our partners, and the person running their business on that app is using what the developer built, not what I built directly.
That means you go through developers to get to customer feedback, which is challenging — those partners often become the voice of your customer unless you're intentional about going around them to interview the end users of their apps directly. It can be hard to get a clear read on what's really happening.
On the other hand, developers are always fun to work with because they're passionate and inventive, give them anything and they'll find a way to push it further than you ever expected. That itself is useful feedback: if they're working that hard to build something difficult, it tells you where you need to make things easier. And because your engineers understand these users so well, sometimes better than you do, it takes some of the pressure off as a PM. You don't always have to go find problems for them to solve; they bring problems to you.
I won't comment on specific mistakes other companies make, but generally, I think the common mistake in this space is making platforms too restrictive. There's a real difference between a guardrail and a guideline, and sometimes we lean too far toward blocking and restricting — often for the right reasons, like security. But if you restrict developers too much, you never really find out what possibilities you're missing for your own product. You only learn the true potential of a platform by keeping it more open. That openness is something I've learned to value along the way.
It's funny — it's only been about a year, and already people don't need much of an introduction to MCP. That wasn't the case with APIs; it took a long time for people to understand what an API even was.
When we first built MCP for HubSpot, I actually ran an internal proof of concept myself, this was before Claude Code existed, I used Cursor at the time. I built a small POC with just one tool to show what was possible with an MCP server, to evangelize it internally, and we shipped an alpha within about ten to fifteen days. Around then I was still explaining to customers and internal audiences what MCP actually was. Thankfully, our founder, Dharmesh Shah, did a great job explaining it broadly, which made things easier and I think his framing has become pretty common across the industry now: MCP is like a USB-C port. You can connect any system to any system.
You could always build these connections through APIs — the APIs were always there, and they still are. MCP sits on top of them. But with APIs alone, every company wanting to connect, say, HubSpot to Claude had to build that integration themselves. It's the world before USB-C; a different proprietary cable for every pair of devices, and someone had to make each one. With MCP, the onus shifts; if a company exposes a USB-C port, you just plug your agent in instead of building the cable yourself.
From a product manager's standpoint, AI changes a lot of the routine, mundane tasks. The biggest thing I use it for is customer sentiment; pulling together feedback and signals from hundreds of different sources and making sense of it, then turning that into something more prioritized and actionable.
I use it constantly to understand what's happening in my product area, where the gaps are, where the strong signals are, and where we need to invest. It even helps with figuring out what to build; a lot of the technical details you can work through with something like Claude Code before you ever knock on your engineers' door. You can get a first pass on whether an idea is even technically feasible, or whether you're talking sense or it's all garbage. It's been genuinely helpful, like having an engineering thought partner.
I've gotten stuck on this myself in the past. Yes, it helps to have someone advocate for you, I'd say the bigger skill is not waiting for anyone else to do that, but learning how to advocate for yourself. Even wanting to move to the next level often comes down to whether people know your impact — business impact, customer impact — and whether you can talk about it clearly and back it up with evidence, and make sure people actually hear about it.
Part of that is making your manager your champion. If you equip them with the right context, they're much better positioned to advocate for you. I think we sometimes expect too much from a manager and end up disappointed, but a lot of that responsibility is actually on us to give them what they need so they can champion you effectively.
What worked for me might not work for everyone, but I'd say: show curiosity, and ask the right questions, get curious about the "why" behind things and really try to understand it. If a decision is handed to you and you don't understand it, keep asking “why”, especially from the customer or user's point of view. The more you become the voice of the end user in these conversations, and keep asking why from their perspective, the further it takes you. That's certainly where it took me in my own PM journey.
Again, being curious is the biggest one for me. Just staying curious has helped me at every step, in every role.
—---------------------------
Toronto Product Management Association (TPMA) is a community focused on development, growth and networking of Product professionals in the Greater Toronto Area.
.png)
