pm at a startup

Every PM training program is secretly optimized for Google. The frameworks, the interview questions, the templates — they assume a world where you have a data team, a research function, a design system, a structured sprint process, and a manager who has done the job before.

Most Indian startups have none of these things.

If you have joined a Series A company as the second PM, or you are the founding PM at a seed-stage startup, you are operating in a different discipline. The title is the same. The skills overlap. But the context changes everything.

This page is for that context.

What actually changes

The textbook definition of PM — decide what to build, get it built, measure if it worked — holds everywhere. What changes is every constraint around that definition.

At a large company: You own a slice of a product. Your users are well-defined. You have historical data. You have a roadmap process. Engineering capacity is known. Prioritization is a negotiation among stakeholders with established relationships.

At an early-stage startup: You own everything that doesn’t belong to engineering or sales. Your users are still being discovered. Your data is thin or unreliable. The roadmap is whatever the CEO said on the last investor call. Engineering capacity depends on whether one developer quit this week. Prioritization is a daily argument about survival.

The mental model shift: at a big company, your job is optimization. At a startup, your job is search. You are searching for a product that people will pay for, a distribution channel that works, and a repeatable business — all at the same time.

The executor trap

The most common failure mode for PMs who join early-stage startups from large companies: they become executors.

This is not a criticism of CEOs. Startup founders are extraordinary at many things: vision, fundraising, selling, hiring. What they are often bad at is separating the problem from the solution they already have in mind.

Your job as a startup PM is to be the translation layer between “the founder’s instinct about what to build” and “the customer’s actual behavior.” That requires you to push back, run fast validation, and bring data to conversations where everyone else is operating on gut.

The KB material from multiple Pragmatic Leaders sessions makes this pattern explicit: at an early-stage startup, the CEO is scanning in all directions and pivoting constantly. If the PM does not hold the line on product strategy — “this is what we are building for the next 30 days, and here is why we should not move” — the engineering team ships nothing coherent.

The four roles you will play simultaneously

At a 15-50 person startup, the PM job description rarely matches what you actually do in week one. Prepare to hold four roles at once:

1. Discovery engine No one else is systematically talking to users. You are. Your job is to run 5-10 user interviews per week in the early months, synthesize patterns, and turn vague pain points into testable hypotheses. At a startup without a research function, this is 100% yours.

2. Strategy co-author The founder has a vision. You have to make it operational — which means you will disagree regularly. You need to be comfortable walking into a founder’s office with data that contradicts their assumption, and walking out with a revised plan they believe in. This is political work. Do not treat it as purely intellectual.

3. Execution anchor Engineering at early startups tends to be founder-directed and reactive. Scope creep, “just one more thing,” and architecture debates are constant. Your job is to run a tight sprint — not tight as in bureaucratic, but tight as in clear scope, agreed outcomes, and a bias toward shipping over perfecting. Every sprint that ends without a shipped artifact is a week you will not get back.

4. Internal communicator At a startup, information does not flow through structured channels. Sales does not know what engineering shipped. Engineering does not know what sales promised. Investors hear one version, customers hear another. The PM is often the only person with the full picture. Write weekly updates. Not reports — updates. One paragraph: what shipped, what blocked us, what changed in our understanding of the problem. This alone will make you disproportionately valuable.

The CEO relationship

In a large company, your reporting line is to a VP of Product or a Director. They have done the PM job before. They run performance reviews. The relationship is professionally bounded.

At an early startup, you report to the founder or CEO. This changes the dynamic entirely.

Startup CEOs tend to want three things from a PM: speed, certainty, and alignment. The problem is that genuine product work — user research, hypothesis testing, data synthesis — produces the opposite in the short run. Research takes time. Good hypotheses introduce uncertainty. Alignment requires convincing someone who built the product from scratch that their instinct about the product may be wrong.

This conversation is recoverable because the PM brought evidence and held their ground respectfully. The mistake would have been to go ahead with the onboarding redesign because that was what was expected — then ship it, see no impact, and have the same conversation three months later with less credibility.

Three practical rules for the CEO relationship at an early startup:

