You don’t have a product manager. You have a product, two engineers, a backlog that lives somewhere between Notion and your head, and twenty conversations from last week’s customer calls that you haven’t processed yet. That is what product management actually looks like at an early-stage startup — and most of the advice written about it assumes you have a dedicated PM, a design sprint budget, and a Jira admin.
At Jetpack Labs, we’ve built software with dozens of founders who are in exactly this position. They’re running the product while pitching investors, handling support tickets, and trying to close their first enterprise deal. This guide is for them — for you. Not theory, not Steve Jobs quotes. What to actually do this week.
The Founder-as-PM Reality
Here’s the honest version of the job description: you are simultaneously the person who decides what to build, the person who explains it to engineers, the person who talks to customers, and the person who decides when something is done. There is no handoff between strategy and execution because you are both sides of it.
That’s not a bug. At 2-10 people, tight coupling between product decisions and customer reality is actually your advantage over a larger company. You don’t need to write a PRD that survives a five-person review process. You need to make a good call on Monday and ship something by Friday.
The problem is that most PM frameworks were designed for organizations big enough to have a PM in the first place. Scrum ceremonies, OKR cascades, user story mapping workshops — these are load-bearing when you have ten engineers and need coordination scaffolding. When you have two, they’re overhead. What you actually need is a simpler system that fits inside a single week and a single brain.
The One PM Skill That Matters Most Right Now: Triage
Not roadmaps. Not sprint velocity. Triage — the ability to say no to 90% of ideas, including your own.
Every founder we work with has the same problem: too many ideas, too few engineering hours, and a strong bias toward building. The feature backlog grows faster than the team can ship, and instead of making a hard call, the temptation is to just keep adding items. Six months later, nothing is finished and the product has no coherent shape.
The framework we use is simple: three columns, every feature idea goes in one of them.
- Now: The one or two things that directly unblock growth or retention this cycle. Not five things. Two.
- Next: Ideas that are good but not urgent. Revisit them in four to six weeks. Most will stay here.
- Never: The honest column. Things that sound good but don’t move the core metric. Most ideas belong here.
The “never” column is where most founders get uncomfortable. An idea you had at 2am that felt urgent tends to look different six weeks later. Be ruthless about it. Every idea in “now” that shouldn’t be there is an idea that delays something that should.
The constraint isn’t imagination. At a startup, the constraint is always attention. Triage is how you protect it.
User Interviews on Zero Budget
The most valuable product research you can do right now costs nothing but time — and you already have access to the people you need to talk to. Here’s how to run five meaningful user interviews in a week.
Who to talk to
Talk to your last five signups, not your best customers. Your best customers are an outlier — they’ve figured out how to get value from your product, which means the friction that stops everyone else is largely invisible to them. Your newest users carry the clearest signal about where the product is actually failing.
What to ask
One question does most of the work: “Walk me through the last time you tried to solve [the problem your product addresses].” Then stop talking. Don’t ask what features they want. People are notoriously bad at predicting what they’ll use — but they’re excellent at describing what actually happened. Listen for the friction, the workaround, the moment they gave up.
Avoid leading questions. “Did you find the onboarding confusing?” will get you “a little, but it was fine.” “Tell me what happened when you first logged in” will get you the truth.
What to do with what you learn
After five interviews, write down every friction point you heard — one per line. Then count how many times each one appeared. Anything that came up in three or more interviews is real. Anything that came up once is interesting but not yet actionable. That list is your product backlog, ranked by users instead of by you.
When to Write a Spec — and When Not To
For a two-person dev team, a three-paragraph Notion doc is a spec. You don’t need user stories, acceptance criteria, or a design review. You need enough shared context that the engineer building the feature and the founder reviewing it have the same picture in their heads.
We call this the thin spec. It has four parts:
- Problem statement (one sentence): What is the user unable to do right now, and why does that matter?
- Success metric (one thing): How will you know in two weeks whether this worked? Name the number.
- Constraints (what you won’t do): Scope creep kills small teams. Write down explicitly what this feature does not include.
- Open questions: What do you still need to decide? Write them down so they get answered before engineering starts, not during.
When do you skip the spec entirely? When you’re shipping something you can undo in a day. A copy change, a UI tweak, a configuration option — ship it, measure it, revert if needed. Save spec-writing for decisions that are hard to reverse.
The Startup Sprint Rhythm That Actually Works
Not Scrum. Not Kanban. Something simpler: one goal per week, a 30-minute kickoff on Monday, a 30-minute retro on Friday, and a deployment before you close your laptop on Friday afternoon.
The weekly cycle forces a useful question every Monday: “What is the one thing we could ship this week that would make the product meaningfully better?” Not five things. One. If the answer is too big to ship in five days, break it down until it isn’t.
The Friday retro has two questions: Did we ship the thing? And what slowed us down? The answers compound. A team that runs this cycle honestly for two months will have eliminated most of its recurring friction. The methodology matters far less than the discipline of closing the loop every week.
Short cycles also protect you from the biggest PM failure mode at a startup: building something for three weeks and then discovering it solves the wrong problem. The faster you ship, the faster you find out if you were right.
The Metrics You Actually Need to Watch
Ignore page views. Ignore signups. Ignore DAU until you have a product that deserves daily use. Three metrics tell you almost everything you need to know at this stage:
- Activation rate: What percentage of new signups complete the core action in their first session? If someone signs up but never does the thing your product is for, you have an onboarding problem. This is the metric most founders don’t watch, and it’s where most early products quietly fail.
- D30 retention: Of the users who signed up 30 days ago, how many are still using the product? If this number is low, you have a value problem — people tried it, didn’t get enough out of it, and moved on. No amount of new user growth fixes a broken D30.
- Time-to-value: How long does it take a new user to get their first real result from your product? Measure it. Then cut it in half. The faster someone gets value, the more likely they stick around.
Everything else is context. Revenue, NPS, session length — all useful, but derivative. If activation, D30 retention, and time-to-value are healthy, most of the other numbers will follow.
When to Hire Your First Real PM
Don’t hire one until you’ve shipped at least three product cycles yourself. You need to understand what the job actually requires before you can delegate it to someone else — and that understanding only comes from doing it.
You’re ready to hire a PM when three things are true:
- You’re consistently choosing between good ideas rather than filtering out bad ones. This means the problem space is getting complex enough to require full-time curation.
- The roadmap has more right answers than you have time to build. This is a very different problem from not knowing what to build.
- You have product-market fit — meaning retention is strong enough that you’re confident the product is right and the job is now about expanding it, not finding it.
Hiring a PM before you have these signals is expensive and usually counterproductive. A good PM will ask you questions you can’t answer yet, and a mediocre PM will introduce process that slows you down. Do the job yourself until you genuinely can’t anymore.
The PM Handoff: How Not to Break Everything When You Stop Being the PM
The most common mistake founders make when they hire their first PM: they hand over the backlog and assume context transfers with it. It doesn’t. The new PM doesn’t know why you made the decisions you made, what you tried that didn’t work, or what mental model your users have of the product. Without that context, they’ll repeat your mistakes.
Before you step back from the product role, write what we call a product bible. It doesn’t need to be long — a well-organized Notion doc will do. It should cover:
- Decisions and their reasoning: For every major product decision you made, write down why. Not just what you built, but what you decided not to build and why.
- What you tried and what failed: A list of experiments that didn’t work, with enough detail that the next person doesn’t have to run them again.
- The user mental model: How do your users think about the problem your product solves? What language do they use? What do they expect the product to do that it doesn’t yet? This is the hardest thing to reconstruct from scratch.
This document is the most valuable thing you can give a new PM. It turns a 90-day ramp into a 30-day ramp and protects the product judgment you’ve accumulated through months of customer conversations.
Start With This Week
If this all feels like a lot, start with one thing: schedule five 20-minute calls with your last five signups and ask each of them to walk you through the last time they tried to solve the problem your product addresses. Don’t pitch. Don’t explain. Just listen.
What you hear will reorganize your backlog better than any framework. That’s the job — staying close enough to your users that your instincts are reliably right. Everything else in this guide is scaffolding around that core skill.
At Jetpack Labs, we partner with founders who are in the middle of this exact phase — building the product, managing the team, and figuring out what product management actually looks like when there’s no one else to do it. If you’re there right now, we’d be glad to talk.