building a pm team
When things are growing really fast, you need to get more product managers in your team so you can distribute the tasks. But adding each person adds entropy. You have to be deliberate.
Most founders and first-time PM leaders make the same mistake: they hire PMs the way they hire engineers. Post a JD, look for domain experience, run a few interviews, pick the person who sounds smartest.
Then three months in, the new PM is sitting in meetings all day, the roadmap is still a spreadsheet nobody trusts, and the founder is doing all the product decisions anyway. The hire did not fail because the person was bad. It failed because there was no structure for them to succeed in.
Building a PM team is an organizational design problem first and a hiring problem second. Get the structure wrong, and even great PMs will be ineffective.
When to make your first PM hire
This is the question every scaling startup in India faces around Series A. The founder has been playing PM — talking to customers, writing specs, prioritizing the backlog. Now there is too much to do. The instinct is to hire a PM immediately.
Hold that instinct. Ask three questions first:
1. Can a founder still own product for the next six months?
If yes, do not hire a PM. At early stage, every person you add increases communication overhead. A founder doing product with two engineers ships faster than a PM coordinating between a founder and two engineers. The entropy is real.
2. Is the bottleneck discovery or execution?
If you know what to build but cannot ship fast enough, you need more engineers, not a PM. If you are shipping fine but building the wrong things, you need a PM.
3. Do you have enough surface area for a full-time PM?
One product with one user segment and one revenue model does not need a PM. Two products, or one product with three distinct user types, or a platform play — now you have enough surface area to justify a dedicated product person.
Board meeting at a Series A fintech in Bengaluru. Monthly burn: 35 lakhs.
CEO: “We need to hire a Head of Product. I am spending 60% of my time on product decisions and I cannot keep doing this.”
Board Member: “What product decisions specifically?”
CEO: “Prioritizing features, writing specs, talking to customers, managing the engineering team's sprint.”
Board Member: “That sounds like three different roles. Which one is actually bottlenecking you?”
CEO: “Honestly... the sprint management. I spend hours in Jira.”
Board Member: “Then you need an engineering manager, not a Head of Product. You are the Head of Product. You just need someone to run the trains.”
The CEO hired an engineering manager. Six months later, when they had three product lines, they hired their first PM.
The bottleneck was execution overhead, not product thinking. Misdiagnosing it would have wasted six months and 25 lakhs.
Structuring the PM team
Once you need multiple PMs, you face an org design decision. There are two dominant models, and the right one depends on your product architecture.
Model 1: Product-aligned PMs
Each PM owns a product or major product area end-to-end. This is the most common structure in India’s mid-stage startups.
| PM | Owns | Reports to |
|---|---|---|
| PM — Lending | Loan application, underwriting, disbursement | Head of Product |
| PM — Payments | UPI, wallet, merchant settlements | Head of Product |
| PM — Growth | Onboarding, activation, referrals | Head of Product |
When this works: When your products are distinct enough that one PM can own the full user journey within their area. The PM has full context on their domain and can make fast decisions.
When this breaks: When features cut across products. A “KYC flow” that serves both Lending and Payments creates ownership fights. A “notification system” that serves Growth and Payments creates coordination overhead.
Model 2: Platform + feature PMs
One or more platform PMs build shared capabilities. Feature PMs build user-facing experiences on top of those capabilities.
Think of it as Lego blocks: the platform PM decides what blocks to build. The feature PMs assemble them into products. This is how larger product organizations at companies like Razorpay and PhonePe operate.
When this works: When shared infrastructure (payments rails, identity, notifications) serves multiple product lines. It prevents each team from rebuilding the same component.
When this breaks: When the platform PM becomes a bottleneck. If every feature team needs platform changes and there is only one platform PM prioritizing them, you have created a dependency chokepoint.
The hybrid reality
In practice, most Indian product teams at the 50-200 person stage run a hybrid. Two or three product-aligned PMs, one platform PM, and — critically — a shared understanding of who owns what at the boundaries.
Draw your current product architecture. For each major area, answer:
- Who owns product decisions today? (Name, not role)
- Where do two areas share infrastructure or user flows?
- Where have you seen ownership disputes or “this is not my problem” behavior in the last quarter?
The ownership disputes tell you where your structure is wrong. If two PMs keep fighting over the same feature, either split it more clearly or create a platform PM role to own the shared layer.
Hiring PMs who actually work out
The pattern I see in hiring failures is consistent: companies hire for the wrong signals.
What to hire for (in order of importance)
1. Problem-finding ability. Not problem-solving — problem-finding. Give the candidate a product and ask them what is wrong with it. A mediocre PM will list UI issues. A strong PM will identify a misalignment between the product’s value proposition and its user behavior. You want the person who sees the structural problem, not the surface one.
2. Communication under ambiguity. Product management is 70% communication. Show the candidate a messy, incomplete brief and ask them to present a recommendation in ten minutes. Watch how they handle gaps. Do they make assumptions explicit? Do they say “I don’t know” when they do not know? A PM who cannot communicate clearly under ambiguity will create chaos in your organization.
3. Domain proximity, not domain expertise. Hiring a PM for your logistics product? You do not need someone who has worked in logistics for five years. You need someone who has worked on operationally complex products — food delivery, field services, fleet management. The mental models transfer. Exact domain expertise is overrated and creates tunnel vision.
4. Comfort with numbers. Not data science. Basic quantitative reasoning. Can they estimate the market size for a feature? Can they look at a funnel and spot the problem? Can they define a metric for success? If they cannot think in numbers, they will make decisions by intuition alone — and intuition without data is just guessing.
What not to hire for
Brand-name companies on the resume. A PM from Google India may have owned a tiny surface area of a massive product. A PM from a Series B startup may have owned everything. Evaluate the work, not the logo.
Framework fluency. If a candidate talks about RICE prioritization for fifteen minutes, they have read a blog post. If they talk about a specific decision they made and how they evaluated tradeoffs, they have done the work.
“Passion for the product.” This is a meaningless signal. Hire for curiosity and rigor, not enthusiasm.
Building PM culture (the part nobody talks about)
You have the right structure. You have hired good people. Now comes the part most PM leaders neglect: building the operating culture that makes the team effective.
Shared decision-making language
The number one dysfunction in PM teams is inconsistent decision-making. One PM uses intuition. Another uses data. A third does whatever the loudest stakeholder wants. The team makes contradictory choices and nobody understands why.
Fix this by establishing explicit decision norms:
- Every feature decision has a written hypothesis. “We believe [change] will move [metric] by [amount] because [reason].” No hypothesis, no build.
- Every prioritization has a stated framework. It does not have to be RICE. It has to be something the whole team uses consistently. Consistency matters more than which framework you pick.
- Every launch has a success criteria defined before launch. Not after. Not retroactively. Before. The PM writes it, the Head of Product reviews it, and the team holds itself accountable to it.
Rituals that actually help
Most PM teams have too many rituals. Weekly syncs, monthly reviews, quarterly planning, annual strategy. Half of these are status updates that could be a document.
Keep three rituals. Cut the rest:
1. Weekly product review (60 min). Each PM presents one decision they are making this week and gets input. Not a status update — a decision. “I am choosing to deprioritize feature X because of Y. Does anyone see a risk I am missing?” This builds collective judgment.
2. Monthly teardown (90 min). The team picks one competitor product or one internal feature that underperformed. They tear it apart: what went wrong, what they would do differently, what they can learn. This builds analytical muscle.
3. Quarterly roadmap alignment (half day). Each PM presents their roadmap for the quarter. The group identifies dependencies, conflicts, and gaps. This is where the Head of Product earns their keep — resolving cross-team tradeoffs that individual PMs cannot resolve on their own.
Growing PMs from within
In India, hiring senior PMs is expensive and the talent pool is thin. Growing your own is not just cost-effective — it produces PMs who understand your product deeply.
The playbook is simple:
- Give associate PMs ownership of a small, complete problem. Not “help the senior PM with research.” Own a feature from problem definition to launch. Small scope, full responsibility.
- Pair them with engineers, not with other PMs. A PM learns faster by shipping with an engineering team than by shadowing another PM. The feedback loop is tighter and the stakes are real.
- Review their artifacts, not their slides. Read their PRDs, their experiment designs, their post-launch analyses. Give specific, written feedback. This is how you build PM judgment — one document at a time.
Test yourself
You are Head of Product at a D2C e-commerce company in India. You have 2 PMs today — one owns the buyer experience, the other owns the seller tools. The company just raised Series B and is expanding into three new categories. The CEO says: 'We need to hire 4 more PMs immediately.' Your current two PMs are strong but stretched thin.
You have budget approval for 4 PM hires. Your CEO wants them onboarded within 2 months. Your current PMs are working 12-hour days.
your path
You are the Head of Product at Nykaa, managing four PMs. You have just discovered that two of your PMs — Priya (strong performer) and Sameer (mid performer) — are both applying for the same external role at Myntra: a Group PM position with a significant title jump. Neither has told you. You learned this from a mutual connection. Priya is critical to a launch happening in 8 weeks. Sameer's team has more slack.
The call: Do you bring it up directly with them, say nothing and plan for the possibility of turnover, or address it differently for each?
You are the Head of Product at Nykaa, managing four PMs. You have just discovered that two of your PMs — Priya (strong performer) and Sameer (mid performer) — are both applying for the same external role at Myntra: a Group PM position with a significant title jump. Neither has told you. You learned this from a mutual connection. Priya is critical to a launch happening in 8 weeks. Sameer's team has more slack.
The call: Do you bring it up directly with them, say nothing and plan for the possibility of turnover, or address it differently for each?
Where to go next
- Hiring PMs in depth: Hiring PMs — interview frameworks, evaluation rubrics, and red flags
- Your own growth as a PM leader: VP / CPO Path — what changes when you manage PMs instead of products
- The skills your PMs need to develop: PM Competency Model — the assessment framework for individual contributors
- How PM teams run day-to-day: A PM’s Day-to-Day — what the calendar actually looks like
- Managing organizational change: Change Management — leading through restructuring and transitions