Earn credibility before you push back. In your first four weeks, observe more than you direct. Understand what the founder values, how they think, what evidence they trust. A PM who walks in on day five and contradicts the founder’s core assumptions without having shipped anything will not last long enough to be right.

Never say no. Show the trade-off. “We can’t do the reconciliation report” is a dead end. “We can do the reconciliation report, but it will take 3 engineering days that were going to go to the payment retry logic — which one should we prioritize given last month’s churn data?” is a conversation. Always surface the cost of yes before declining.

Put things in writing, fast. After every conversation with a founder, send a three-line summary: what we discussed, what we decided, what I am doing next. This prevents “I said no such thing” moments two weeks later. It is not defensive — it is professional. The best startup PMs do this instinctively.

Startup vs. big company: what the numbers look like

A specific comparison. Not generic — these are patterns from the Indian startup ecosystem.

The upside of the startup column: every row under “low structure” is also high learning. You will make product decisions in month two that a PM at a big company would not make until year four. You will see the full loop — customer pain, hypothesis, build, measure, iterate — in weeks, not quarters.

The downside: you will make some of those decisions with insufficient information, ship the wrong thing, and have to explain why to a CEO who funded the sprint. That is part of the education.

When you are the only PM

Being the founding PM — or one of two PMs at a 30-person startup — is a specific job inside the startup PM category. It has unique demands.

You build the PM function from scratch. There is no existing process for how product decisions get made. You will introduce user interview templates, PRD formats, roadmap reviews, and sprint ceremonies — and you will have to sell each one. Not by citing best practices from Google, but by demonstrating that each process produces better outcomes than whatever existed before.

You are the institutional memory. Every decision that was made before you arrived exists in Slack threads, engineer memory, and founder intuition. Part of your first month is archaeology — dig up why the product looks the way it does, which experiments failed, which customers churned and why. Do not assume the code is the documentation.

You will be asked to do non-PM work. Customer support queries. Investor deck slides. Hiring sourcing for an engineering role. Competitive research for a BD meeting. Say yes to most of this in the first six months. It builds credibility and it gives you information you will not get from a formal PM process. Pick the moments to push back selectively — when the non-PM work starts consuming more than 30% of your week, raise it.

Product culture is your responsibility. If decisions are made without user research, that is your problem to fix — not by writing a memo, but by running two user interviews, showing the findings in the next team meeting, and doing it again next week. Culture is behavior repeated over time. You cannot ask for it. You model it.

The India-specific context

A few things that are different about the startup PM job in India that most PM curricula skip:

Founders often distrust PMs initially. The Indian startup ecosystem grew up on engineering-led product development. Founders who built their first product themselves often see a PM as overhead — someone who organizes meetings and creates friction between engineering and the business. Your first job is to make yourself obviously useful through specific, concrete output, not through explaining what a PM does.

Users will tell you what you want to hear. This is a well-documented phenomenon in user research globally, but it is more pronounced in India, where people are often reluctant to tell a stranger their product is bad. Learn to watch what users do, not what they say. Run usability tests where you observe behavior. Check drop-off in your funnel. The data is harder to fake than a polite interview.

Distribution is a product problem. Indian startups often treat distribution — WhatsApp, field sales, regional language support — as a sales or marketing question. But at early stage, distribution is inseparable from product. A product that does not consider how it will reach a first-time internet user in tier-2 India, or a small business owner who runs the company from a feature phone, is not done. The PM must have a point of view on distribution.

Regulatory context changes frequently. If you are working in fintech, edtech, healthtech, or any sector that has seen regulatory attention — SEBI, RBI, TRAI, MeitY — the product roadmap can be disrupted by a policy circular with two weeks’ notice. Build this into your planning. The PMs who thrive in these sectors treat regulatory change as a product input, not an interruption.

Test yourself

Where to go next

• The job you are working toward: Zero to One — Building from Scratch
• The milestone every startup is racing toward: Product-Market Fit
• When you start scaling beyond early customers: Scaling Product at a Startup
• The decision-making skill underneath all of this: Prioritization
• How to structure your time across all of these demands: A PM’s Day-to-Day