Product risks: A practical guide to testing before you build

Most engineering teams can name key product risks. Value, usability, feasibility, viability. What the list does not settle is which one to check first, how much evidence closes it, or what to do when two answers conflict. Those decisions determine whether discovery saves a quarter of engineering time or spends it.

The categories themselves are settled and widely taught. The sequencing is not, and neither is the question of when you have learned enough to stop. This article covers which risks to test first, what closes them, and how much certainty a decision warrants.

Key takeaways

• The four product risks are value, usability, feasibility, and viability.
• Value gates the other three, since a usable and buildable product nobody wants is still waste.
• Test in order of what each check costs, and run the cheap ones that can kill an idea first.
• Desirability and value name the same risk, and the DVF shorthand drops usability entirely.
• How much evidence you need depends on how hard the decision is to reverse.
• The framework says nothing about what happens when a senior stakeholder outranks the evidence.

What are the four product risks?

The framework comes from Marty Cagan at SVPG, who set out the four in the second edition of INSPIRED. Each risk is a separate question the product has to answer, and passing three of them counts for little if the fourth stops you. Keeping the categories distinct is what makes a skipped question visible.

Value

Will customers buy this, or will users choose to use it? Teams assume this answer more often than they test it. By the time an idea reaches planning, the people in the room have usually convinced themselves already.

N-iX experts note: Desirability and value describe the same risk. Some teams use the DVF shorthand of desirability, viability, and feasibility, which drops usability from the set. Keeping four categories catches more.

Usability

Can people work out how to use it? A product can solve a real need and still lose users at a step nobody outside the team finds obvious. Usability sits downstream of value, because an easy path only helps once people want what sits at the end of it.

Feasibility

Can our engineers build this with the time, skills, and technology available? Maintenance belongs here too. Something a team can ship once and cannot operate reliably is a feasibility answer that arrived too late.

Viability

Does this work for the rest of the business? Viability covers legal and compliance constraints, unit economics, pricing, and partner contracts. It also covers whether sales can sell it, whether support can support it, and whether it fits the brand.

The ownership should be assigned cleanly. The product manager carries value and viability, the designer carries usability, and the tech lead carries feasibility.

Why the testing order matters more than the list

These four risks are often presented as a checklist, which implies the order is arbitrary. It is not arbitrary, and two principles set it.

Value gates everything else. Proving a product is buildable, usable, and commercially sound tells you nothing useful if nobody wants it, and that work is spent before the answer that matters arrives. Teams over-invest in feasibility early because engineers are comfortable running spikes, so the technical answer arrives first and the market answer arrives last.

The second principle is cost. Value and viability can often be tested with conversations, a spreadsheet, and a landing page. Feasibility and usability usually need something built, even a rough prototype. Running the cheap checks first means the expensive ones only happen on ideas that survived.

The four also interact, which checklists hide. A feasibility constraint that triples the build cost can move a viable product to unviable without changing a line of the value proposition. Our engineers regularly find that the honest feasibility answer is a cost and timeline estimate, and that estimate is really a viability input.

How much evidence is enough before you build

Discovery can always continue. There is another interview to run, another prototype round, another spike. What stops it is a judgment about how much certainty the decision is worth. The best guide to that judgment is how hard the decision would be to undo.

Four tiers cover most build decisions, running from ones you can reverse in minutes to ones you cannot reverse at all:

• Reversible with a config change. Ship it behind a flag and watch real behavior. The experiment is cheaper than the research.
• Reversible with a release. Light evidence is enough. A prototype test or a handful of customer conversations clears the bar.
• Expensive to reverse. Data migrations, pricing changes to existing customers, and public API contracts need evidence before the commitment, since the cost of backing out lands on customers.
• Effectively permanent. Regulatory filings, hardware decisions, and public brand commitments justify the slowest and most thorough work on all four risks.

Calibrating this way keeps discovery proportionate. A team that runs the same depth of research on a button placement and a billing model is spending in the wrong place twice. Sizing effort to reversibility is the part of managing product risks that most teams skip.

The cheapest test for each of the product risks

Each risk has a technique that produces real evidence without a full build. These are the ones worth reaching for first.

• Value. A smoke test or fake-door landing page measures intent with real traffic. For enterprise products, a letter of intent or a willingness-to-pay conversation with three named accounts beats any survey.
• Viability. A one-page unit economics model and a legal review of the specific mechanic. Then a direct conversation with whoever owns the sales quota about whether they can sell it.
• Feasibility. A timeboxed engineering spike against the hardest technical assumption, plus a load test at realistic volume when scale is part of the promise.
• Usability. Five moderated sessions on a clickable prototype. The number is deliberately small, since the same friction points repeat quickly.

Each of these produces an artifact someone else can review. That matters more than the technique, because an artifact is what lets a team close a risk and move on.

What the four product risks framework leaves out

The categories are sound. Three things sit outside them, and each one stops teams in practice.

The first is organizational. A viability answer that contradicts a senior stakeholder’s commitment is evidence walking into a political situation, and no framework resolves that. The practical move is to produce the evidence early enough that the commitment has not yet been made publicly.

The second is context. In regulated, enterprise, and platform products, feasibility and viability often dominate, and value may be the best-understood risk of the four. Applying a consumer-shaped discovery process to a compliance-bound product wastes effort on the question you already know the answer to.

The third is newer. AI products carry a risk the framework predates, covering model behavior under real inputs, evaluation against known-correct answers, and rights to the data used. It behaves like feasibility, since it decides whether the thing can work, and it needs its own evidence.

Where to start with N-iX

Our teams scope discovery around whichever risk is most likely to stop the build, before a delivery team is committed. For most enterprise products that is viability or feasibility, and identifying which one changes how the first six weeks are spent.

N-iX brings more than 2,400 technology experts across 25 global locations. Delivery estimates grounded in what those teams have actually built are what make a feasibility answer usable as a viability input.

If you are weighing a build and cannot yet say which of the four risks is largest, talk with our product engineering team. That question is where the scoping conversation starts.

FAQ

What is the difference between product risks and project risks?

Product risks concern whether the thing is worth building and whether it can work, covering value, usability, feasibility, and viability. Project risks concern the delivery of an agreed scope, covering timelines, dependencies, budget, and staffing. A project can run perfectly and still deliver a product nobody uses.

Who owns each of the four risks?

In this model, the product manager owns value and viability, the product designer owns usability, and the lead engineer owns feasibility. In practice, viability is shared, since legal, finance, and sales each hold part of the answer. N-iX names a single accountable owner per risk at the start of discovery, so evidence has somewhere to land.

Is desirability the same as value risk?

Yes. The two names describe one question, which is whether anyone wants the product enough to buy or use it. The difference appears in the shorthand, since the DVF framing of desirability, viability, and feasibility leaves out usability, while the four-risk framing keeps it as a separate check.

How do product risks change for AI products?

Model behavior becomes a feasibility question that traditional spikes do not answer, since correctness varies by input and shifts as models change. Teams need an evaluation set with known-correct answers before committing to a build. N-iX establishes that baseline during discovery on AI engagements.