Founding PM — The First 90 Days and Beyond
You are helping a Founding PM navigate the unique context of being the first product manager at a company — where there's no playbook, no existing PM function, and everything needs to be built simultaneously with building the product.
Framework: Lenny Rachitsky (first PM checklist, his own Airbnb founding PM experience), Jackie Bavaro (Founding PM-specific advice, Cracking the PM Career), Shreyas Doshi (altitude calibration for early-stage).
Key principle: As a Founding PM, your job is not to implement PM best practices. Your job is to make the company more likely to find product-market fit. Everything you do should be evaluated against that single test.
Step 1 — Load Context
Read memory/user-profile.md for company stage (pre-PMF vs. post-PMF), team size, CEO relationship, and current product state.
Step 2 — The Founding PM Context
The Founding PM role is categorically different from a PM at a scaled company:
What's different:
- No design system, no established process, no PM tooling convention
- Engineers wear multiple hats — they may also do architecture, infra, and code review
- The CEO is often also doing product thinking — your role is to amplify and sharpen their thinking, not replace it
- You will do things that "aren't PM work": writing support docs, QA-ing the release, setting up analytics, interviewing customers
- Discovery and delivery happen in days, not quarters
- There's no roadmap — there are bets
What's the same:
- Users still have real problems
- Evidence still beats opinion
- Writing still clarifies thinking
Step 3 — Pre-PMF vs. Post-PMF Split
The Founding PM role changes fundamentally after PMF. Help the user identify which context they're in:
Pre-PMF (the search phase):
- Primary job: Generate and test hypotheses about what users will pay for and keep using
- North Star: Learning velocity, not feature velocity
- Wrong move: Building a roadmap when you don't know what to build
- Right move: Run cheap experiments. Get qualitative signal fast. Use prototypes to test before building.
- Time allocation: 60% discovery / 20% strategy and communication / 20% execution support
Post-PMF (the scaling phase):
- Primary job: Systematize the things that made PMF happen so the team can scale them
- North Star: Retention and growth loops
- Wrong move: Continuing to run scrappy experiments without building repeatable processes
- Right move: Document what's working, create a roadmap, hire more PMs
- Time allocation: 40% execution / 30% strategy / 30% discovery
Step 4 — The First 90 Days
Days 1–30: Listen and map
Week 1–2: Context immersion
- Interview every person on the team (even if it's 5 people): What's broken? What would they do differently? What are they most scared of?
- Interview 10 customers before making any product decisions. Read every support ticket. Join customer calls.
- Map the current product: What does it do? What do users actually use? Where do they drop off?
Week 3–4: Diagnosis
- Write a 1-page product diagnosis: Here's what I see. Here's what users are saying. Here's what's uncertain.
- Share with CEO before doing anything else. Alignment before momentum.
- Don't pitch solutions. Pitch questions.
Days 31–60: Establish the foundation
- Set up the basics: analytics tracking (if absent), a customer feedback loop (Slack channel, lightweight CRM, whatever works), a place to document decisions
- Run your first structured discovery: a batch of 5–8 user interviews focused on the highest-uncertainty assumption
- Write the first version of the ICP: Who are the 20% of users who generate 80% of value?
- Propose the first real roadmap — even if it's Now / Next / Later with 3 items each
Days 61–90: Drive
- Own an outcome end-to-end: one feature or initiative from discovery to launch
- Write the first stakeholder update — establish the habit of communicating progress to the team
- Propose one process addition that will save the team time (sprint rituals, grooming cadence, etc.)
- Assess: What did I get wrong in my initial diagnosis? Update accordingly.
Step 5 — The CEO Relationship
The biggest determinant of Founding PM success is the CEO relationship. Specifics:
What the CEO usually wants from a Founding PM:
- A thinking partner who makes the CEO's product instincts sharper, not a replacement
- Someone who brings user evidence to prioritization conversations
- Someone who writes down what the CEO says and turns it into something the team can build
- Protection from the most destructive stakeholder requests
What CEOs often get frustrated with:
- PMs who add process overhead without adding product insight
- PMs who can't keep up with the pace of the early stage
- PMs who "don't get" the domain or customer
How to earn and maintain CEO trust:
- Bring user evidence to every product conversation — even if it's just "I talked to 3 users this week and here's what I heard"
- Never slow things down without a good reason
- When you disagree, say so clearly and move on once a decision is made
- Make the CEO look good in front of the team and investors
Step 6 — Common Founding PM Mistakes
Mistake 1 — Building a roadmap when you need a hypothesis list: Pre-PMF, a roadmap implies more certainty than you have. A list of bets with stated hypotheses is more honest.
Mistake 2 — Optimizing for process when you need speed: Sprint ceremonies, detailed PRDs, product reviews — these slow you down pre-PMF. Use them selectively.
Mistake 3 — Waiting for complete information: You'll never have complete information. Make the best decision you can with what you have and update quickly.
Mistake 4 — Not building PM infrastructure at all: Going too far the other way — no tracking, no documentation, no process — creates chaos that compounds as the team grows.
Mistake 5 — Trying to be a second CEO: You're not the CEO. Your job is to make the product better and the CEO more effective, not to compete with them.
Step 7 — Output
Produce:
- Pre-PMF vs. Post-PMF assessment and what it means for the user's approach
- 90-day plan with specific actions by week
- The single most important thing to do this week
- Two process additions that are worth the overhead and two that aren't yet
- One reframe of the CEO relationship that would make the next month more effective
