Four Big Risks

For a long time, the question that dominated a spec review was a single one: can we build this? Engineering said yes, a date went on the calendar, design drew the screens, and three months later the feature shipped. A month after that, a number came back saying two percent of users had touched it.

The strange part of the retrospective was that every answer held up. Engineering had confirmed it was buildable. Design had checked that nobody got stuck on the screens. Sales could point to customers who had asked about it. Each group answered the question in front of them, and the only question nobody owned was whether anyone would actually pay or spend time to use the thing. The reason the team collectively believed nothing was missing is that no list of what to check existed in the first place.

The four big risks nail that list down to four boxes. This isn't a new research technique — it's closer to taking the checks teams were already doing, naming them, and standing them up side by side. Once the boxes exist, "what did we skip this time?" becomes a question that can be answered instead of a feeling somebody has in the hallway.

Take one feature and ask four separate questions about it, then check whether each question has a real answer behind it. Any box left empty is the weak link for that feature.

1. Value risk — will people want this? The risk is that customers won't bother spending money or time on it. You test it by watching and interviewing people through user research, or by shipping only the button for a feature that doesn't exist yet and counting how many people press it.
2. Usability risk — can people figure it out? They want the thing, but they stall in front of the screen. Hand a screens-only prototype to five people, give them a real task, and three or four sticking points usually show up in the same places.
3. Feasibility risk — can we build it? The risk lives in the technology or the schedule. An engineer takes the single most suspicious piece and spends two days building just that to find out.
4. Viability risk — can the business carry it? You can build it and customers want it, but something on the company side blocks it. Unit costs run higher than the revenue, the way it handles personal data runs into regulation, or sales can't sell it because it conflicts with contracts already signed.

There's no fixed order, but teams in practice start with value. The other three only pay off when value is there. A feature that's pleasant to use, cheap to build and priced correctly — but that nobody wants — is harder to fix than an awkward one, because there's nothing to fix.

The cost of checking also varies box by box. Usability takes five people and a day. Feasibility takes one engineer and two days to sketch out. Viability is the slow one, because it pulls in legal or finance from outside the team, so it attaches to the schedule last. That's why viability problems tend to surface after the feature is built, at the point where there is the most to undo.

The most common setting is the spec review right before a build decision. Draw the four boxes, make someone write one line per box saying what the check actually was, and any feature with a blank box stops there. It also keeps the meeting out of taste arguments, because the conversation shifts from whether something is good to which box is empty.

Ownership differs by box too. Value and viability usually sit with the product manager, usability with the designer, feasibility with the engineer. When one person claims all four, they typically go deep on the box they enjoy and fill the rest in as a formality.

The four boxes also shape how a hypothesis gets written. Decide first which risk the experiment is meant to reduce and the design changes. Testing value means recruiting people who aren't already interested and watching their reaction; testing usability means giving a task to people who already are.

None of this means every change deserves four boxes. Run the full set on a button label or anything else that's easy to reverse and a two-week job turns into a six-week one. The harder a decision is to undo, and the more teams it touches, the more seriously the boxes get filled.

"You checked feasibility, right? Who looked at the value risk?"

Someone confirmed the thing is buildable but nobody confirmed anyone wants it.

"Viability is the big one here and we haven't sent it to legal yet."

The weak link isn't the technology or the customer — it's a condition inside the company.

"Usability is the only box left, so let's run the prototype past five people and move on."

One box remains and it happens to be the cheapest to close, so there's no reason to drag this out.

At Pagedeck these four boxes go up as a table during quarterly planning. Mia brings four lines per candidate feature, Theo fills the feasibility box with something like "the external service is slow here, give me two days to measure it," and Noa notes in the usability box that three people last week failed to find the same button. Any feature with an empty value box leaves the meeting without a date and rolls into the next cycle.

Grace takes the viability box herself. For enterprise features she checks whether it collides with terms already in signed contracts, and whether extending the retention window pushes storage cost above what the plan charges. A feature or two gets stopped by that box every quarter, which is far cheaper than stopping one after it's built.

The most common mistake is reading the four as gates to clear in order. They're numbered and lined up, so a picture forms of collecting stamps from one through four. In practice you fill all four a little at a time in the same week, and a single prototype session moves the value box and the usability box together, so both get rewritten at once. Run them as gates and engineering sits idle for weeks waiting on a value stamp — and when something fails at number four, the first three boxes get walked again from the start.

Treating four filled boxes as a guarantee of success is the other common one. What the framework does is expose where you haven't looked, not lower the odds of failure. Features clear all four boxes and still fail. The difference is that when they do, there's a record of what was misread, and the next call is better for it.