Chapter 3 How PMs think
Engineers think in systems. Designers think in users. PMs think in tradeoffs.
AI makes generating options cheap. It makes choosing expensive — because now you’re always choosing from a larger set, with less time to interrogate each option, against a model that will argue persuasively for whichever one you’re leaning toward.
The mental moves that define PM work were always there. They’re more exposed now.
3.1 1. Problem first, not solution
Bad PM: “We should add an AI assistant.”
PM: “Support tickets about onboarding are up 30% month-over-month. Half are ‘where do I start?’ What’s the smallest thing we can test to see if better guidance cuts that in half?”
AI will generate twenty assistant designs. It will not tell you whether an assistant is the right answer to the problem, whether the problem is worth solving, or whether the spike in support tickets is actually a lagging indicator of a pricing change your sales team made in March.
The discipline is writing the problem statement before you let yourself think about the solution. Not because you’re not creative. Because solutions are seductive and problems are hard, and the model is very good at making bad solutions look reasonable.
Test: State the problem you’re working on right now without describing any UI, any feature, any technical approach. Just the problem, for whom, and at what scale. If you can’t do that in two sentences, you’re not working on a problem yet. You’re working on a solution to an assumed problem.
By context:
Startup. The problem is easy to identify and easy to misidentify. Customers will tell you what they want. They will not tell you what they need. The discipline here is the weekly ritual: what did we learn, and does it change the problem statement?
Scale-up. There are now many problems, all legitimately real, competing for finite quarters. “Problem first” becomes “which problem first” — and the answer is not whichever one your largest customer asked for loudest, and not whichever one appears in the most tickets. It’s the one whose solution compounds.
Mega-corp. The problem has already been defined by someone above you, often in an OKR that was written to survive a planning process, not to describe reality. “Problem first” at this scale means having the courage to say “this is the stated problem, here is what I believe the actual problem is, and here is why the gap matters.”
3.2 2. Leverage over output
Shipping is not the goal. Shipping things that compound is.
2015 leverage: Write a spec so five engineers build the right thing.
2026 leverage: Write a prompt so five engineers plus five agents prototype five variants. Then kill four before they become technical debt.
Your job moved up one abstraction layer. You don’t manage execution. You decide which experiments are worth running and which results are worth building on (Doshi 2024). The model can run experiments faster than you can think of them. Your edge is knowing which experiments answer a question worth asking.
Test: If your team doubled in size tomorrow, would you ship twice as much? If yes, you’re managing output. If no — if the bottleneck is decisions, not hands — you might be working on leverage.
By context:
Startup. Leverage looks like killing things. You can generate more ideas and prototypes than you can evaluate. The PM who kills bad ideas before they consume engineering time is creating leverage. The PM who says yes to everything because “we should test it” is destroying it.
Scale-up. Leverage looks like infrastructure. The prioritization framework that your team uses without asking you. The metrics dashboard that answers the recurring question. The template that removes the first two hours from every planning cycle. These are leverage. They compound.
Mega-corp. Leverage looks like influence. The relationships that let you short-circuit a six-week review into a thirty-minute conversation. The platform investment that five teams can build on instead of building five parallel systems. The standard you set that other teams adopt because it worked.
3.3 3. Sequencing is strategy
Roadmaps are lies. Sequences are truth.
AI can generate “Q1: Auth. Q2: Sharing. Q3: AI features.” It cannot tell you that if Auth slips, Sharing is worthless, but that if Sharing ships early, you learn whether the AI feature is even needed — or whether users care about sharing at all.
Sequencing is understanding the dependency graph of your bets. Not just which things need to be built before which other things, but which things need to be learned before you know whether to build the next thing. The question is not “what order should we build this in?” It is “what order of learning is cheapest?”
Test: Draw your roadmap on a napkin. Now cross out 50% of it. Does the remaining 50% still make sense as a plan? If yes, you had a sequence. If no, you had a list dressed as a roadmap.
By context:
Startup. Sequencing is survival. The wrong order of bets can burn runway on the wrong thing while the market moves. The right sequence is usually: what is the cheapest test of the riskiest assumption?
Scale-up. Sequencing now has organizational weight. Teams have been staffed against the roadmap. Platform dependencies have been scheduled. Sequence changes create ripples. The discipline is knowing which changes are worth the ripple and which ones should wait for the next planning cycle.
Mega-corp. Sequencing is political. What gets resourced first signals what the organization believes matters. Changing the sequence after planning is locked requires executive air cover or documented evidence of a bet going wrong. Both are available. Neither is free.
3.4 4. Calibrated conviction
You need a view. AI will validate any view you give it.
This is the most dangerous thing about working with LLMs in product work. It is not that they give you wrong answers. It is that they give you confident wrong answers — and that if you prompt them with your hypothesis, they will generate evidence for it. You can now build an airtight case for almost any product decision in thirty minutes. That used to require weeks of work, which forced you to encounter disconfirming evidence along the way. The friction was epistemically useful.
Calibrated conviction means: you have a strong view, you can defend it, and you have pre-committed to the evidence that would change your mind. Not evidence that might change your mind. Not “I’m open to feedback.” Specific, observable evidence. “If 40% of users complete the onboarding flow without help in the first two weeks, we were right. If not, we were wrong about the problem and will rebuild from what we learn.”
Test: For the thing you’re currently building: what evidence would make you stop, before launch? If you don’t know the answer before you ship, you’re not running an experiment. You’re shipping a preference.
By context:
Startup. Conviction is a survival mechanism. Nobody will follow you into uncertainty if you don’t project confidence. But uncalibrated conviction kills companies. The founders who survive are the ones who hold conviction loosely enough to update when the data comes in and firmly enough that the team doesn’t lose faith during every weekly review.
Scale-up. You now have enough data to be wrong with confidence. The models can rationalize. The dashboards can be selectively read. The discipline is running pre-mortems — before you ship, before the case is built, before you’ve started to fall in love with the idea.
Mega-corp. Conviction has to survive a bureaucracy designed to sand it down. Legal review, policy review, exec review, regional review. By the time something ships, the original insight can be unrecognizable. The discipline is writing down what you believed and why before the process starts, so you can compare it to what shipped and learn from the delta.
3.5 Try this
Exercise: Pick one metric your team cares about. DAU, revenue, activation rate, anything with a number.
Use AI to generate ten ways to move it 5% in the next quarter.
Now kill nine of them. In writing. For each one, explain specifically why it’s the wrong bet right now — not in general, but for your product, your users, your constraints.
The one you kept: write the evidence that would prove it wrong within thirty days of shipping.
If you couldn’t kill nine, you don’t have a strategy. You have a list. If you enjoyed killing nine, keep reading.
Chapter 4 covers the people you’ll be having these arguments with — and how AI shifted the power dynamics in every one of those relationships.