What a Product Decision Actually Is

It is a Thursday review. Maya, one of your product managers, is walking the room through a proposal for smart reminders — a feature that nudges users about work they left unfinished. She has mockups. She has an engineering estimate: four people, six weeks. She has a rollout schedule and a slide listing the risks, each with a mitigation next to it.

Nobody in the room has a question. The document answers everything it raises. You approve it.

Six weeks later it ships. It works — no outages, no complaints, the settings page is clean. At the next quarterly review someone asks whether it helped. The answer takes a while to arrive, and when it does it is a version of: engagement is up about two percent, but the marketing campaign ran in the same window, and we didn't measure the before, so, honestly, we don't know.

Nothing went wrong. Everyone was competent. The document was genuinely good.

Here is the uncomfortable part: the thing that failed had already failed on that Thursday, in the room, before a line of code existed. The proposal was thorough about one question and silent about three others, and its thoroughness is exactly what stopped anyone noticing.

So: what was missing at the moment of approval? Not detail — there was plenty of that. Something else.

The four risks

Two proposals land in your inbox on the same morning.

The first is twelve pages. Architecture diagram, data model, a table of edge cases, a per-engineer breakdown of the six weeks. The second is two pages and mostly prose.

The twelve-pager feels safer. Almost everyone reads it that way. But notice what its extra ten pages are about: they are all about whether the team can build the thing. That is one question. It happens to be the question a competent engineering organisation can answer by itself, in a room, by thinking hard — which is exactly why so much effort collects there.

Any product idea has to survive four separate risks before it is worth building:

• Value risk — will anyone actually choose this? Not "would it be nice," but will a real person pick it over what they do today, including doing nothing.
• Usability risk — can they work out how to use it without being taught?
• Feasibility risk — can you build it with the people, data, and time you have?
• Business viability risk — does it work for your own company? Support load, legal exposure, brand, margin, whether your sales team can explain it.

These are independent. Passing one tells you nothing about the others. A feature can be beautifully engineered (feasibility: solved), obvious to use (usability: solved), and still nobody wants it (value: fatal). A feature can be wanted and usable and buildable and still sink you because it triples support tickets or attracts customers your pricing can't carry (viability: fatal).

How to use it. When any proposal reaches you, do not evaluate it. First, take inventory. Go through the four risks and sort each one into addressed, assumed, or not mentioned. Then ask one question about the biggest thing in the "assumed" pile: what would we do this week to find out?

How to spot the gap. Count where the pages went. A document that is overwhelmingly about how and how long has answered feasibility and quietly assumed the rest. As Cagan puts it, a proposal like that has not been evaluated; it has been scheduled.

One thing that has changed. Feasibility risk has genuinely fallen for a lot of software — building really is faster than it was. That does not remove the risk mix, it reweights it. When building is cheap, value becomes the binding constraint, and business viability becomes the quiet killer, because support load and legal exposure and brand damage did not get cheaper just because code generation did. An idea that looks newly attractive because "we can build this in a week now" is usually still failing on the exact risk it failed on before.

Look back at Maya's proposal. Mockups and an estimate: feasibility and, partly, usability. Value and viability: assumed in a sentence each. Three of four risks went unexamined in a document nobody had a question about.

Problems, not solutions

Open any quarterly roadmap — the plan for what a team will work on over the next few months — and you will usually find a list that looks like this:

Q3: Smart reminders · Bulk import · Notification preferences · Mobile onboarding v2

Read it again and ask a plain question about any one item: what is this supposed to change, and by how much?

Most roadmaps cannot answer. That is not a formatting problem. A list of features is a list of solutions, and every solution on it was chosen before anyone did the work that would justify choosing it. The document has quietly converted a team of people who understand the customer into a delivery queue.

The alternative is not "no roadmap." It is handing a team the problem and the outcome to move, and letting the people closest to the customer choose the solution. "Reduce the time it takes a new user to get their first real result below ten minutes" is a problem. "Ship onboarding v2 by March" is a queue ticket.

