first pm hire: building the function from scratch

You are PM #1. The job posting said “product manager” but nobody at this company has done the job before. There is no PRD template. There is no sprint process. There is no analytics stack. The roadmap lives in the founder’s head and changes every time she gets off a customer call.

The engineering team ships whatever the CEO says to ship. Designs happen in Figma and WhatsApp screenshots simultaneously. Three paying customers have three different expectations. And the founder — who built this product from nothing, who coded the first version, who closed the first deal — is supposed to hand product decisions to you.

She will not hand them to you. Not yet. You have to earn that handoff. And the way you earn it is not by importing process. It is by proving that you make the product better and the founder’s life easier within the first 30 days.

This page is about those first 30, 60, and 90 days — and the specific mistakes that get first PMs fired or sidelined within a quarter.

Why founders hire a PM (and what they actually need)

The stated reason a founder hires a PM: “I need someone to own the product so I can focus on fundraising and sales.”

The real reason: the founder is drowning. Customer calls, engineering decisions, design reviews, bug triage, roadmap questions from investors — all of it flows through one person. The founder is not looking for a “product visionary.” She is looking for relief.

This distinction matters because it sets your initial mandate. You are not hired to reimagine the product strategy. You are hired to absorb the operational chaos around the product so the founder can breathe. Strategy comes later — once you have earned the right to have strategic opinions.

I have watched dozens of first PM hires at Indian startups through Pragmatic Leaders cohorts. The ones who lasted understood this sequence: first be useful, then be strategic. The ones who got sidelined came in with frameworks and opinions on day one.

The handoff is not automatic

At large companies, when you join as a PM, the role is defined. You inherit a product area, a team, a backlog. Authority comes with the title.

At a startup where the founder has been the PM, authority is personal. The founder built the product. The engineering team trusts her judgment. Customers have a direct line to her. When you show up with the title “product manager,” nobody automatically defers to you — and they should not.

The handoff happens in three stages, and you cannot skip any of them:

Stage 1: Shadow and absorb (weeks 1-2). Sit in every meeting. Read every customer ticket from the last 6 months. Understand how decisions actually get made — not the org chart version, but the real version. Who does the engineering lead listen to? Which customer’s opinion carries the most weight? What did the founder try and abandon? This stage is about building a mental model of the business that is accurate, not theoretical.

Stage 2: Own the edges (weeks 3-6). Take over the operational work the founder is worst at or most annoyed by. Bug triage. Customer call notes. Sprint coordination. Design review logistics. These are not glamorous. They are the proof that you can be trusted with more. Every week you own an edge without breaking it, the founder’s confidence in you grows.

Stage 3: Earn the centre (months 2-3). After you have absorbed context and proven operational competence, start making product recommendations. Not decisions — recommendations. “Based on what I’ve seen in customer calls and the support queue, I think we should prioritise X over Y. Here’s my reasoning.” The founder will push back on some of these. That is fine. The point is not to be right — it is to demonstrate product judgment that the founder can evaluate.

The mistake I see most often: PMs who jump straight to Stage 3. They walk in, spend a week “getting up to speed,” and then present a roadmap. The founder nods politely, ignores it, and continues making product decisions herself. Three months later, the PM is confused about why they have no influence.

You do not earn influence by having good ideas. You earn it by demonstrating that you understand the business, the customers, and the product as well as the founder does — and then showing you can make it better.

What to build first (and what to leave alone)

Your instinct will be to set up a “proper” product process. Resist that instinct. Every process you introduce has a cost: it takes time, it creates friction, and it signals to the team that things are changing. Introduce too much too fast and you become the person who “slowed us down.”

Instead, introduce exactly three things in your first 60 days. No more.

1. A lightweight decision log

Not a PRD template. Not Confluence. A shared doc — Notion, Google Docs, whatever the team already uses — where you write down every product decision with three fields:

• What we decided
• Why (the reasoning, in 2-3 sentences)
• What we gave up (the alternative we considered and rejected)

This does three things. It creates institutional memory at a company that has none. It forces clarity on decisions that were previously made in Slack and forgotten. And it gives the founder a record she can point to when investors or customers ask “why did you build X instead of Y?”

Start filling this in retroactively. Go to the founder and the engineering lead. Ask them about the last five major product decisions. Document them. This is not busywork — it is you building context while creating something useful.

2. A weekly product review

Not a standup. Not a sprint planning session. A 30-minute meeting, once a week, where three things happen:

• What shipped last week (demo, not description)
• What we learned from customers this week (3-5 insights, sourced from support tickets, calls, or your own conversations)
• What we are building next week and why

This meeting replaces the chaos of “the founder decides in the hallway.” It creates a rhythm. It gives engineering visibility into why they are building what they are building. And it gives you a natural venue to introduce product thinking without calling it that.

