Cagan's Definition Is Right. The Weights Are Wrong.

Marty Cagan published a piece last month titled "A Fresh Definition of The Product Role." I read it expecting a new definition. That is not what is in it, and the reason why is more interesting than a new definition would have been.

What he does is take three skills he credits to Benedict Evans, from an article of Evans's called "Most People Aren't Tool Builders," and map them onto the framework he has used for two decades. Recognizing the general problem sitting behind a pile of specific pain becomes problem discovery. Being able to create a good solution, which he is careful to distinguish from being good at using someone else's tool, becomes value risk. Understanding what a solution means across sales, marketing, finance, compliance, and the legacy systems nobody wants to touch becomes viability risk.

The mapping is the argument. Cagan is saying the definition did not need to change, and that the thing everyone is calling a revolution slots neatly into vocabulary he already had.

He is right about that. I think the definition is right and the weights are wrong. The short version of what he actually published, without my argument on top, is here.

The short version

Cagan's August 2026 piece maps Benedict Evans's three product skills, problem discovery, solution discovery, and business viability, onto the risk framework SVPG has used for years, and concludes the product role's definition survives AI intact. The skills do survive. What does not survive is the assumption that they are one job in roughly equal parts. Solution discovery is the most AI-exposed skill in product work, because generating options is now free and the surviving skill is selection rather than generation. Problem discovery is intact but its input changed, since listening agents remove the bottleneck on how much pain one person can personally hear. Business viability barely moved, which is exactly why it is becoming the majority of the job: it is a consent problem across a company, not an information problem, and consent does not compress. A definition that does not say which third is growing is accurate and not actionable.

A threshold is not a detail

The load-bearing sentence in Cagan's piece is eight words long: AI changes the thresholds but not the problem.

I have a lot of sympathy for it. It is the correct answer to most of the noise, and Cagan has earned the right to be unimpressed by a new tool. It is also the same shape of argument I picked apart two days ago when everyone read the Miro sale as pure valuation compression. Compression was real and it explained the range. It did not explain the position inside the range, and the position was where the product story lived.

Here it is the same move. Yes, the abstract problem statement survives. Somebody still has to know that a thing should exist and how it should exist. But a threshold is not a detail of a problem. A threshold is what determines the shape of the organization built around the problem. Dual-track discovery, the empowered team, the trio, the PRD, the quarterly planning cycle, the leveling rubric: none of those are the problem. All of them are structures calibrated to a specific cost of being wrong. Move that cost by two orders of magnitude and every one of them is wrong in its particulars while the sentence describing the problem reads exactly the same.

Saying the problem is unchanged is true. It is also how you talk yourself out of noticing that everything built on top of it has come loose.

Three skills, three different futures

Here is what the definition hides by treating the three as one role.

Solution discovery is the most exposed thing in product work. Not because a model has taste, it does not, but because the expensive half of that skill was generating candidates at all. Producing a credible option used to take a designer a week and an engineer a sprint. It now takes an afternoon, and you can have twelve. What remains scarce is choosing, and choosing is a different skill with a different training path. The profession has twenty years of people who got good at producing options and almost nobody who got deliberately good at killing them. Twelve directions is not twelve times the thinking, and a reviewer cannot tell the difference by looking, which is a problem I have written about from the design review side.

Problem discovery is intact, and its input changed underneath it. Evans's framing is that most people can feel pain and even propose fixes, but recognizing the general problem behind the specific complaint is rarer. That is true and it stays true. What moved is the sample. That skill was always bottlenecked on how many pains one human could personally hear, which is why the canonical advice is a weekly interview cadence: it is the most listening a person can sustain. A listening agent hears every ticket, call, churn survey, and rage click. The skill is unchanged. The volume it operates on is not, and a skill that was practiced on twelve conversations a quarter behaves differently when it is practiced on everything.

Business viability barely moved, and that is the whole point. Legacy systems, procurement, compliance, legal, the finance conversation about what happens to gross margin when your product bills per outcome. None of it compresses, because none of it is an information problem. It is a consent problem across a company, and consent runs at the speed of people in rooms. Which means that when the other two thirds of the job get dramatically faster and this third does not, it becomes the majority of the calendar by arithmetic alone.

Nobody is hiring for that. Go read product job descriptions this week. They are still weighted toward the third that is deflating fastest.

Where this leaves the Product Builder argument

I wrote a long piece in June about where Cagan's model holds and where mine breaks, and I am not going to relitigate it. But this one clarifies something I had not said cleanly.

The Product Builder argument was never that the three skills stop being necessary. That would be a stupid claim and it is the version critics like to argue against. The argument is about residence. Those three skills were split across a PM, a designer, and a tech lead because coordinating them inside one head was harder than coordinating them across three people. That tradeoff was priced against a build cost. The build cost collapsed. So the coordination overhead, the handoffs, the specs written so one role could tell another what it had decided, stopped being worth what it costs.

Cagan and I agree the skills are required. We disagree about whether the org chart that carried them survives, and a definition of the role is exactly the wrong altitude to settle that at, because a definition describes what must be true and says nothing about who holds it.

There is one place his framing beats mine cleanly, and I will say it plainly. If viability really is the growing third, then the skill that grows is organizational, not technical, and organizational skill is the thing you accumulate by staying somewhere long enough to have made the mistake. That is a point for the twenty-year practitioner and against the person who is good with tools. The tool fluency I keep arguing for is necessary and it is aimed at the deflating column.

Try this week

Pull last quarter. Not the roadmap, your own calendar and your own output.

Split your hours three ways. Hours spent recognizing what the real problem was. Hours spent finding and choosing a solution. Hours spent making it viable inside your own company.

Then write the same three numbers for where you think they will be in twelve months.

If your biggest column is the one shrinking fastest, you have about a year, and the thing to go learn is the boring third.

This is one more entry in the running argument I keep on AI Product Management, which is that the job did not get harder. The parts we trained people to be good at got cheap, and the parts nobody trained for are what is left.

Sources: A Fresh Definition of The Product Role, Marty Cagan, SVPG, August 10, 2026. Cagan credits the three-skill framing to Benedict Evans's article "Most People Aren't Tool Builders," which sits behind a paywall; Cagan links a podcast episode where Evans discusses it.