How to use it. For each item, write down the outcome it is meant to move and the evidence that it will. Items that can answer are bets — keep them. Items that cannot are commitments to someone, usually a customer or an executive, and those are fine as long as everyone says so out loud. What is not fine is a commitment wearing a bet's clothes.

How to spot it. Look at the success criteria. If they are shipping dates, you are looking at a feature roadmap, whatever the header says.

One thing that has changed. Generated roadmaps are very good at producing plausible feature lists and very bad at supplying the problem behind them. The format survives the generation; the justification does not. Asking "what outcome does this move?" of an AI-drafted plan is the fastest way to find out whether anyone thought about it before it was formatted.

Outcome over output

A launch retrospective — the review a team runs after shipping — opens with a slide: fourteen releases, velocity up 30%, zero rollbacks. The room is pleased, and it should be; that is real work.

Then someone asks what changed for users, and the honest answer is that nobody knows, because nobody measured the before.

Output is what you shipped. Outcome is the change in behaviour that shipping caused. They are not two views of the same thing. Output is always achievable — a working team will produce some — and it is measurable, immediate, and attributable to named people. Outcome is noisy, lagging, and shared. Under pressure, the measurable thing wins, and a team can run for years reporting output without ever finding out whether any of it worked.

How to use it. Take every stated accomplishment and translate it into the behaviour it was meant to change, then check whether that behaviour was measured against a baseline — the reading taken before the change, without which "improved" means nothing. "We shipped onboarding v2" becomes "did more new users reach their first real result, and how would we know?" If the artifact only reports shipping, the review has not happened yet. It has been announced.

How to spot it. A metric with no baseline and no comparison group. Also: any claim of improvement made in a window where something else obviously changed — like Maya's two percent, sharing a calendar with a marketing campaign.

One thing that has changed. This is where the AI productivity paradox lives. Teams adopting AI tooling frequently ship substantially more while their outcomes stay flat, which is not a mystery: the constraint was never how fast the team could produce. More output at constant outcome is a signal that you are solving the wrong problem faster.

So what is a decision?

The three concepts converge on one distinction, and it is the reason this chapter is first.

A commitment names a thing and a date. It can be tracked, reported, and delivered. Delivering it proves you delivered it.

A decision names which risk you are taking, what you expect to change, and what would tell you that you were wrong. It can turn out badly while having been made well — and that is the point, because a bet you can lose is the only kind that teaches you anything.

"We scoped it" is not "we validated it." Maya's proposal was an excellent commitment. It was never a decision, and the Thursday room approved it as one.

The twelve-page proposal

Devraj founded a company that makes scheduling software for veterinary clinics. Nine engineers, roughly two hundred paying clinics. His head of engineering brings him a proposal for an AI-assisted triage assistant: a system that reads incoming appointment requests and suggests urgency levels.

The document is excellent. Model evaluation, a fallback path when confidence is low, an audit log for every suggestion, cost projections per clinic, and a ten week estimate with named owners.

Devraj runs the inventory rather than reacting to the document.

Feasibility: addressed, thoroughly. Usability: partly — there are mockups of where suggestions appear, but nothing about how a receptionist learns to trust or override one. Value: one line — "clinics have told us triage is painful." That is a description of a problem, not evidence that this solution gets chosen over the whiteboard they use now. Business viability: absent. And this is the one that stops him, because a wrong urgency suggestion in a veterinary clinic is not a support ticket. It is an animal seen too late, and a company his size cannot carry that.

He does not reject the proposal, and that matters — rejecting it would teach the team that thorough documents get punished. He asks two things. First: sit with three receptionists next week and watch what they currently do at the moment a request arrives. Second: write the paragraph about what happens when the model is confidently wrong, including who is liable.

The second question comes back in four days and reframes the whole feature, from assign urgency to flag the three requests a human should look at first. The new version is smaller, ships in five weeks instead of ten, and carries a risk the company can actually hold.

Notice what did the work. Not scepticism, not seniority. A four-item checklist run against a document that had answered one item at length.

The roadmap item that cannot say its outcome

Lena runs product at a forty-person company selling expense software. Her Q3 roadmap has six items. Her CEO likes it. She runs the outcome question over it herself before the planning meeting.

