On August 10, Marty Cagan published A Fresh Definition of The Product Role. What makes it worth reading is that the definition is not his. He found it in an article by the technology analyst Benedict Evans called "Most People Aren't Tool Builders" — a piece that, as Cagan notes, was not trying to define the product role and barely uses the word product. The line that anchors the whole argument is this one, from Evans: "Writing the code isn't the hard part, and making the tool isn't the hard part — the hard part is knowing that it should exist, and knowing how it should exist, and that's a different person."

Three skills, and none of them are building

Evans describes three distinct capabilities that separate someone who can create a good tool from someone who is merely good at using one. First, seeing the general problem behind a specific pain — lots of people notice friction, far fewer can name the underlying problem worth solving. Second, discovering a solution that actually works for the customer. Evans puts it sharply: "You have to know a lot about sales to make good sales software, but being good at sales does not make you good at making sales software." Third, discovering a solution that also works for your business — the constraints across legal, finance, support, compliance, and legacy systems that most solutions eventually collide with. Cagan maps these directly onto vocabulary his readers already have: problem discovery, then value risk, then viability risk.

The admission buried in the middle

The most interesting paragraph in the essay is not the definition. It is Cagan revisiting his own Era of the Product Creator piece from a year earlier, where he welcomed the new tools that made product creation dramatically cheaper and said he expected to see many more strong product creators as a result. His verdict now: "That's been maybe a little bit true, but not anywhere near what I had hoped for." That is a fairly direct statement that better tools did not manufacture better product judgment. The tools scaled output. Judgment did not come along for the ride.

Why this matters beyond the job description

Evans' original point is about customers, not product teams, and it is the part most likely to change a roadmap. Product people keep assuming their customers will use AI the way they themselves use it — that if you hand everyone the ability to automate their own workflows, they will. Evans argues they mostly will not: "AI makes it easy for anyone to build tools to automate their work... except most people and most companies aren't tool-builders, don't think like that, and can't and won't do that. This is why software companies and consultants exist — AI changes the thresholds but not the problem." If you have been sizing a market on the assumption that AI turns your customers into builders, that assumption deserves a second look.

If judgment is the scarce input, where does it live?

Here is the operational consequence nobody in the PM tooling category is addressing. If the expensive, scarce, differentiating input is product judgment, and the cheap, abundant, commoditized input is execution, then the binding constraint on your team is how much of that judgment is accessible to the things doing the executing. Today, on most teams, it is not accessible at all. It lives in a product manager's head, in the reasoning behind a decision that was recorded only as an outcome, in a Slack thread from March. An agent can execute against a ticket. It cannot execute against an intuition that was never written down.

What making judgment legible actually requires

This is more specific than "write better documentation." The three skills Evans describes each produce a distinct artifact, and an agent needs all three to produce work worth acting on.

Problem framing — the general problem behind the pain, stated explicitly, separate from the solution you happen to favour.
Value evidence — what you learned in discovery, what you ruled out, and what you are still assuming.
Viability constraints — the legal, commercial, and technical boundaries the solution has to live inside.
Success definition — what changes in customer behaviour if this works, expressed as something measurable rather than as a ship date.
Non-goals — the decisions you have already made against, which is the artifact most teams skip and the one that prevents the most rework.

What this does not fix

Worth being honest here: writing judgment down does not create it. If nobody on your team can see the general problem behind the pain, no artifact, template, or tool will conjure that skill into existence — and Cagan's essay is largely a reminder that the skill remains rare. What a written operating model does is narrower and still valuable. It makes judgment that already exists transferable to people who joined last month, checkable by someone who disagrees, and readable by an agent that would otherwise infer intent from a backlog. That is a real gain, but it is a multiplier on judgment, not a substitute for it.

Where Delvyn Studio fits

Delvyn Studio exists to be the place that judgment gets written down in a form execution can use. Vision, strategy, discovery evidence, and OKRs stay connected as a live chain rather than four documents that drift apart, and that chain is what feeds agent specifications through the MCP layer. We are not claiming to make anyone better at product. We are claiming that if you have done the thinking, there should be somewhere for it to live other than your head — and that once it lives there, every agent downstream produces work that is closer to correct.

The category's current answer to AI is to generate more output, faster. Cagan and Evans are both pointing at the opposite end of the pipeline. If the hard part was never the building, then the tools that matter next are the ones that improve what gets built on purpose — not the ones that shorten the distance between a vague idea and a well-formatted document.

The Hard Part Was Never the Building