Preface
In 2015, you could figure out product management on a long weekend. Read a couple of blog posts — Shreyas Doshi on thinking in systems, Ken Norton on hiring PMs, the old Joel Spolsky essays about working with engineers. Shadow a PM at a company that would let you shadow one. Write a product requirements document badly, then less badly. Apply to jobs. Get one.
That path is gone. Not because the blog posts were wrong. Because the job moved.
I don't mean the job title moved or the compensation bands shifted or the org charts got reorganized. I mean the actual work — the thing you do with your hours, the skill that earns you a seat at the table, the reason a company employs a PM instead of just letting engineers and designers make product decisions themselves — that work is substantively different today than it was ten years ago, and it will be more different still by the time you finish reading this.
Let me be specific about what moved and why, because vague claims about AI changing everything don't help you decide anything.
What actually changed
The first version of this book was roughly two hundred and fifty words. I wrote it fast, in one sitting, the way you write something when you're certain of it. The core claim was simple: the job moved up one abstraction layer. What I didn't do — because two hundred and fifty words doesn't leave room — was explain what that means in practice, why it happened, and whether you'd actually enjoy living inside that change.
So start here. A junior PM in 2015 spent meaningful portions of their day on tasks that required skill but not judgment: writing detailed acceptance criteria, creating competitive comparison matrices, pulling basic product analytics, synthesizing user research notes, wireframing flows in Balsamiq or Sketch, writing tickets. These weren't trivial tasks. Done well, they communicated clarity. Done badly, they created confusion. But they were learnable, and learning them was how you built the muscle to eventually do the harder work.
That ladder is largely gone. A junior PM with access to a good AI assistant — and by 2026, every PM has access to a good AI assistant — can produce in an afternoon what used to take a month. Competitive analysis that once required hours of structured research: drafted in twenty minutes. User research synthesis across fifty interview transcripts: done. Prototype flows: generated. PRD structure: scaffolded. The output quality varies; you still need to edit, judge, and refine. But the volume of time spent on production work has collapsed.
This sounds like pure gain. In some ways it is. But consider what it displaced.
That production work was how PMs learned. You learned what questions mattered by writing fifty tickets and noticing which ones engineers ignored. You learned what users actually said — not what you wanted them to say — by spending ten hours reading interview transcripts. You learned where your product had architectural seams by drawing out every edge case in a flow diagram. The tedium was the curriculum. The hours were the education.
Junior PMs entering the field now skip most of that curriculum. They go straight to output. And the output looks competent — often it is competent — but it can be competent without the person producing it understanding why it's competent or knowing how to course-correct when it isn't.
This is the first thing that changed: the apprenticeship broke.
The power shifted — but not toward PMs
Here's the part of the AI-and-PM conversation that almost everyone gets wrong: they assume AI empowers PMs relative to their teammates. It doesn't. It empowers everyone roughly equally, which means the old PM advantages don't hold the way they used to.
A PM in 2018 held a structural information advantage. You were the person who had read the user research and the business metrics and the competitive landscape. Your engineers were experts in the codebase; your designers were experts in interaction patterns; your data scientists were experts in the model. You were the generalist in the room. That generalism was leverage.
Now your engineers can prompt their way to a competitive analysis in fifteen minutes. Your designers can pull their own analytics. Your data scientists write their own user story summaries. The AI gave everyone access to the information-gathering work that used to justify a PM's presence in the room.
What this means is that the parts of PM work that were always invisible — judgment, conviction, the willingness to be wrong in front of people and keep going — are now the whole job. The scaffolding that used to surround those invisible parts, and in some ways obscure them, is gone. You're left standing in a room, and the question is: can you actually do the thing that matters?
The thing that matters is deciding. Not in the sense of having the authority to decide — that's organizational politics, a different problem. Deciding in the sense of taking a pile of incomplete, contradictory information and collapsing it into a direction that you're willing to defend. AI is extraordinarily good at generating options. It is not good at choosing. That asymmetry is where the modern PM's value lives.
Why I wrote the first version — and why I'm writing this one
I've been a PM for going on fifteen years. I've done it at startups small enough that "the product team" was me and a shared Figma file. I've done it at companies big enough that my metrics ran on infrastructure that served billions of people. I've PM'd hardware — actual physical objects that existed in the world and broke in ways software doesn't break, with supply chains and tolerances and the specific anxiety of knowing that a flaw in your spec will be manufactured into ten thousand units before you catch it. I've PM'd regulated products in cities that had strong opinions about what could move on their streets and how fast. I've PM'd platforms for merchants who weren't engineers and didn't want to be, who just needed commerce to work.
Each of those contexts taught me something different about what the job actually is. Not what PM blogs say it is. Not what job descriptions say it is. What it actually is — the texture of it, the parts that feel good and the parts that drain you, the skills that turn out to matter and the ones that turn out to be theater.
I wrote the first version of this book because I was tired of watching people discover too late that PM wasn't the job they thought it was. Not because PM is bad — I've loved most of it, and I think it's one of the genuinely interesting crafts in technology — but because the gap between the marketing version of the job and the actual job is large enough to be a real problem. People take PM roles expecting to be builders and find themselves in meetings. People take PM roles expecting autonomy and find themselves negotiating for every inch of roadmap space. People take PM roles because they heard it's the path to a CEO — which, for most people, it isn't, and the route through it is miserable if that's what you're actually trying to do.
The model I had in mind was a book called Architect? A Candid Guide to the Profession, published by MIT Press. That book doesn't tell you architecture is glamorous. It tells you what architects do all day, what kind of person tends to thrive in it, what the economic realities are, what gets lost from the romantic version when you actually do the work. It respects the reader enough to give them the information they need to make a real choice. I wanted to write that book for product management.
The first version was too short to do it justice. This version attempts to actually do it.
The question this book is answering
It is not: how do I become a PM?
There are dozens of resources for that. Courses, bootcamps, interview prep guides, portfolios of case studies you're supposed to build, mock interviews with people who used to work at Google and will charge you four hundred dollars an hour to tell you what CIRCLES stands for. That ecosystem exists and will serve you if what you want is tactical help getting hired.
This book is answering a different question: Do you actually want this job?
That sounds obvious. Of course you want it — why else would you be reading about it? But wanting a job and wanting to do the work that job consists of are two different things, and conflating them is expensive. Expensive in time. Expensive in the particular exhaustion that comes from doing work that doesn't suit you. Expensive in opportunity cost — all the things you didn't do while you were failing to become a PM or succeeding at becoming one but hating it.
The Architect? book asks: do you like the work, the problems, the person you become doing it? That's the right frame. Professions don't just give you a salary and a title. They shape how you think, what you notice, what you care about, who you become over a decade. The best PM I know thinks about everything as a problem of incentive design and user behavior — at a restaurant, watching a city block, reading a news story. That's what fifteen years of PM did to her thinking. It's not a costume; it's a restructuring.
So the question isn't whether PM is a good career. It's whether it's a good career for you — for your cognitive style, your tolerance for ambiguity, your relationship with authority, your need for visible creative ownership. And the only honest way to answer that is to show you what the work actually looks like, up close, on a Tuesday at 2 PM when the sprint is behind and the stakeholder is upset and the data is contradicting itself.
That's what this book tries to do.
What PM is not
Before I describe what product management is, I need to clear the field of the things it isn't, because the misconceptions are so durable that if I don't address them up front, they'll color how you read everything else.
PMs are not mini-CEOs. I know this framing is everywhere. Ben Horowitz wrote it. Every PM job description references it. It's the single most damaging idea in product management, and I want to be clear about why.
A CEO has formal authority. They can hire and fire. They can reallocate budget. They can override decisions. They are accountable to a board, which means they have someone to be accountable to in a way that has teeth. A PM has none of these things. A PM is accountable to everyone and has authority over almost no one. The PM "owns" the product in the sense that they're responsible for its outcomes — but they don't control the engineers who build it, the designers who shape it, the data scientists who instrument it, the legal team that constrains it, or the executives who ultimately fund it.
The mini-CEO framing is seductive because it sounds empowering. What it actually does is set up a mismatch between responsibility and authority that crushes people who aren't prepared for it. If you go into PM expecting to be a CEO, you will spend your career being confused and frustrated by the gap between what you think should be true (I own this, therefore I decide) and what is true (I own this, therefore I am accountable when others decide badly).
The right mental model isn't CEO. It's closer to editor. A great editor doesn't write the book. They understand what the book is trying to be, they help the author get there, they make hard calls about what to cut and what to develop, and they take some of the blame when the book doesn't land. They have enormous influence without formal authority. That's a more useful frame.
PMs are not the voice of the customer. This one is subtler. PMs do user research. They talk to customers. They synthesize feedback. But calling them "the voice of the customer" is both incorrect and counterproductive. It's incorrect because customer feedback is not a single voice — customers want contradictory things, prioritize differently, and tell you what they want rather than what they need. Synthesizing that into a useful signal requires judgment, not just collection. And it's counterproductive because it lets everyone else in the organization abdicate their responsibility to understand users. When only the PM talks to customers, you get products that a PM filtered rather than products that actually work.
PMs don't build anything. Another one. The romanticism around PM often includes an idea that PMs are somehow creative in the way that designers are creative or engineers are creative. This is true in a very limited and specific sense. PMs make decisions about what to build, which is a creative act of a particular kind. But they don't design the interface, they don't write the code, they don't run the query. The PM's primary output is not a thing. It's a decision, a direction, a maintained alignment that allows other people to build things without constantly renegotiating first principles. If you need to make something with your hands — or your direct creative vision — PM will frustrate you.
PM is not a stable job description. One thing I want to be direct about: what a PM does varies enormously by company stage, company type, team composition, and the specific PM's background. A PM at a twenty-person startup is doing something meaningfully different from a PM at a five-thousand-person company, which is different still from a PM at a platform company with a developer ecosystem. This book will point out those differences, but you should go in knowing that "PM" is more of a category than a job. The category is defined by accountability for product outcomes and the work of turning ambiguous problems into executable decisions. The specific shape of that accountability and that work varies more than most PM content acknowledges.
About the age of AI, specifically
I've been careful in this preface to describe AI's effect on PM work without being either apocalyptic or dismissive, because both failure modes are common and neither is useful.
The apocalyptic version: AI is going to eliminate product management. PMs will be replaced by AI systems that talk to users, synthesize feedback, generate specs, and run products automatically. This is not happening in the near term for a specific reason: the hard part of PM isn't information processing, it's judgment under uncertainty, and judgment under uncertainty requires accountability, and accountability requires a person. When the AI product strategy turns out to be wrong — and it will — someone has to own that, explain it, update the organization, and recommit to a new direction. That's human work, and it will remain human work for longer than most people predict.
The dismissive version: AI is just a tool, PM is PM, the fundamentals don't change. This is also wrong. The skill mix is shifting. The work that used to take time and served as PM's on-the-job training is being automated away faster than most practitioners have adapted to. The PMs who will thrive in the next decade are going to look different — in how they think about their leverage, what they spend their hours on, and what they consider their core competency — from the PMs who thrived in 2018.
The honest version is: AI changed the operating conditions of PM significantly, in ways that make the judgment-and-conviction parts of the job more exposed and more critical, while making the production and information-gathering parts faster and cheaper. If you liked PM because you liked writing PRDs, you will find less of that satisfaction available. If you liked PM because you liked deciding — really deciding, with incomplete information, against real constraints, and then living with the consequences — you will find more room for that than ever.
This book is partly about helping you figure out which of those you actually like.
How to use this book
Each chapter ends with an exercise. Do the exercises. Not because exercises are inherently useful — most professional development exercises are busy work dressed up as reflection — but because the question this book is trying to answer (do you actually want this job?) can't be answered by reading alone. You have to try the thinking, notice how it feels, observe whether you find it energizing or draining.
Some of the exercises are designed to surface a real answer quickly. They're calibrated so that people who will enjoy PM work tend to find them interesting, and people who won't tend to find them tedious or arbitrary. I'm not telling you which is which, because that would defeat the purpose. Pay attention to your reaction, not just your answer.
The chapters don't have to be read in order, but I wrote them to build. The first chapter — what PMs actually do — is the foundation. Everything else assumes you've read it. The later chapters on traits and thinking patterns are harder to interpret without the grounding of the first.
Finally: this book is written from my perspective, which is a specific one. I've been a PM in transportation, commerce, education, and advertising. I've worked at startups, scale-ups, and very large technology companies. I've managed hardware products and software products and platform products. But I haven't done everything, and my experience has shaped my views. Where I'm offering a general claim, I've tried to ground it in something more than personal anecdote. Where I'm offering a personal view, I've tried to flag it as such.
The job is worth understanding clearly. It's worth neither overselling nor underselling. Let's start with what it actually is.