Five items answer, more or less. One does not: Slack integration. Asked what outcome it moves, the honest answer is that a large customer asked for it in a renewal call.

The weak move is to invent an outcome — write "improves engagement" underneath and carry on. Now the item is undecidable: nobody can ever say it failed, because nothing was claimed.

The strong move is to write down what is actually true: this is a retention commitment to one account worth 8% of revenue, not a bet on a customer need we have evidence for. That single line changes three things. It makes the item's scope negotiable — the smallest thing that satisfies the account is now obviously the right size, where a "bet" would have justified building it properly. It makes the cost visible, because it is now clearly sitting where a bet could have been. And it tells the engineers what kind of work this is, which is the difference between a team that feels jerked around and a team that has been levelled with.

The item stays on the roadmap. It just stops pretending.

The retro that had not happened

A team ships a redesigned checkout flow. The retro reports: shipped on time, support tickets flat, conversion up 4%.

Someone asks what conversion was doing in the eight weeks before. Nobody has the number to hand, and when it is pulled it turns out to have been drifting up already — the trend accounts for most of the 4%.

The failure here is small and extremely common, and it is worth being precise about what it is. The team did not lie. They did not even do bad work; the redesign may well have helped. What they did was ship a change and then look for a number that moved, which is a procedure that returns a positive result almost every time regardless of whether the change did anything.

The correction costs about ten minutes and has to happen before: write down the number now, and write down what you expect it to be afterwards. A launch with no pre-registered expectation is not a success or a failure. It is an unevaluated bet, and saying so plainly is more useful than a 4% that dissolves under one question.

Name which of the four risks you actually tested. Most proposals conflate "we scoped it" with "we validated it," and naming the risk you addressed exposes the ones you didn't. Tell: a strong artifact says "this de-risks value; usability and business viability are untested." A weak one offers an engineering estimate as validation.

Give the team the problem, and hold them to the outcome. Specifying the solution deletes the one step where the team's knowledge of the customer could improve the answer, and it quietly moves accountability from results to delivery. Tell: goals stated as outcomes with numbers — "get time-to-first-result under ten minutes" — rather than features with dates.

Report the outcome, not the shipment. Output is guaranteed; the outcome is the thing that was actually being bought. Teams that report shipments can run for years without learning whether any of it worked. Tell: a launch retro with no post-launch metric, or one comparing against no baseline, has not evaluated anything.

Feasibility theatre

What it looks like. A proposal that covers engineering approach, estimates, and architecture exhaustively, with value and business viability handled in a sentence each. It reads rigorous because it is rigorous — about the wrong risk.

Why smart people do it. Feasibility is the only one of the four risks that is fully knowable from inside the building. You can resolve it by thinking hard, which makes it disproportionately attractive to competent people who like resolving things. The other three require going outside and being told something you did not want to hear.

The correction. Force the four-risk inventory before discussing the plan. State which risks are addressed, which are assumed, and what would test the biggest assumed one this week.

The feature roadmap

What it looks like. A quarterly plan that is a list of features with dates. The success criteria are the dates. An outcome may be named once at the top and is never connected to any specific item.

Why smart people do it. Stakeholders ask "what are you shipping," and a feature list is the only answer that fits in a status meeting. It also feels like commitment and competence — which it is, just not the kind being claimed.

The correction. For each item, write the outcome it moves and the evidence that it will. What survives are bets. What doesn't are obligations, and those should be renegotiated explicitly rather than smuggled through as strategy.

Output mistaken for progress

What it looks like. A retro or update listing shipped work as accomplishment. Velocity up, releases up, the team visibly productive. No behavioural metric appears — or one appears without a baseline.

Why smart people do it. Output is measurable, attributable, and immediate. Outcomes are noisy, lagging, and shared across teams. Under pressure the measurable thing wins, every time, and nobody involved is being dishonest.

The correction. Pair every shipped item with the behaviour it targeted and the observed change. Where nothing was measured, say so — an unmeasured launch is an unevaluated bet, not a success, and the sentence "we don't know yet" is a sign of a serious team.