Value Risk

What teams actually checked before starting usually stopped at whether people could operate the thing. Show a mockup to five people, watch all five reach the end without stalling, call it cleared, start building. Checking whether a screen is hard is visible work; questioning whether the feature is needed at all is uncomfortable work that disturbs a plan already agreed to.

So the same outcome kept repeating: four months of building, and usage a month after launch sitting at 2 percent. The people who used it hadn't struggled. They simply had no reason to open it in the first place. A feature that is awkward to use can be fixed by changing screens; a feature nobody wants has nothing to fix. That's why this particular risk got its own name and moved to the front of the checking order.

You check behavior, not statements. Almost everyone says yes to "would you use a feature like this." It's an answer given to avoid disappointing the person asking, and it filters nothing.

Three approaches cover most cases.

1. Ship only the entry point to a feature that doesn't exist yet and count who clicks it. Clicking shows a note saying it's on the way.
2. Show a screens-only prototype and ask what they'd pay to use it today, or whether they'd drop their current method for it. Questions about money and switching are hard to answer politely.
3. Do the work by hand without building anything and count how many requests come in.

Whichever you pick, write the passing line down as a number first. Forty clicks on the entry point out of 300 people who got the announcement email, say. Set the line afterward and it drifts to fit whatever number arrived.

Look at how customers are coping with the problem today as well. A problem people endure with no workaround at all carries a strong reason to change; a problem already handled passably in a spreadsheet means a new feature has to be visibly better before anyone moves. Skip this and jump to usability risk and what you get is a well-built feature nobody needed.

"Usability cleared, but we haven't looked at value risk yet."

We know people can operate it; we don't know they want it.

"Don't ask whether they'd use it. Ship the button and count the clicks."

Measure behavior instead of asking about intent.

"What are you doing about this today?"

Finding the current workaround to size the reason for switching.

Pagedeck followed this order when it looked at a document approval feature. Mia put the menu item in place before anything was built and left it for two weeks. Nine of 400 customer companies clicked it, and six of those nine read the note and left. Theo had estimated four months for the feature, so it was dropped right there.