Chapter 9 Appendix: Reading the room in 2026
This book expires. The tools change. The jargon changes. The power dynamics don’t.
So this appendix is two things: a buzzword decoder, so you can stop nodding along to nonsense; and an interview kit, so you can test whether a team actually does PM work or just has “PM” in the job title.
Use it before you take a job. Use it after you quit one.
9.1 A. Buzzword decoder: 2026 edition
PMs speak in code. Half of it is useful shorthand. Half of it is cope. Here’s how to translate, post-AI.
| They say | They mean | What to ask | Red flag if |
|---|---|---|---|
| “AI-native” | We added a chatbot to the settings page. | What decision does the model make without a human in the loop? | Answer is “it summarizes content.” |
| “Agent” | We put a model in a while-loop and called it a product. | What happens when it’s wrong? Who gets paged at 2am? | Answer is “we haven’t fully thought through that.” |
| “0 to 1” | We have no users and the definition of success is unclear. | What did the zero users tell you? What counts as 1? | Answer is “we’re pre-PMF” with no further specifics. |
| “Platform” | We have three features and a hope that others will build on them. | Who builds on this today, besides your own teams? | Answer is “we’re building toward that.” |
| “Flywheel” | We drew a circle on a whiteboard. | Walk me through the specific input metric and loop mechanic. | Answer involves the word “network effects” with no mechanism. |
| “Customer-obsessed” | We did two user interviews last quarter. | What did you learn that changed a roadmap decision? | Answer is “users really love what we’re building.” |
| “Data-driven” | We have a dashboard that runs automatically. | What decision did the data change in the last sixty days? | Answer is “we’re monitoring it closely.” |
| “Founder mode” | No process, no accountability, the founder decides everything including your vacation. | Who says no to the founder, and when was the last time it happened? | Answer is “the founder has really high standards.” |
| “Influence without authority” | Nobody listens to you and it’s framed as a growth opportunity. | Who gets fired if this product fails? | Answer is “it’s a team outcome.” |
| “Full-stack PM” | We need you to also do design, data, and some light engineering. | What gets deprioritized when your PM work expands? | Answer is “we’re lean so everyone wears multiple hats.” |
| “Player-coach” | You manage two people and also own a full product surface. | Which role takes priority when they conflict? | Answer is “we trust you to manage that.” |
| “Leverage” | I attend a lot of meetings. | What did you ship last quarter that still runs without you? | Answer is “the roadmap.” |
Rule: If you cannot diagram it on a napkin, it is not real. If they cannot answer “who gets paged when it breaks,” it is not real. If the answer to every question is “AI,” leave.
9.2 B. Interview questions to ask them
The interview is two-way. They’re testing whether you can do the job. You’re testing whether the job exists.
Ask these. Stop if the answers are bad. Bad answers are data.
9.2.1 “Walk me through a decision the team made last month. What was the alternative? Who disagreed?”
Why: PMs live in decisions, not in artifacts (Cagan 2017). If they cannot name a recent, real one with a named dissenting view, there is no PM work happening. There is project management, possibly with a roadmap.
Green flag: “We were going to build X. Engineering pushed back because of a platform constraint. We switched to Y. Here’s the doc.”
Red flag: “We’re data-driven, so the data led us to the decision.” The data does not have a badge. Someone made a call.
9.2.2 “What got killed last quarter? Who killed it? How?”
Why: Shipping is easy. Killing is hard. Teams that cannot kill ship museums of half-finished features.
Green flag: “I killed it. Here’s the writeup I sent. Here’s who was mad. Here’s how it ended.”
Red flag: “We don’t really kill things — we iterate.” That’s how you end up with forty tabs in your product and no coherent user story.
9.2.3 “Show me the last post-mortem. What changed because of it?”
Why: Teams without blame have no learning. Teams with blame and no change have politics and no learning. You want both blame and change.
Green flag: “We were wrong about the activation assumption. So we stopped doing X and started doing Y in how we measure onboarding.”
Red flag: “We do blameless post-mortems.” There is no blameless post-mortem. Someone is always held responsible. If not named explicitly, the accountability lands on the most junior person in the room. Call it what it is.
9.2.4 “If I join, what am I saying no to in month one?”
Why: PM scope is defined by what you choose not to do as much as what you do. If everything is in scope, nothing is. If they can’t name it, either the role has no scope or they haven’t thought about it, both of which are problems.
Green flag: “You’ll be saying no to these three request categories. They’re noisy and they’ll come immediately.”
Red flag: “You’ll figure out the scope as you go.” Translation: nobody owns this, and you’ll spend six months in a territorial dispute before anything gets done.
9.2.5 “Who will be frustrated with me in ninety days, and why?”
Why: PM is conflict-adjacent work. If the answer is “nobody,” they’re either lying about the role or describing a role where no one cares what you do.
Green flag: “Sales will push back because we’re not building their top three requests. Here’s why we’re not, and here’s what you’d need to tell them.”
Red flag: “We’re all really aligned here.” Nobody is ever all aligned. What they mean is that the conflict is currently undiscussed.
9.3 C. Interview questions they’ll ask you (post-AI edition)
Behavioral questions are easier to prep now. AI can draft a STAR response in ninety seconds. Interviewers know this. The questions that matter now are the ones that require real-time thinking.
9.3.1 “Here’s our product. You have one hour. What would you change and why?”
What they’re testing: Can you pick a problem without being handed one. Can you scope and prioritize quickly. Can you use AI to move fast without being fooled by surface-level analysis.
How to prep: Do this on five products a week. For real, not in your head. Write the one-pager. Don’t send it. Build the muscle.
9.3.2 “Variant A versus variant B. A wins by 2%. Ship it?”
What they’re testing: Statistical literacy, cost-of-delay reasoning, opportunity cost awareness. “Ship it” is the wrong answer. “It depends” is right — and then you need to explain what it depends on specifically.
Strong answer structure: “What’s the confidence interval? What’s the cost of waiting to get more data versus the cost of being wrong? What are the guardrail metrics?” Then give an actual recommendation.
9.3.3 “The CEO wants this feature. Data says it won’t work. Engineering says it might. What do you do?”
What they’re testing: Conflict navigation under real authority gradient. There is no clean answer. The wrong answers are clear: “Do what the CEO says” and “Do what the data says.”
Strong answer: “I’d write the one-pager for why the data gives me pause. I’d share it with the CEO before the decision is public. If they still want to proceed, I’d scope the smallest version that definitively tests the assumption within thirty days. Then I’d own the result either way.”
9.3.4 “Use AI to critique something you’ve built or written. Walk me through what it said and what you did with it.”
What they’re testing: Can you use the tool, handle disagreement from a model without dismissing it, and stay calibrated about when the model is right versus when your judgment overrides it.
How to fail: “The AI was wrong.” The AI is sometimes wrong. What matters is whether you can say specifically how it was wrong and why you overrode it.
9.4 D. The 30-60-90 for your first PM job
You got the job. Now the actual work begins.
First 30 days: Learn without shipping
Don’t ship anything. Don’t propose anything. Don’t have opinions yet in public. Do:
- Kill something small. A dead dashboard. A zombie feature. A recurring meeting with no output. This teaches you more about the team’s tolerance for change than any onboarding doc.
- Write three teardowns of the product — privately. What’s broken, for whom, and what you’d measure. Don’t share them yet. You’re calibrating, not performing.
- Learn who actually decides things, which is not who the org chart says decides things.
First 60 days: Ship something small that wasn’t your idea
Find something Engineering wanted but couldn’t prioritize. Something Design had mocked up and nobody scheduled. Clear the path for it to ship. Get a win. Get trust. Then share one of your teardowns with a person who can engage with it honestly.
First 90 days: Say no to something big
With a document. With data. In a room full of people who expected a yes.
If you can’t do this by day 90, you’re not a PM yet. You’re a well-organized note-taker. Ask for the scope that requires you to have a position, even if that means asking for less scope temporarily to do one thing with conviction.
Rule: If you’re not uncomfortable by day 90, something is wrong with the scope. Either ask for more, or ask for different. But ask.
9.5 E. The last question
You’ve read the book. You did the exercises. You know the paths.
One question remains:
Is the daily experience of this work — the inbox, the no, the room, the story, the call, the calendar — the experience you want to accumulate?
Not the outcomes. Not the title. Not the compensation range. The daily experience.
If yes, the path is already in front of you. Everything in Chapter 7 is operational from here.
If no, the path is also in front of you. Chapter 7 mapped the exits too.
The goal was never “decide to be a PM.” The goal was to know clearly — not as a rationalization, not as a plan B backup — what kind of work you want to do and whether this is it.
You either know now, or you know you need more evidence. Both are good outcomes for a book.
References