Your first PM is struggling, and it’s probably your fault
Eight things founders get wrong handing the wheel to their first PM
It’s been a while since I wrote here. In that time, I joined GitHub as a PM. The job was intense and exhilarating, and there wasn’t room for much else, including this newsletter. I’ve since left to return to founding full-time.
I’ve been a lot of different kinds of PM: a first PM, a founder acting as PM, a product director, and most recently a PM at GitHub. Of all of them, the hardest to get right is a startup’s first-ever PM. That’s why I’m restarting this newsletter with a tighter focus: the initial phases of building a product org, starting with the first PM hire.
Here’s what that looks like. The search is over, the offer has been accepted, and someone finally owns product. The founder expects to recover time, the PM expects to take responsibility, and everyone is optimistic. Then the handover proves harder than expected. This usually isn’t a sign that the wrong person was hired. It’s a sign that the company hasn’t yet changed how product leadership works, because hiring a PM doesn’t automatically transfer the founder’s context, judgement, or authority.
Why the first PM struggles
When a first PM stalls, it is tempting to question the hire. In my experience the cause is almost always one of three things, and all three sit with the founder rather than the PM.
Context never gets transferred. Years of customer conversations, failed experiments, and hard-won judgement live in the founder’s head. The PM sees the decisions but not the history behind them, so they cannot reproduce the founder’s thinking and keep looking like they do not understand what matters.
Decision rights are left implicit. “Own product” is said but never defined, so the PM is accountable for outcomes without the authority to match and is never sure when they are actually allowed to disagree with the founder.
They get conclusions and silence. Founders save time by handing over answers rather than the evidence and reasoning behind them, so the PM never builds independent judgement. Feedback then arrives late, long after the moment when it would have helped.
The rest of this piece is about closing these three gaps, along with a few related traps that make them worse.
1. Your role changes before theirs can
Before the first PM arrives, product management happens inside the founder’s head. Customer conversations, sales objections, technical constraints, investor expectations, failed experiments, and strategic choices accumulate over years. The founder can make a decision in minutes because they’re drawing on context that nobody else can see. The new PM sees the decision, but not always the history behind it.
That work is both tactical and strategic at once: reviewing feature decisions, sitting in sprint planning, checking the same analytics weekly, on top of fundraising, hiring, and everything else running the company demands. Hiring a PM should lift the tactical layer off the founder’s plate, freeing them for the parts of the company only they can do. Most founders keep reaching for those tactical decisions anyway, because they’ve been close to the product for so long that letting go feels unnatural. Distrust has little to do with it. That habit does more to keep a founder in the PM’s way than any lack of trust does.
Your first PM needs more than a roadmap and a list of introductions. They need access to the thinking that produced the roadmap, and they need to understand which assumptions are firm, which are open to challenge, and which decisions they can make without asking you. The goal is to build, over time, a system through which context and responsibility can move.
2. Start with outcomes before the backlog
It’s tempting to give a new PM the backlog because it’s concrete. There are features to prioritise, customer requests to resolve, and bugs to fix. But a backlog tells them what people have asked for. It doesn’t tell them what the company is trying to change.
Start with a small number of outcomes instead:
What must become true for customers?
What must become true for the business?
What would meaningful progress look like in 90 days?
Which assumptions need to be tested first?
This gives the PM room to develop a view rather than merely administer inherited work. A useful test is whether the PM can explain the company’s priorities without referring to a list of features. If they can’t, the gap is usually strategic context, and a better roadmap template won’t close it.
3. Work through the PM, not around them
Founders who struggle to let go often show it by giving direction straight to engineers or designers, or quietly doing parts of the PM’s job themselves. The team notices. If the founder keeps routing around the PM, the obvious read is that the PM’s judgement isn’t trusted, so why should anyone else defer to it? Route requests and direction through the PM instead, even when it would be faster to just tell the engineer yourself.
4. Make decision rights explicit
“Own product” sounds clear until a real disagreement appears. If the boundaries stay implicit, both sides tend to make the safest possible assumption: the PM asks for approval too often, or makes a call they believe is theirs only to have it reversed without warning. Write down the initial decision rights, even if they’ll evolve, and watch for the quieter version of the same problem: a founder who wins every argument by default, simply because they have more context and authority, teaches the PM to stop pushing and loses the second opinion they hired them for. I’ll go deeper on this, with a decision-rights map template, in a future edition.
5. Don’t split strategy from execution
Founders also fall into a related trap: dividing the work cleanly in two, with the founder doing the strategy and the PM executing it. It’s tempting, and it isn’t entirely wrong, but treating it as a hard line turns the PM into a delivery function and wastes most of what you hired them for. Better to split by scope than by activity: give the PM a real end-to-end slice of the product, a major feature area, for example, where they own both the strategy and the execution, and expand what they own as they prove themselves. I’ll dig into how much strategy a first PM should actually own in a future edition.
6. Share the evidence behind your conclusions
Founders try to save time by giving the PM the answer. “We need this feature for enterprise.” The conclusion may be right, but if you share only the answer, the PM can’t learn how you reached it or develop the judgement to make similar decisions independently.
Share the underlying evidence when you can. Invite them to customer and sales calls. Forward the difficult support conversations in full, so they see more than a tidy summary. Explain which experiments failed and why. Show them where your confidence is high and where you’re guessing, and talk through an important decision before announcing the answer. This may feel slower at first, but it’s how the PM becomes faster later.
7. Give feedback while it’s still useful
Many founders delay feedback because they’re busy, uncertain, or trying to give the PM space. The PM experiences the silence differently. They may assume they’re doing well, or sense dissatisfaction without understanding its cause. By the time the founder raises a concern, weeks of avoidable frustration have piled up.
Early feedback should be frequent, specific, and tied to real work. Instead of saying, “Be more strategic”, discuss the recommendation they just made. Which part was strong? Which context was missing? Where did their judgement differ from yours? Was the problem in the decision, the reasoning, or the communication, and what should they try differently next time? Do the same when the work is good. If the PM only hears from you when something is wrong, they can’t tell which behaviours to repeat.
8. The first PM shouldn’t have to grow alone
It’s just as easy to fall into a different trap here: leaving the first PM to grow alone. In an established product organisation, a PM has experienced product leaders around them to review a strategy or help interpret difficult stakeholder feedback. The first PM at a startup often has none of that, and the founder rarely has the time or product background to fill the gap alone. Founders should decide deliberately where that support will come from, whether that’s an advisor, a peer, or a coach. I’ll go deeper on this in a future edition.
The whole handover works the same way. A first PM gives a founder more leverage, but only if the founder does their part: sharing context, clarifying authority, and giving the PM room to grow into the role. The founder’s product job doesn’t disappear when the PM arrives. It changes from personally carrying every decision to creating the conditions in which someone else can carry more of them well.
I’m currently open to coaching a small number of first PMs at seed to Series A startups that have recently made the hire, working as an independent, confidential sounding board.
If you’ve hired your first PM, what’s been hardest about helping them succeed? Reply and tell me. I’d like to use what you’re wrestling with to shape future editions.