Chapter 8 What comes next
You’ve done the exercises. You picked a direction.
This chapter is short. It doesn’t congratulate you on a decision that’s barely begun. It gives you two things: how to stay in the job if you chose it, and how to leave it well if you didn’t.
Both matter. The PM who burns out after two years because they didn’t know how to protect what they had built is a waste. The person who decided PM wasn’t for them and spent three more years chasing it anyway is also a waste.
8.1 If you’re in: How to not get fired
You decided the work is for you. The exercises landed right. Now you have eighteen months — give or take — before the job shifts enough that what got you in isn’t enough to keep you there (Rachitsky 2023).
Here is how to use them.
8.1.1 Ship every quarter
Your title doesn’t matter. Your LinkedIn doesn’t matter. Your docs don’t matter.
What shipped — to users, not to your manager’s slide deck — matters.
Startup: If you haven’t shipped in ninety days, you are dead weight. AI makes ninety days an eternity. Your target is thirty. Ship in thirty, learn in thirty, kill in thirty if it’s wrong. The company does not owe you a full quarter to find your footing.
Scale-up: If you haven’t shipped in a quarter, your team is getting reorged. You’ll find out from a calendar invite. The only protection against the reorg is recent, visible impact — users who changed their behavior because of something you shipped.
Mega-corp: If you haven’t shipped in two quarters, your scope is shrinking. You won’t see it happen directly. Your manager will give you slightly less context in the weekly sync. Someone else will be invited to the meeting you used to own. Ship before it reaches that point.
Test: Open your calendar from six months ago. What changed in the product because of a meeting you were in? If the answer is “nothing I can trace directly,” fix that this quarter.
8.1.2 Have a take
AI generates consensus. Consensus is safe and it is late. Your job is to have a view before the model does, before the team does, before the data fully supports it — and to hold it with enough clarity that the team can aim at something rather than at a distribution of possibilities.
You will be wrong sometimes. That’s fine. PMs who are never wrong are PMs who only make calls that are obvious, and the obvious calls don’t need a PM.
Startup: If you don’t have a take, the founder does. You’ve just become project management.
Scale-up: If you don’t have a take, the engineering lead does. Same outcome. You’re coordination overhead, not judgment.
Mega-corp: If you don’t have a take, three other PMs do. You’ll lose the scope one calendar invite at a time.
Test: State why your product exists in one sentence. No jargon. No “platform.” No “AI-native.” No “ecosystem.” If you can’t, you don’t have a take. You have talking points.
8.1.3 Keep your network honest
The PMs who survive know other PMs. Not for job leads. For calibration.
“Am I crazy, or is this roadmap wrong?” The model will tell you you’re right. Another PM who shipped something similar last year will tell you the truth.
How: Send a PM you respect your current product teardown — what you’re building, why, what metrics you’re watching. Ask for their read. Not “feedback.” Their read. If they push back, engage with the pushback. The conversation is the value.
Startup: Your network is other founders and early PMs. Everyone is scared. The ones who admit it are the ones worth talking to.
Scale-up: Your network is PMs one or two stages ahead of you. The person who was at your stage six months ago is the most useful. They can see what you’re about to run into.
Mega-corp: Your most valuable network is the PMs who left. They can tell you what you cannot see from the inside.
8.1.4 Learn the new tedium
AI killed the old tedium: writing specs, formatting docs, pulling standard reports. Good.
New tedium replaced it: prompt hygiene, eval design, reviewing model outputs for confident errors, knowing when the embedding is stale, understanding why the demo worked in staging and failed in production.
You don’t need to become an ML engineer. You need to know enough to run the post-mortem when your AI feature fails without saying “the model was wrong” and sitting down. “The model was wrong” is the beginning of the investigation, not the end of it.
Test: Can you explain why your last AI-powered feature failed — without using the word “model” as the agent? If the answer is “the model hallucinated,” you need another sentence. What did it hallucinate? Why? What would you instrument differently next time?
8.2 If you’re out: How to leave cleanly
You did the exercises. You felt mostly dread. You’ve read Chapter 7 and found the adjacent role that fits better. Good.
Here is how to leave without three wasted years in between.
8.2.1 Don’t call it failure
PM is not a better job. It is a specific configuration of work: conflict, ambiguity, narrative, accountability for outcomes you don’t fully control.
If that configuration doesn’t fit you, you are not less ambitious. You are calibrated. The people who do the job well are the ones who, for whatever combination of disposition and background, find that configuration energizing more often than draining. You found that yours is the opposite. That is information about job fit. It is not information about your ability to do hard things.
Architect? didn’t tell people who decided against architecture that they’d made a small choice (Crites and Ward 2014). It said: here is the work, and here are other places where similar instincts might land differently.
8.2.2 Use what you learned
The exercises you did are not PM-specific. The triage tolerance you tested in the inbox exercise, the position-holding you tested in the no exercise, the comfort with uncertainty in the call exercise — these show up in every professional role, in different proportions.
The role you move into will have its own version of each. Knowing your baseline on all of them is worth more than whatever you can put on a résumé.
If you built anything — a prototype, a teardown, a tool — keep it. It demonstrates the thing most adjacent roles actually want: someone who makes something when they see a gap, rather than waiting for someone else to define the spec.
8.2.3 Don’t keep chasing it
The MBA who does PM internship after PM internship hoping it will eventually feel right is not doing research. They are hoping that persistence will change their disposition.
It won’t. Disposition changes slowly and through experiences that are not “try the same thing again.” If three real attempts at PM-type work have produced the same feeling, the sample size is sufficient.
Go do the adjacent thing that pulled at you in Chapter 7. Do it with the same seriousness you would have brought to PM. The domain doesn’t matter as much as the fit.
8.3 For both
Whether you’re in or out, one thing is true: the job will keep changing.
Eighteen months from now, the tools will be different. The interview questions will be different. Some of what this book described as “AI’s impact” will be so embedded in standard practice that it won’t need to be named. Something else will be the new thing everyone is figuring out.
The underlying job — deciding what’s worth building, for whom, using what resources, and holding the team together through the uncertainty — will still be there. It was there before AI. It will be there after whatever comes next.
The last question is not about PM. It’s about you.
What kind of problem do you want to spend your time on?
Not “what do I want to accomplish.” Not “what do I want to be known for.” What kind of daily work, what kind of daily friction, what kind of daily satisfaction — is worth the cost of showing up?
If the exercises in Chapter 6 pointed you toward that answer, use it. If they pointed you away from PM and toward something else, that direction is just as valid.
The goal is not to become a PM. The goal is to find the work where the daily experience of it — the meetings, the decisions, the conflicts, the moments of clarity — is the kind you want more of.
Stop reading. Start looking.