Product Judgment Used to Live in Your Head. That No Longer Scales.

Updated September 13, 2026: revised the address example to show alternatives and owner reasoning, and clarified how judgment can enter through proposal review. All numbers and product context in that example are synthetic.

In 2020, Paul Adams wrote what is still the definitive piece on product judgment. Product judgment, he wrote, is the ability to predict what your customers need and ship the right solution for them. And there is exactly one way to build it. Talk to hundreds of customers. He'd done around 500 interviews at one company, 800 at another. The judgment lived in his head, earned one conversation at a time.

He was right. He's still right about how judgment is built. What the AI era changed isn't how you build judgment. It's what now has to happen to it once you have it.

That essay described a world where the hard part of software was building it. You carried judgment in your head, and then you spent six months and a team of engineers turning a sliver of it into a shipped product. Execution was the bottleneck. Judgment was the cheap input: the part that fit comfortably inside one experienced person's intuition, dispensed in standups and design reviews as the work unfolded.

That world is gone.

When building gets cheap, choosing gets expensive.

The bottleneck moved

The evidence is no longer anecdotal. A 2026 NBER study followed more than 100,000 developers who adopted AI coding tools; with the most autonomous of them, commits jumped 180%, and total usage of everything they shipped stayed flat. More code, more releases, the same number of people who cared. We pulled that thread in The Cost of Being Worth Using. And when a survey of 309 product leaders asked what AI changed about their work, one of them wrote the whole story in a sentence: delivery of code got fast; delivery of good decisions became the new constraint. That's The Bottleneck Moved. The same survey shows where the acceleration landed, and where it didn't: AI's impact rated high in engineering (50%) and design (45%), and barely registered in strategic planning (18%), discovery, or customer feedback loops (13%). It made the building faster and left the deciding exactly where it was.

Strip it down and you get a simple inversion. For thirty years, the bottleneck in software was the ability to build it. Judgment mattered, but it was rarely the rate limiter. You could afford to be a little wrong, because being right took just as long to ship anyway.

Now an agent can build the feature in the time it takes you to describe it. The cost of execution fell through the floor. The cost of being wrong did not. Ship the wrong thing now and you've simply been wrong faster, at scale, with confidence. The constraint is no longer can we build it. It's should we, and is this the right "it."

That question has a name. It's product judgment. And it just became the most expensive thing in the building.

The problem Adams's era never had to solve

The 2020 framing never had to account for one thing, because it couldn't have.

In a world where humans execute, judgment-in-your-head works fine. The person with the judgment is in the room. They wrote the brief, they're in the standup, they answer the hundred small questions that come up mid-build: no, not that edge case; yes, ship without that; actually the real problem is upstream. The spec is a starting point; the judgment fills the gaps in real time, conversationally, because the human holding it is right there.

An agent cannot read an unstated preference, but it can ask questions and propose alternatives. Those exchanges can happen before and during implementation. The risk is that the person holding the product context never sees the interpretation, or that their correction fails to reach the version being built.

So the thing that was a feature for thirty years (that good judgment could stay tacit, living in an experienced head and leaking out as needed) is now a bug. Tacit judgment doesn't delegate to a machine.

An agent with perfect context and no judgment builds the wrong thing, fast. Context isn't judgment.

The decision needs a durable record: what problem, for whom, with which outcome, and what must not break. That record can begin as an agent’s proposal. The product owner brings judgment by questioning its interpretation, resolving alternatives, and approving the revised behavior. They do not have to write a complete specification before that conversation can start.

What good and bad product judgment look like now

A broad request such as “Improve onboarding” can be a useful starting point. It becomes risky when a plausible interpretation passes into implementation without the team examining the choices inside it.

Consider the address step in signup. In this illustrative scenario, the funnel shows 35% drop-off and 6 of 8 usability participants hesitate while entering six fields. Those synthetic observations suggest that entry effort may contribute. They do not establish the cause or prove that autocomplete is the answer.

The agent proposes address suggestions. The owner asks: “Do we need the address now?”

Three choices become visible. Remove address collection, ask later, or make entry easier. In this scenario, signup includes arranging a first shipment, so removing collection leaves a delivery requirement unresolved. Asking later remains possible but changes that flow. An address lookup service already exists, making suggestions with a manual fallback a bounded experiment.

The owner chooses that experiment and explains why: test reducing entry effort while preserving the shipment flow. The agent revises the proposal, and the owner reviews and authorizes that revision. The resulting spec can say:

Try address suggestions with editable manual entry. Keep the existing rule for collecting the first shipment’s address. If lookup fails or finds no match, users can finish manually without losing their text. Test whether step-three drop-off falls from the illustrative 35% baseline to 21% or less, a relative 40% reduction. Check final submitted values and fallback behavior, and monitor address corrections before shipment.

Those numbers are hypothetical targets, not customer results. If entering the address becomes easier but abandonment does not improve, revisit when the address is requested. The decision includes both a reason to try the change and a reason to reconsider it.

That is what the spec preserves: the chosen approach, its alternatives, the expected behavior, and the uncertainty that remains. See the decision diagram and resulting intent.md.

Judgment vs. sense vs. intuition vs. taste

These four blur together, and the distinction matters more now than it used to.

Product intuition, product sense, product taste all name the same instinct: the fast, pattern-matched read that tells an experienced person this is the real problem, that feature is a distraction. This is what Adams was teaching you to build, and what Kahneman popularized as System 1: fast, intuitive, and sharpened over thousands of reps. It is real, it is valuable, and it still only comes from contact with customers.

Product judgment is what happens when that instinct meets a decision: which problem is worth solving, framed how, with what accepted trade-offs. Sense is the input; judgment is the applied call.

For thirty years the gap between the two didn't matter much, because the same person did both: felt the instinct and made the call, in their head, in the room. The AI era pries them apart. The instinct stays inside you. The decision has to come out, in a form an agent can act on. Taste you can't articulate is just preference. Taste backed by evidence and made explicit is judgment you can ship.

You can't keep it in your head anymore

If product judgment is now the limiting input and it has to leave your head to be useful, then "develop better judgment" is necessary but no longer sufficient. You also have to capture it, reliably, every time, before it evaporates into a Slack thread or a decision nobody wrote down.

That's a discipline, not a vibe. It has four moving parts:

• Evidence and assumptions: link useful observations when available, and label what is still a hypothesis. Research attachments are optional at entry.
• Intent: the objective and observable outcomes, with consequential choices resolved and remaining questions visible.
• Constraints and scope: the hard boundaries and the fence around what to leave alone.
• Verification: how you'll know it worked, before and after it ships.

Record those alongside the chosen approach, alternatives, and reasons, and another person or agent can inspect the decision. We call that discipline intent engineering. The spec carries the current agreement; questions and implementation findings can still bring it back for review.

In an AI-native SDLC, that discipline becomes a four-stage product intent loop: Sense, Decide, Specify, and Learn, connected to the agent-run execution loop at the handoff and the return path.

The job that's left

AI will keep getting better at execution. That curve only goes one way. Models can already propose, rank, and simulate. What they cannot do is be accountable for the call: own the decision, carry its consequences, or resolve the user-and-business trade-offs without judgment supplied from outside. That accountability is product judgment, and as execution approaches free, it's the part of the job that's actually the job.

Adams was right that you build judgment by talking to customers. That hasn't changed and it won't. What changed is that having it is no longer enough. In a world where the thing gets built the moment you describe it, the judgment that stays trapped in your head is judgment the product never gets. The work now is to get it out of your head and into the hands of whatever does the building. Evidence-backed, explicit, durable.

Building got cheap. Judgment is the job. Don't leave it in your head.