Voice of the customer

Value hypothesis

Value hypothesis is licensed CC BY 4.0. Attribution: Katafacts (katafacts.com).

1 · What it is

What it is

A value hypothesis closes the same gap a CTQ tree always closes — between 'the customer wants X' and something specific enough to build a case around — pointed at a single deal instead of a product line. It's the same three-level tree: a buyer need at the top (ideally traced to a real discovery call, not assumed), the reasons your solution actually addresses that need underneath it, and one or more specific, measurable proof points under each. 'We'll save them time' isn't a value hypothesis — 'time from a deal going quiet to being flagged at-risk, target under 48 hours versus their current 3 weeks' is. The tree also tracks its own coverage: any need with no quantified proof point yet is named directly, not silently treated as done.

2 · When to use it

When to use it — and when not to

Use it when

You have real buyer needs from an actual discovery call and want to translate them into something specific enough to build a business case around, not just a pitch.
You want to know exactly which parts of your pitch are backed by a real number and which are still just a confident-sounding claim.
The deal is heading toward a business-case or ROI conversation and you want the value stated as a proof point the champion can defend internally, not a slide you presented.

Not when

You don't have a real discovery conversation yet, just an assumed persona's pain points — run discovery first, or you'll be quantifying value for a need nobody actually confirmed.
You want the raw notes from the call — that's the discovery call itself; a value hypothesis assumes the need is already named and is translating it into something measurable.
The 'proof point' you're about to write is really just a restated benefit ('saves time', 'reduces risk') — push for a real number or concrete criterion before treating it as specified.

3 · How to fill it in

How to fill it in

Scope: Which deal or buyer is this hypothesis built for, and at what stage?
Needs → drivers → measurable CTQs: List each buyer need, ideally traced to a specific discovery call finding. Drivers and quantified proof points get drafted beneath each one — don't fill those in at intake.
Coverage: Computed for you: total needs, drivers, and proof points, and which needs still have no quantified proof point beneath them — nothing to enter here.
Narrative: Drafted from the tree and any coverage gaps — which needs are well-specified, which still need more discovery.
Next steps: What will you do about a coverage gap or a specific need, ranked by impact and effort, owned and dated? A next step not tied to a named need is a coaching failure mode, not a real action.

4 · What good looks like

What good looks like

The example below builds a value hypothesis for a mid-market prospect discovered through this catalogue's own discovery call standard work. The second need is deliberately grounded in a real internal finding — Beacon Analytics' own deal A3 identified 'business case never quantified' as a named driver of stalled pipeline, and this hypothesis exists specifically to close that exact gap before it costs this deal too. A third need is honestly left with no drivers yet, because it surfaced as an aside in discovery, not something actually probed.

Same example, as a downloadable xlsx workbook.

Download .xlsx

CTQ tree

Northline Freight — value hypothesis

Jordan Ellis, Sales Manager · 2027-02-11

Team: Priya Anand, RevOps · Sponsor: Renee Okafor, VP Sales

Scope

Built during the qualification stage for the Northline Freight opportunity — a mid-market logistics company evaluating Beacon Analytics to replace a spreadsheet-based pipeline review. Translates discovery findings into a hypothesis the team can test and quantify before the deal reaches a business-case conversation.

Needs → drivers → measurable CTQs

RevOps leadership needs to see win-rate risk before it shows up in the quarterly forecast, not after

Evidence: Surfaced in discovery — Northline Freight's VP RevOps described finding out about stalled deals in the QBR, weeks after they'd already gone quiet.

Real-time visibility into stalled or at-risk deals, without waiting on a manual pipeline review

Time from a deal going quiet to it being flagged at-risk< 48 hours, vs. Northline's current ~3 weeks (first surfaced at the next QBR)

A repeatable way to see why deals are stalling, not just that they are

% of stalled deals with a named, categorized stall reason logged≥ 90%, vs. ~20% today

Whoever approves this purchase needs a defensible, quantified reason to say yes without us in the room

Evidence: This is the exact gap named in Beacon Analytics' own Q1 deal A3: 'business case never quantified' accounted for $40K of the quarter's stalled pipeline value. Built directly to prevent this deal from stalling the same way.

A quantified cost-of-inaction the champion can carry into an internal budget conversation alone

$ value of at-risk pipeline the platform would have flagged 2+ weeks earlier, using Northline's own historical deal data$310K in the trial cohort — the reference figure from Beacon's own pilot analysis

The team already using spreadsheets needs to trust a new system before they'll stop trusting the old oneNo CTQ yet

Coverage

Needs

Drivers

Measures

No measurable CTQ yet: The team already using spreadsheets needs to trust a new system before they'll stop trusting the old one

Narrative

The first two needs are both well-specified with concrete, checkable targets — visibility timing and a dollar figure the champion can defend internally without Beacon Analytics in the room. The second is the more important of the two: it exists specifically to close the gap deal A3 already identified as costing real pipeline. The third need — trust in a new system over a familiar spreadsheet — has no drivers or measures yet, which honestly reflects that it surfaced as an aside, not a probed need; treating it as specified before it's actually understood would be the exact mistake this tool exists to catch.

Next steps

Run a follow-up discovery call specifically probing the spreadsheet-trust need before the next call — what would have to be true for the team to actually stop using it.
Linked finding: The team already using spreadsheets needs to trust a new system — no measurable CTQ yet
Impact: medium · Effort: low · Owner: Jordan Ellis · Due: 2027-02-25
Pull Northline's own historical deal data to replace the $310K reference figure with a number calculated from their pipeline specifically, before the business case is presented.
Linked finding: Whoever approves this purchase needs a defensible, quantified reason to say yes — fully specified
Impact: high · Effort: medium · Owner: Priya Anand · Due: 2027-02-20

5 · Common mistakes

Common mistakes

Writing a driver or proof point that's really just a restated benefit.
"Saves the team time" as a proof point has no target and can't be defended in a budget conversation — "time to flag an at-risk deal, under 48 hours versus 3 weeks today" can. A value hypothesis that isn't concrete enough to fail against isn't actually one.
Treating a coverage gap (a need with no quantified proof point) as good enough to bring into a business case.
A need with no driver or proof point beneath it is still just a claim, not evidence — the whole point of this tool is surfacing that gap honestly rather than letting an unproven benefit pass as done.
Writing needs that aren't traced to a real discovery conversation.
A value hypothesis translates real buyer needs into proof points — starting from an assumed persona's pain risks building a precise, confident case for something this particular buyer never actually said mattered.

6 · What it connects to

What it connects to

upstream

Discovery call standard work
A need surfaced with real technique in discovery — the compelling event, the cost of inaction — is exactly the kind of evidence this tree exists to translate into a quantified proof point.

downstream

Deal A3 — win-rate root cause analysis
When a value hypothesis's proof point turns out to be wrong or unpersuasive after the deal is lost, that gap is exactly what an eventual deal A3's root cause analysis would trace back to.
Message architecture
Once a proof point actually works in a real deal, this is where it gets promoted into the standing message every deal and channel should use — not invented fresh a second time.

7 · Where AI helps

Where AI helps

Judgement — stays yours

Deciding whether a drafted driver or proof point is actually right for this buyer, or reworking it during review
Deciding which coverage gap to close before the business-case conversation

Analysis — AI helps

Drafting drivers and quantified proof points from a stated need and its supporting discovery evidence
Drafting the narrative from the tree and any coverage gaps

Drudgery — automated

Counting needs, drivers, and proof points across the whole hypothesis
Identifying which needs still have no quantified proof point
Exporting to xlsx in the house format

9 · Rate this kata