Desirability Hides Two Different Risks

I spent an evening recently with three risk frameworks open next to each other, trying to decide which one to actually use inside my own company. Strategyzer's, Marty Cagan's four risks, and Ash Maurya's version. Not an academic exercise. I am building a product that is supposed to keep strategy, discovery, feedback and delivery connected, so whichever model I picked was going to end up shaping how the work gets structured.

I expected to pick one and move on. What happened instead is that one distinction jumped out, and I realised I had been blurring it for most of my career.

Cagan keeps value and usability as two separate risks. The three-lens version does not. It puts them both inside one word.

The Word That Fits on a Slide

Desirability, feasibility, viability. Three clean lenses, and they are genuinely useful. I have drawn that triangle on more whiteboards than I can count, and the reason is not that it is the most accurate model available. It is that three things fit on a slide and four do not.

Desirability answers the question "do people want this". Which sounds complete, and is where the trouble starts.

Because underneath it sit two entirely different questions that fail in entirely different ways. Will someone choose this, pay for it, pick it over the thing they use today. And then, once it is in front of them, can they figure out what to do with it.

Those two get tested by different methods, at different times, with different people. Folding them into one word gives a team permission to answer the first one and file the whole lens as validated.

Wanting Is the Easy Signal to Collect

The reason this keeps happening is that evidence of wanting is cheap and pleasant to gather.

Somebody nods in a demo. Somebody asks when they can have access. A key account brings the same request to three biweekly meetings in a row and names it explicitly, which in enterprise B2B is about as strong as a signal gets. All of that is real. None of it is fake enthusiasm.

And it is all still only the first half. Every one of those signals was produced by a person imagining the thing, not using it. Imagination is frictionless. It fills in the parts that are not built yet, and it fills them in with whatever that person already knows how to do.

Then the thing ships, and it turns out the mental model they filled in with was their old one.

The dangerous product is not the one nobody wants. It is the one people want right up until they have to use it.

Where the Good Ideas Actually Die

I have watched a feature go out that a customer had asked for by name, get used by exactly that customer, and by almost nobody else. The demand was documented. The usage was not there.

What normally happens next is that the post mortem reaches for a different explanation. Positioning. Enablement. Not enough internal communication. Sometimes that is even true. But a team that never separated the two risks in the first place has no way to tell the difference between "they did not want it after all" and "they wanted it and could not get in".

Those two have opposite remedies. One says stop building this. The other says the thing is right and the way in is wrong. Getting them mixed up is how teams kill work that was actually close, and how they keep polishing work that was never wanted.

This is sharper for anything that asks people to work differently. If your product fits the way somebody already operates, usability risk is mostly interface detail. If it proposes a genuinely different flow, then usability is not a polish problem at all. It is the main event, because every user arrives carrying habits from the tools they already know, and those habits are the actual competitor.

I am living inside that version of the problem. People can want a more connected way of running product discovery, mean it sincerely, and still land in front of a new shape of work and have to translate it back into the arrangement they came from. The value being real does not help them in that moment.

Two Lines Instead of One

So I dropped desirability from how I frame risk internally. Value and usability get their own line now, each with its own evidence and its own test.

Value is answered by what people do when there is a cost. Choosing, switching, paying, giving up the incumbent. Interviews help, but interviews are also where wanting is cheapest.

Usability is answered by watching somebody try, ideally without you talking. First five minutes, no guidance, no demo script. It is uncomfortable to run and it is the fastest information in product discovery.

Maurya adds the move that makes this operational rather than just tidier. Of the two, which is the riskiest assumption right now, and what is the smallest test that would tell you. Not both, not a research programme. The one that would change what you do next.

For most teams building something familiar, value is the open risk and usability is a detail. For anyone proposing a new way of working, it is the other way around, and the frameworks will not tell you which situation you are in. Only your own honest read will.

The Question I Would Put in the Next Review

The thing I find slightly funny about all this is that Cagan has had four risks in there for years. It is not hidden knowledge. The three-lens version simply travels better, and the version that travels is the version teams internalise, which is its own small lesson about how product frameworks actually spread.

So, next time something gets marked as validated in your process, one thing worth checking.

Do you know whether people wanted it, or whether they could use it? And if the answer to both is the same sentence, you tested one risk and shipped against two.