--- name: value-hypothesis description: "The critical-to-quality (CTQ) tree's need-driver-measure discipline pointed at a deal instead of a product: what the buyer actually needs, why what you sell addresses it, and a specific number that proves the value rather than asserts it — with any need still missing a real proof point named plainly. Use 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. Not for: 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." --- # Value hypothesis The critical-to-quality (CTQ) tree's need-driver-measure discipline pointed at a deal instead of a product: what the buyer actually needs, why what you sell addresses it, and a specific number that proves the value rather than asserts it — with any need still missing a real proof point named plainly. Family: Voice of the customer · Format: .xlsx · Domain: commercial ## 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. ## When to use it 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. ## How to fill it in - **scope** — Which deal or buyer is this hypothesis built for, and at what stage? - **needs** — 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. - **nextSteps** — 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. ## 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. Full worked example, on-screen and as a downloadable .xlsx: https://www.katafacts.com/katas/value-hypothesis ## 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. ## What it connects to Upstream: - **Discovery call standard work** (`discovery-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** (`deal-a3`) — 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** (`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. ## Where AI helps Judgement — stays with you: - 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 --- Value hypothesis is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Attribution: Katafacts (katafacts.com). ## Using this skill Apply this method as part of whatever broader task, instructions, or deliverable you're already working on -- it's a method to use, not a standalone conversation to start. There is no generation tool for this catalogue yet, so draft the artifact's actual content yourself, following the fields above, the same way a person filling this out by hand would. The canonical guide page and a downloadable worked example (.xlsx) are at https://www.katafacts.com/katas/value-hypothesis.