Keep this meeting to 30 minutes. Do not let it become a two-hour planning session. Do not introduce story points, velocity tracking, or estimation frameworks. The goal is rhythm, not rigour.

3. A customer feedback system

At a 20-person startup, customer feedback exists but it is scattered. It is in the founder’s inbox. It is in support tickets. It is in Slack messages from the sales guy. It is in WhatsApp groups with early customers. Nobody is aggregating it.

Set up a single channel — a Slack channel, a Notion database, a simple spreadsheet — where all customer feedback gets logged. Not analysed, not prioritised, just logged. When someone hears a feature request on a call, they drop it there. When a support ticket reveals a pain point, it goes there.

This does not need to be sophisticated. A spreadsheet with four columns works: Date, Customer, What They Said, Category. The value is not the tool. The value is that for the first time, the company has a single place to see what customers are actually asking for — and you can start spotting patterns that nobody else sees because nobody else was looking.

What NOT to do

The failures are more instructive than the successes. Here is what kills first PM hires at Indian startups:

Do not introduce Jira when the team uses a Notion board. If the engineering team is shipping with a Notion kanban board, do not switch them to Jira. You will spend three weeks migrating, training, and configuring — and ship exactly nothing. Use whatever the team already uses. Optimise the existing tool before replacing it. I have seen this mistake at five different startups through our cohorts. The PM brings in Jira because “that’s what real companies use.” The team hates it. Velocity drops. The founder blames the PM.

Do not write a 30-page PRD. At a 20-person startup, a PRD should be one page. Problem, proposed solution, success criteria, open questions. That is it. The engineering lead sits three desks away from you. If the spec is ambiguous, walk over and talk. The PRD is a thinking tool, not a communication artefact. If your PRD is longer than what someone can read in 5 minutes, you are writing for a company that does not exist yet.

Do not ask for a data team before you have set up basic tracking. You do not need Mixpanel, Amplitude, and a dedicated analyst. You need Google Analytics or PostHog (free tier), five key events tracked, and a weekly habit of looking at the numbers. Set up basic event tracking in your first month. You can get sophisticated later. The first PM who says “I can’t make data-informed decisions because we don’t have an analytics stack” has already lost. Build the minimal version yourself.

Do not reorganise the team. You are new. You do not understand the team dynamics yet. The engineering lead who seems disengaged might be the most productive person on the team. The designer who seems junior might be the founder’s most trusted collaborator. Observe for 60 days before suggesting any structural changes.

Do not compete with the founder. This is the subtlest and most fatal mistake. You are not here to prove you are smarter than the founder about the product. You are here to make her product judgment more effective by giving it structure, data, and customer insight. The moment the founder feels you are trying to take “her product” away from her, you are finished.

The 30/60/90 day framework

This is the plan I recommend to every first PM hire who goes through our program. It is deliberately conservative in the first 30 days and progressively more assertive.

Days 1-30: Learn and absorb

Your job is to build context, not to make changes.

• Sit in on every customer call. Take detailed notes. Share them.
• Read the last 6 months of support tickets. Categorise the top 10 complaints.
• Interview every team member: what do they think the product should be? Where do they think the biggest problems are? You will get wildly different answers. That is the point.
• Shadow the founder in every product-related meeting. Do not speak unless asked. Watch how decisions get made.
• Map the actual user journey. Sign up as a user. Use the product. Break it. Document every point of confusion.
• Set up basic analytics if none exist. Five key events, tracked. Weekly check-in with the numbers.

Output by day 30: A one-page document — “What I’ve Learned in 30 Days.” Share it with the founder. Include: top 5 customer pain points (with quotes), top 5 product gaps (your assessment), and the three decisions you would make differently (with reasoning). This document is your audition for strategic influence.

Days 31-60: Own the operational layer

Your job is to create rhythm without creating bureaucracy.

• Start the weekly product review. Run it yourself.
• Take over sprint coordination with engineering. Keep whatever process they have. Just make it more consistent.
• Start the decision log. Backfill the last 10 decisions.
• Set up the customer feedback channel. Start tagging and categorising.
• Write your first product spec. Keep it to one page. Get it reviewed by the founder and the engineering lead. Ship the feature. This is your first end-to-end product cycle — it needs to go well.
• Start having 1:1s with the engineering lead. This is the most important relationship you will build. Not the founder — the engineering lead. If engineering does not trust you, nothing else matters.

Output by day 60: The team has a product rhythm. The founder is attending fewer operational meetings. Decisions are documented. Customer feedback is aggregated. You have shipped one feature end-to-end.

Days 61-90: Introduce product strategy

Your job is to shift from reactive to proactive.

