Assumption Testing Template for User Research

Focus on your top 3-5 highest-risk assumptions (Risk Score 16+). You do not need to test every assumption. Low-impact or well-evidenced assumptions can proceed without formal testing. The goal is to derisk the initiative enough that the remaining unknowns are manageable, not to eliminate all uncertainty.

Assumption testing happens before you build. It validates whether the premise behind a feature is sound. A/B testing happens after you build. It optimizes the implementation of a feature that already exists. Assumption testing asks "Should we build this?" while A/B testing asks "Which version performs better?" Both are valuable, but assumption testing prevents wasted effort on features that should never have been built.

Use smoke tests and concierge experiments. A smoke test puts up a landing page or pricing page for a product that does not exist yet and measures intent signals (email signups, "Buy Now" clicks). A concierge experiment delivers the value manually to a small group of users to see if they find it useful enough to pay for. Both generate evidence about willingness to pay without writing production code.

Present the evidence clearly and recommend an alternative path. "Our test showed 2% conversion versus our 8% target. Here are three options: redesign the free tier to be more compelling, invest in paid acquisition instead of freemium, or proceed with adjusted financial projections showing break-even at month 18 instead of month 6." Give them options, not ultimatums. If they choose to proceed despite the evidence, document it.

Assumption testing typically happens after initial research (interviews, data analysis) and before solution design. You gather evidence about the problem space through interviews, form assumptions about the solution, test the riskiest ones, and then proceed to prototyping and usability testing with the validated assumptions as your foundation. The [Product Discovery Handbook](/discovery-guide) covers this full cycle. ---