Product Discovery: Test Assumptions Before Building

Run product discovery around a decision, a customer problem and the assumptions behind a solution. Includes a worked opportunity map and an experiment planning table.

Product discovery reduces uncertainty about what to build and why. It connects an outcome to people’s needs, possible solutions and tests of the assumptions those solutions depend on. It is ongoing work rather than a document that guarantees product success.

Separate the outcome, problem and solution

An outcome describes a change you want to see. An opportunity describes a customer need or obstacle. A solution is one possible response. Mixing them makes it easy to approve a feature before understanding the problem.

Teresa Torres’ opportunity solution tree provides a structure for these relationships. The following hypothetical example applies that distinction without claiming a validated opportunity.

Level	Invoice-product example
Outcome	More eligible teams complete account setup
Observed opportunity	A user needs an administrator’s approval to connect accounting data
Possible solutions	Administrator invitation; guided handoff; alternative setup route
Risky assumption	The user can identify and contact an authorised administrator
Initial test	Observe a safe prototype handoff, including cases where the administrator is unavailable

The tree helps organise thinking. It does not turn an unsupported customer story into a confirmed market need.

Start with recent behaviour

Ask people to reconstruct a specific situation: what triggered it, what they tried, which alternatives were available and what happened next. A future preference such as “I would use this” has a different evidential status from a recent action.

Use JTBD interviews and switch interviews to explore progress, alternatives and constraints. Supplement interviews with observations or existing product evidence when the question concerns behaviour.

Make assumptions testable

Assumption	Evidence that could challenge it	Appropriate first activity
The problem is important	Users repeatedly defer it or accept an existing workaround	Recent-event interviews and observation
People can use the proposed flow	They miss a consequential step or cannot recover	Task-based prototype testing
The organisation can buy it	The likely buyer lacks budget or an approval route	Buyer research
The offer is understandable	People interpret the promise differently from the intended value	Message testing
The economics can work	Delivery and support costs exceed the plausible value	Pricing research and an explicit cost model

Prioritise the assumption whose failure would most change the decision. Assumption mapping makes that choice explicit; experiment design translates it into a test.

Decide before collecting convenient evidence

Write down the decision, what you would regard as contradictory evidence and the next action for each plausible result. Avoid changing the success condition after seeing the data. Qualitative work can reveal a failure mechanism without establishing how often it occurs.

Use concept testing to compare meaningfully different propositions. If two concepts vary in audience, price and functionality simultaneously, do not attribute a preference to just one of those differences.

Keep learning connected to delivery

A useful discovery record contains the decision, current evidence, remaining uncertainty and next review. Revisit it when customer circumstances or product constraints change. Route supported findings through insight to impact, and use the product research guide when the question extends beyond an interface into market or buying behaviour.

Glasgow Research helps B2B SaaS teams turn research into product decisions. Discuss your study.

Explore product discovery

Choose the guide that matches your next research decision.

Assumption & Opportunity Mapping in Product Discovery
Map product assumptions by importance and evidence, identify the risks that matter and choose an appropriate test before committing to a solution.
Concept Testing: Run a Test That Yields a Decision
Plan a concept test with clear questions and decision criteria. Compare methods, recruit relevant participants and interpret interest without overstating demand.
Conjoint Analysis for Feature Prioritisation & Pricing
Plan a conjoint study for feature and pricing tradeoffs. Define attributes, design choice tasks and interpret results in relation to the sample and study assumptions.
Continuous Discovery Interviews for Product Teams
Build a sustainable weekly customer interview practice with a clear cadence, recruitment system, synthesis workflow and decision log.
Empathy Mapping in UX Research: From Interview Data
Build an empathy map from interview evidence. Separate what people said and did from interpretation, then identify uncertainties and a relevant product decision.
Experiment Design for Product Discovery
Design product discovery experiments with a clear hypothesis, decision rule and measure. Distinguish learning about a need from validating a solution.
Jobs-to-Be-Done Interviews for B2B SaaS: Complete Guide
Plan jobs-to-be-done interviews for B2B SaaS. Reconstruct a recent decision, explore switching forces and distinguish buying roles from day-to-day product use.
MaxDiff Analysis for Feature Prioritisation Guide
Design and analyse a MaxDiff study that actually prioritises features: item counts, set design, sample size, TURF and turning scores into roadmap decisions.
Message Testing: Validate Value Props With Research
Learn how to test value propositions and messaging with qual and quant research—plus when to use message testing vs concept testing to pick winning copy.
Opportunity Prioritisation in Product Research
Turn a backlog of research-surfaced opportunities into a ranked, decision-ready shortlist. A practical scoring framework bridging synthesis and roadmap input.
Switch Interview Technique: A Step-by-Step Guide
Use a switch interview to reconstruct a recent product change. Explore the timeline, alternatives, anxieties and circumstances behind the buying decision.
User Research Plan Template: Structure Any Study
Write a user research plan that connects a product decision to questions, participants, methods and analysis. Includes a practical planning structure.
Why You Shouldn't Delegate Customer Interviews to Non-Researchers
Learn why delegating customer interviews to non-researchers often creates biased evidence, false confidence, and weaker product decisions in practice.