• Present a quarterly product plan. Not a roadmap — a plan. “Here are the three bets I think we should make in the next 90 days, and here is why.” Ground it in customer evidence and business metrics.
• Introduce a lightweight prioritisation framework. I recommend a simple effort-vs-impact matrix. No ICE scores, no RICE, no weighted scoring models. Two axes: how much effort, how much impact. Sort and discuss.
• Start running user research proactively — not just reacting to support tickets. Pick the biggest open question about the product and run five user interviews in a week to answer it.
• Propose one process improvement. Just one. It might be a better handoff between design and engineering. It might be a monthly customer advisory call. Pick the highest-impact change and make it happen.

Output by day 90: The founder trusts you to make product decisions without her in the room for 80% of cases. She still wants to weigh in on the big bets — and she should. But the day-to-day is yours.

The founder override problem

This is the moment that breaks most first PM hires. You have done the work. You have built context, earned trust, and created a product plan. And then the founder overrides your recommendation.

Maybe she came back from a customer meeting with a “must-have” feature. Maybe an investor mentioned a competitor and she panicked. Maybe she simply disagrees with your prioritisation.

This will happen. It is not a failure. It is the nature of working at a founder-led company. How you respond determines whether you last.

The India-specific dynamics

Startup PM hiring in India has specific patterns that global PM advice misses.

The founder-CEO is almost always the de facto PM. In Silicon Valley startups, the CEO often comes from a business or sales background and hires a PM early. In Indian startups — especially technical founder-led companies — the CEO built the product herself. She understands the technical architecture, the user experience, and the market deeply. This means the handoff is harder. You are not filling a vacuum. You are replacing someone who was doing the job and doing it reasonably well. Your value proposition is not “I’ll do the job you can’t do.” It is “I’ll do the job so you can do the other five jobs that need you.”

Hierarchy is implicit even in flat startups. Indian startups claim flat hierarchies, but in practice, the founder’s word carries disproportionate weight. If the founder says “build X” in a standup, the engineering team will build X regardless of what the sprint plan says. You cannot fix this by asserting your authority. You fix it by being in the room when the founder has the idea, shaping it before it becomes a directive. This means your calendar should overlap heavily with the founder’s in the first 90 days.

The “jugaad” culture cuts both ways. Indian engineering teams are extraordinarily good at shipping fast with limited resources. This is an advantage — you will get more done with fewer people than you expect. The downside: shortcuts accumulate. Tech debt is tolerated until it causes a production incident. Your job is not to impose engineering discipline — that is the CTO’s job. But you need to understand which shortcuts affect the user experience and flag those.

Compensation and title matter more than startups want to admit. If you are PM #1 and the next hire is a Senior PM from Flipkart, you need clarity on reporting lines and decision rights before that hire happens. I have seen first PMs get undermined by a senior hire who was brought in “to help scale” but actually takes over. Have the conversation about your growth path and the team structure early — not after the second PM joins.

The relationship that matters most

Your most important relationship is not with the founder. It is with the engineering lead.

The founder gives you the mandate. The engineering lead gives you the ability to execute. If the engineering lead does not trust your judgment — if she thinks your specs are vague, your priorities are wrong, or you do not understand the technical constraints — nothing ships well, no matter what the founder says.

Build this relationship deliberately. Spend time understanding the codebase at a high level. Ask the engineering lead what annoys her about the current process. Ask what the biggest technical risk in the product is. Ask what she would build if she had a free sprint. These conversations create mutual respect faster than any “PM-Engineering alignment framework.”

And when the engineering lead pushes back on a spec or a timeline, listen. At a 20-person startup, the engineering lead has been shipping this product since the beginning. She knows where the code is fragile, which features will be easy and which will be nightmares. That knowledge is more valuable than any prioritisation framework you bring.

When it works

When the first PM hire works — when the handoff happens, the rhythm is established, and the founder trusts the PM — the startup accelerates visibly. The founder closes the Series A because she has time to focus on investors. Engineering ships faster because priorities are clear. Customers feel heard because someone is systematically listening.

This is not a small thing. At the 20-person stage, the difference between a startup that has a functioning product process and one that does not is the difference between a Series B and a pivot. You are building the operating system for how this company makes product decisions. That operating system will outlast you. Build it well.

Where to go next

• Understand the startup PM role deeply: PM at a Startup — scope, speed, and the four roles you play simultaneously
• Build and ship fast: Zero to One — MVP definition, first users, and the mistakes that kill products before launch
• Find product-market fit: Product-Market Fit — the metrics, the signals, and when to know you have it
• Write specs that work at a startup: Writing PRDs — one-page specs that engineers trust and founders approve
• Build the right relationships: Stakeholder Management — working with founders, engineering, and early customers
• Understand prioritisation: Prioritization — frameworks that work when everything feels urgent