What Counts as Evidence? The Risk Receipt for Value, Usability, Feasibility, and Viability
AI made feasibility cheap to prove. Value, usability, and viability still need their own evidence — and a great prototype demo counts for less than it feels like. Here's the Risk Receipt framework for checking what you've actually retired.
Share
AI made one product risk cheap to retire. It did nothing for the other three.
That's the quiet argument running under this month's product discourse. An October 13 essay on Leading in Product put it bluntly: AI made feasibility almost trivial, but it hasn't touched value, viability, or usability. Scroll LinkedIn this week and you'll see the opposite claim in a hundred variations: the PM is "becoming an AI-powered decision maker," prototypes are "the new PRD," and discovery is "10x faster now."
Some of that is true. Most of it skips a step. A working prototype answers can we build it? in an afternoon. It does not answer will anyone want it, can they use it, and does it work for the business? — and those three questions are where products actually die.
The problem isn't that PMs stopped caring about the other risks. It's that a polished prototype feels like evidence for all four. Demo it to five people, hear "this is great," and the team walks away believing value, usability, and viability are covered. They aren't. Each risk has its own currency of evidence, and most teams are paying in the wrong one.
This post gives you a simple framework for fixing that: the Risk Receipt.
The four risks, quickly
The four big product risks were popularized by Marty Cagan and SVPG, and they've held up because they're independent:
Value risk — will customers choose to use or buy this?
Usability risk — can they figure out how to use it?
Feasibility risk — can we build it with the time, skills, and technology we have?
Viability risk — does it work for the business: pricing, cost to serve, sales, legal, support?
Independent means evidence for one tells you almost nothing about another. A feature can be trivially feasible, perfectly usable, and still have zero value. A feature can have obvious value and be unviable because each use costs more in inference than the customer pays.
When building was expensive, feasibility was the gate everything queued behind, so teams naturally spent discovery time on the other three while engineering estimated. Now that feasibility clears in hours, the queue is gone — and so is the forced pause where the other risks used to get examined.
The Risk Receipt framework
S
Specky Team
Writing about AI-native product development at Specky.
A Risk Receipt is a short record you attach to any meaningful product bet. For each of the four risks it answers three questions:
What's the claim? One sentence, specific enough to be wrong.
What evidence do we have, and what kind is it? Linked to the source, not paraphrased.
Does that evidence actually count for this risk? This is the part teams skip.
The third question is the whole point. Evidence has an exchange rate. Some evidence is strong currency for one risk and close to worthless for another. Here's the conversion table we use.
Value: pay in behavior, not compliments
Counts: customers describing the problem unprompted, with a recent concrete example. Existing workarounds (spreadsheets, scripts, manual processes) that cost them real time. Commitments with a cost attached: a calendar slot, a pilot with their data, a pre-order, an introduction to their boss.
Doesn't count: "I'd use this." Enthusiasm during a demo. A prototype's click-through rate in a moderated session. Upvotes on an idea board from people who'll never pay.
The tell: if the strongest evidence for value is someone reacting to your prototype, you've collected usability evidence and labeled it value. People react politely to anything competent-looking you show them. Value evidence usually comes from before they saw your solution — in how they talk about the problem.
Usability: pay in observed tasks, not opinions
Counts: watching a real target user attempt a real task without coaching, and recording where they hesitate or fail. Task completion on the first attempt. The questions they ask out loud.
Doesn't count: "it looks clean." A stakeholder walkthrough. Your own team using it every day (they already know where everything is).
The tell: if nobody outside the team has attempted a task alone, usability is unverified — no matter how good the prototype looks.
This is the one risk AI prototyping genuinely helps with, and it's worth saying so. A clickable, data-backed prototype gets you real task observation weeks earlier than a static mockup. That's a real gain. It's just a gain for one risk.
Feasibility: pay in a working path, including the ugly parts
Counts: a prototype that runs against realistic data volumes, real permissions, real latency. An engineer's honest list of what the prototype skipped: auth, migrations, error states, the integration that's rate-limited.
Doesn't count: a demo on the happy path with seeded data.
The tell: ask "what did this prototype not have to handle?" If the answer is long, feasibility is partially retired, not fully. AI made the first 70% cheap. It didn't make the last 30% — the edge cases, the reliability, the maintenance — free.
Viability: pay in numbers someone outside product would sign
Counts: a cost-to-serve estimate (for AI features, cost per use at expected volume). A pricing hypothesis you've said out loud to a buyer. A check with whoever owns support, sales, security, or legal. For B2B: does a buyer's procurement process allow this?
Doesn't count: "we'll figure out pricing later." Assuming usage costs are negligible because the prototype was cheap to run for one person.
The tell: if no one outside the product team has seen the bet, viability is unexamined.
A worked example
Say you're a two-person founding team building a B2B tool, and a customer call sparks an idea: an AI assistant that drafts weekly status updates from project activity. You prototype it over a weekend. It works. You show it to four customers on calls. All four say they love it.
Here's the honest Risk Receipt:
Risk
Claim
Evidence
Counts?
Value
Team leads will use weekly drafts instead of writing updates themselves
4 positive demo reactions
Weak — reactions to a solution, not behavior. No one described writing updates as a pain before you showed them.
Usability
Leads can review and send a draft in under 5 minutes
None observed
Unverified — nobody tried it alone.
Feasibility
Drafts stay accurate on real project data
Weekend prototype on your own workspace
Partial — no test on a messy customer workspace.
Viability
Cost per draft stays well under what the plan charges
Not estimated
Unexamined
Four enthusiastic calls, and the receipt says you've retired almost nothing. That's not a reason to kill the idea. It's a reason to run three cheap checks before building the production version:
Value: go back to two of those customers and ask how they write updates today, how long it takes, and what happened the last time one was late. Listen for a workaround.
Usability: give one customer the prototype on their own data and watch them use it, unguided, for one cycle.
Viability: multiply your per-draft model cost by realistic weekly volume across your customer base, and compare it to plan price.
Each check takes days, not weeks. That's the actual dividend from cheap feasibility: you can afford to buy real evidence for the other three risks before you commit.
Why receipts beat a discovery checklist
You could turn the four risks into a checklist. Teams do. Checklists fail in a predictable way: someone ticks "value validated" because a demo went well, and the tick hides what the evidence was.
A receipt forces the evidence to stay attached to the claim. Three months later, when the feature is underperforming and someone asks "why did we build this?", the answer isn't a memory or a slide. It's a record: here's what we believed, here's what we saw, here's which risks we knowingly left open.
That last part matters. Shipping with an open risk is often the right call — small teams can't afford to retire everything. The failure is shipping with an open risk you thought was closed.
How we run Risk Receipts in Specky
We built Specky around this habit, so here's what it looks like in practice.
Customer signal — interview notes, support threads, call transcripts, analytics events — lands in the product graph as typed nodes, each one keeping its source. When you draft an insight or a decision, it cites the specific nodes it rests on, so "four customers loved it" can't quietly turn into "customers need this." You can open the decision and see exactly which evidence it points to — and whether that evidence is a demo reaction or a customer describing their own workaround.
For the value check, Specky's AI interviewer can run a short research session with customers about their current process — before they see your solution — and the transcripts flow back into the graph as evidence. For an early demand signal, a validation page measures whether people take an action with a cost attached instead of just saying yes.
None of that replaces judgment about which risks to leave open. It just makes the receipt the default, instead of something you reconstruct after the fact.
Start with one receipt this week
You don't need a tool to start. Pick the bet your team is most excited about right now — the one with the best prototype. Write four lines: one claim per risk, the evidence behind it, and an honest "counts / weak / unverified / unexamined."
If the most exciting bet has the emptiest receipt, you've found where your next week of discovery should go.
Feasibility used to be the expensive question. Now it's the cheap one. The teams that win this cycle won't be the ones who build fastest — they'll be the ones who can show what they knew when they decided.
Specky is the AI product workspace that shows its work — every decision keeps a live link to the evidence behind it, so you always know which risks you've actually retired. → specky.space