Viability Risk

Concept

The risk that a thing customers want and engineers can build is still something the business or the law won't let the company carry.

Why it exists

Teams that checked only on the customer side kept getting stopped inside their own company. Customers want it, nobody stalls using it, the technology is there — and the day before launch legal says the data can't be retained that way. Four months of work halts in an afternoon.

There's a reason it surfaces late. This risk lives on the company's side rather than the customer's, so meeting a few users produces no signal at all. Legal, security, finance, sales, and support each block for different reasons, and none of those people is usually in the kickoff meeting. That's why, when the checks got divided into four, this one got a slot of its own.

How it works

The block almost always comes from one of five places.

  1. Law and contracts. Where personal data can live and for how long, and whether any of it breaks agreements already signed with customers.
  2. Unit economics. When the cost of usage runs above the revenue, selling more loses more. Charge $75 a month with unlimited document conversion while each conversion costs $0.30 in servers, and one heavy customer alone passes that price.
  3. The load on selling and support. A feature sales can't explain in one sentence, or one that doubles the inbound tickets after rollout, gets caught here.
  4. Existing customers and brand. If a new feature breaks the order of work people already rely on, the losses outweigh the new signups.
  5. Partner and platform rules. App store policies or payment provider terms doing the blocking.

Checking it is the cheapest of the four, because it's asking people rather than running an experiment. Write one page before anything is built, circulate it to the departments involved, and phrase the question as whether there's a reason to block rather than whether the idea is good. When conditions come back attached, write those conditions into the document verbatim.

If value risk is the check you take to customers, this is the one you take to colleagues. Which is why it gets skipped most often despite taking about a day.

How it sounds at work

"Let's clear viability risk first. Legal can answer in a day."

Find out whether anything internal blocks this before starting.

"The feature works, but at this price the heavy users put us underwater."

Naming whether we can carry it rather than whether we can build it.

"Sales says they don't know how they'd explain this."

A signal that the feature can't be sold.

Pagedeck ran into this while looking at publishing documents externally. Mia circulated a one-pager, and Grace pointed out a clause in existing customer agreements saying internal documents are not sent outside. Sofia counted seventeen customer companies covered by that clause. The feature wasn't dropped — it shipped switched off by default for those seventeen.

Easily confused with

TermWhat it asksHow it differs from viability risk
Feasibility riskCan this be built with the technology and the time availableIt asks whether building is possible. This one assumes it is and asks whether the company can carry it

Where to go next

  • Four big risks

    see all four checks and why this one comes late

  • Value risk

    put the check aimed at customers next to this one

Last updated 2026-09-16