Assumption Mapping and Hypothesis Development

Introduction and Context

Product discovery is not primarily the search for attractive ideas. It is the disciplined reduction of uncertainty about a product, service, market, or organisational intervention. Every proposed product contains beliefs about people, contexts, technology, economics, operations, and consequences. Some beliefs are supported by evidence; others are merely plausible. Assumption mapping makes these beliefs visible. Hypothesis development converts them into propositions that can be tested through research and experimentation.

This distinction is central to product management. Teams often move directly from an idea to a roadmap, treating untested beliefs as requirements. The result may be a technically impressive product that nobody needs, cannot use, cannot afford, or should not be offered. A product manager therefore needs to ask not only “What should we build?” but also “What must be true for this product to succeed?”

Assumption mapping and hypothesis development support five related judgements:

• Desirability: Do customers want or value the proposed outcome?
• Feasibility: Can the organisation and its technology reliably deliver it?
• Viability: Can it create sustainable economic or strategic value?
• Usability: Can intended users understand and successfully use it?
• Ethical acceptability: Can it be delivered without unacceptable harm, unfairness, deception, or unlawful treatment?

The objective is not to eliminate all uncertainty. That is impossible. The objective is to identify the uncertainties that matter most, test them efficiently, and establish decision rules before evidence is interpreted selectively.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Distinguish facts, assumptions, hypotheses, risks, and decisions.
2. Identify desirability, feasibility, viability, usability, and ethical assumptions.
3. Write clear, falsifiable and measurable hypotheses.
4. Rank assumptions using consequence, uncertainty, and testability.
5. Define evidence thresholds and decision rules before conducting a test.
6. Select proportionate research or experimentation methods.
7. Interpret ambiguous evidence and recognise common cognitive biases.
8. Apply assumption mapping to a product decision in a professional context.

1. The Logic of Assumption-Driven Discovery

An assumption is a proposition accepted provisionally in the absence of sufficient evidence. For example, “busy parents will pay for a meal-planning subscription” is an assumption. A fact is an observation that has been verified for a defined context, such as “Thirty-two interviewed customers currently use a spreadsheet to plan meals.” A fact is never context-free: evidence has a population, method, date, and level of reliability.

A hypothesis is an assumption expressed as a testable proposition. It specifies who is affected, what is expected to happen, under which conditions, and how success or failure will be recognised. A risk is the possibility that an uncertain assumption will produce a harmful consequence. A decision rule states what action follows from evidence.

A useful chain is:

Idea → assumptions → hypotheses → tests → evidence → decision → learning

The chain is not strictly linear. Research may reveal a new customer segment, causing the team to revise the original problem and create a new set of assumptions. Discovery is therefore iterative, but it should not be directionless.

The anatomy of an assumption

A well-described assumption includes:

This structure prevents vague statements such as “customers will love it.” Love is not an operationally defined outcome. A more useful proposition is: “Among parents who prepare at least four weekday dinners, at least 35% of users shown the prototype will complete a weekly plan and save it for later.”

2. The Five-Dimension Assumption Map

Desirability assumptions

Desirability assumptions concern customer problems, motivations, alternatives, willingness to adopt, and willingness to pay or exchange another scarce resource. Typical assumptions include:

• The problem occurs frequently enough to matter.
• The problem is painful or costly enough to motivate action.
• The proposed outcome is preferable to current alternatives.
• The intended segment can be reached through an economically sensible channel.
• Customers will change behaviour rather than merely express interest.

Desirability evidence should progress from claims to behaviour. A customer saying “I would use this” is weaker than a customer permitting access to data, completing a realistic task, joining a pilot, or paying a deposit. Stated preference is useful for learning language and motivation, but it is not equivalent to adoption.

Feasibility assumptions

Feasibility concerns whether the product can be built, integrated, operated, maintained, and scaled within relevant constraints. Examples include:

• A required data source is accessible and legally usable.
• A model can achieve acceptable performance on representative inputs.
• Response time and reliability can meet user expectations.
• Internal capabilities, suppliers, and support processes are sufficient.
• Security, privacy, accessibility, and regulatory controls can be implemented.

Feasibility is not simply a question for engineers at the end of discovery. A feasibility constraint can change the product concept itself. For example, if real-time identity verification is too costly or unreliable, the experience may need to use delayed verification or a different trust mechanism.

Viability assumptions

Viability concerns whether the product can create sustainable value for the organisation and relevant partners. It includes revenue, costs, retention, strategic fit, operational capacity, and funding requirements. Common assumptions are:

• Customers or sponsors will provide sufficient economic value.
• Acquisition and service costs are compatible with the business model.
• Users will remain active long enough to justify acquisition.
• The product will not undermine a profitable existing offering.
• The organisation can support the product at the required scale.

A simple contribution estimate can support early reasoning:

Revenue and variable cost must be measured over the same period and for the same customer unit. This estimate excludes fixed costs and therefore does not by itself establish profitability. It is useful for comparing scenarios, not for presenting false precision.

Usability assumptions

Usability assumptions concern whether intended users can understand the product, complete important tasks, recover from errors, and achieve their goals with acceptable effort. They include:

• Users recognise what to do next.
• The language and interaction model match users’ mental models.
• Critical tasks can be completed without expert support.
• Error messages enable recovery.
• The experience is accessible to people with relevant disabilities.

Usability is distinct from desirability. A customer may strongly want an outcome but abandon a difficult interface. It is also distinct from feasibility: a system may function correctly while remaining confusing or exhausting to use.

Ethical assumptions

Ethical assumptions concern whether the product’s effects, methods, and distribution of benefits and burdens are acceptable. Examples include:

• Users understand what data is collected and why.
• Consent is informed, voluntary, and appropriately revocable.
• The product does not systematically disadvantage a protected or vulnerable group.
• Persuasive design does not manipulate users into choices against their interests.
• Automated recommendations can be explained and challenged where appropriate.
• Safety risks are identified, monitored, and mitigated.

Ethics should not be treated as a final compliance gate. If a concept depends on surveillance, exclusion, hidden fees, or coercive retention, that dependency is a product assumption requiring early examination. Legal compliance is necessary but may not be sufficient for ethical acceptability.

3. Building an Assumption Map

An assumption map can be created in a workshop or individually. Begin with the intended customer, problem, proposed outcome, and business model. Then record assumptions without immediately debating them. Classify each assumption by dimension and distinguish evidence from belief.

A practical map uses two axes:

1. Importance or consequence if wrong: How seriously would failure affect customers, the organisation, safety, or strategy?
2. Confidence or evidence strength: How well supported is the assumption today?

The most urgent assumptions are generally high-consequence and low-confidence. Teams should also note whether an assumption is a prerequisite. A low-priority assumption may become critical if several later decisions depend on it.

Figure: A prioritisation matrix directs early testing toward high-consequence, low-confidence assumptions.

The matrix is a conversation aid, not a scientific measurement instrument. Teams should document why an assumption was placed in a quadrant and revisit the judgement as evidence changes.

4. From Assumptions to Falsifiable Hypotheses

A hypothesis must be capable of being contradicted by an observation. “Users will like the feature” is not falsifiable unless “like” is defined. A useful form is:

For [defined population] in [defined context], [intervention or condition] will produce [observable outcome] at or above/below [threshold] within [time period], because [reason].

Examples:

• Desirability: “Among independent cafés with at least 200 weekly orders, at least 30% of qualified owners will request a trial after seeing a workflow prototype.”
• Usability: “At least 8 of 10 target users will complete the first-order task without moderator assistance, and the median completion time will be below three minutes.”
• Feasibility: “For representative images, the classification service will achieve at least 95% recall for safety-critical defects at p95 response time below two seconds.”
• Viability: “A pilot customer acquired through the proposed channel will generate positive contribution over six months under the stated price and support-cost assumptions.”
• Ethics: “In a representative fairness assessment, no defined user group will experience a materially higher false-rejection rate than the reference group, and all affected users will receive an accessible appeal route.”

A strong hypothesis has five properties:

1. Specific population: It avoids treating all users as identical.
2. Observable behaviour or outcome: It does not rely solely on attitude.
3. Defined metric: The measurement method is stated.
4. Threshold: The team knows what result is sufficient.
5. Time and conditions: The result is interpreted in context.

A hypothesis is not a prediction that must be confirmed. It is a structured risk statement. Evidence that contradicts it is valuable because it prevents investment in an invalid proposition.

5. Prioritising Risks and Tests

A basic risk-priority model is:

If each factor is scored from 1 to 5, the resulting score ranges from 1 to 25. Consequence estimates the seriousness of being wrong; uncertainty estimates the lack of credible evidence. The score is ordinal, not a probability and not a precise expected loss. It should be used to compare assumptions within the same team and scale.

A more decision-oriented model is expected loss:

Here, P(failure) is the estimated probability that the assumption will fail, and impact must be expressed in a consistent unit such as money, time, users affected, or a documented severity scale. The model is appropriate only when the probability and impact estimates are sufficiently meaningful. It should not be used to assign spurious numerical precision to ethical or safety concerns.

Test priority should also consider cost and speed of learning. A high-risk, low-cost test is usually attractive. However, the cheapest test is not always the best: a misleading survey may be less valuable than a more expensive behavioural pilot. Teams should ask:

• What decision will this test inform?
• What uncertainty will it reduce?
• What is the minimum credible evidence?
• What is the cost of a false positive or false negative?
• Can the result be generalised to the intended context?

Evidence strength

Evidence can be viewed as a ladder, although the levels are not universally ordered:

1. Team opinion and analogy.
2. Desk research and market reports.
3. Interviews and qualitative observation.
4. Concept reactions and prototype tasks.
5. Behavioural commitment, such as sign-up, deposit, or workflow adoption.
6. Controlled experiments or pilots with relevant outcomes.
7. Repeated post-launch behaviour and economic performance.

Qualitative evidence is excellent for discovering language, motives, workarounds, and unanticipated problems. Quantitative evidence is useful for estimating frequency, comparing alternatives, and monitoring outcomes. Neither automatically proves causality. A large survey with leading questions can be weaker than a small, well-designed observational study.

6. Evidence Thresholds and Decision Rules

A decision rule should be agreed before the test begins. Otherwise, teams may reinterpret disappointing results as “interesting signals” and continue investing because of commitment or optimism.

A simple three-way rule is:

• Proceed: evidence meets the threshold and no critical safety or ethical issue is present.
• Revise and retest: evidence is mixed, the segment or proposition may be wrong, or the test has material limitations.
• Stop or pivot: evidence falls below the minimum threshold, or an unacceptable risk is revealed.

For a usability test, a rule might be: proceed if at least 8 of 10 representative participants complete the critical task independently and no severe accessibility barrier is found; revise if 5–7 complete it; redesign before further testing if fewer than 5 complete it. These thresholds are managerial criteria, not universal laws. They should reflect task criticality, sample limitations, and the cost of failure.

For quantitative experiments, teams should define the primary metric, comparison condition, observation period, minimum practically important effect, and guardrail metrics. A statistically detectable difference may be too small to matter commercially; conversely, a harmful effect may be unacceptable even if a small sample cannot establish statistical significance.

Decision rules should also specify uncertainty. If a result is based on a convenience sample, the conclusion should be limited to that sample and context. Product teams should avoid claiming that “the market wants this” when the evidence only shows that a few recruited participants understood a prototype.

7. Selecting Methods Proportionately

Different assumptions require different tests.

A test should be as realistic as necessary and no more elaborate than necessary. A clickable prototype may test navigation but cannot establish system reliability. A landing page may test message resonance but can overestimate demand if the promised service is not delivered. A concierge pilot can test value and workflow while humans perform tasks that automation may later handle; it cannot prove that automation is feasible at scale.

8. Worked Example: A Digital Medication-Reminder Service

Consider an illustrative product: a service intended to help adults manage recurring medication schedules. The proposed service sends reminders, allows users to confirm doses, and provides selected information to caregivers.

Background and problem

The team believes that some adults miss doses because schedules are complex and reminders are poorly matched to daily routines. The product raises high ethical and safety stakes because incorrect reminders, privacy failures, or inappropriate caregiver access could cause harm.

Initial assumption map

Hypotheses and tests

The team writes the following hypotheses:

1. Among adults managing at least two recurring medications, at least 70% will complete schedule setup correctly in a prototype task without assistance.
2. In a four-week supervised pilot, reminder delivery will reach at least 99% of scheduled notifications, excluding user-device failures that are separately documented.
3. At least 80% of participants will be able to explain who can see their adherence information before enabling caregiver access.
4. At least 25% of eligible provider organisations will request a paid pilot after reviewing the service and implementation requirements.

The first test uses moderated usability sessions with realistic labels and schedules. The second requires an instrumented pilot and a clear definition of successful delivery. The third uses comprehension questions and observed consent behaviour rather than simply asking whether participants find the privacy policy clear. The fourth uses qualified provider conversations and a paid-pilot commitment, not general expressions of interest.

Decision rules

The product team agrees in advance that:

• Any critical configuration error that could generate a dangerous reminder blocks progression until redesigned.
• If fewer than 70% complete setup correctly, the team revises the interaction and repeats testing.
• If caregiver permissions are misunderstood by more than 10% of participants, the feature is withheld from the pilot.
• The business pilot proceeds only if at least three qualified providers commit resources or payment.

Outcome

Suppose 8 of 10 users complete setup, but 3 misunderstand caregiver visibility. Technical delivery reaches 99.4%, while provider conversations produce two paid pilot commitments. The service has passed the initial usability threshold and the technical threshold, but it has failed the ethical comprehension threshold. The correct decision is not to average the scores and proceed. The team must redesign consent and access controls, retest comprehension, and delay caregiver functionality.

Learning points

First, critical assumptions should have veto power rather than being diluted by positive results elsewhere. Second, behavioural evidence is more informative than enthusiasm. Third, the same product may require different methods for different risks. Finally, an ethical failure is a product-learning outcome and should alter the design, not merely be recorded in a compliance file.

9. Common Errors and Limitations

Treating opinions as evidence

Senior stakeholders, customers, and experts can all provide valuable insight, but authority does not convert belief into proof. Record the source and limitations of each claim.

Testing the wrong population

Convenient participants may not possess the problem, purchasing authority, constraints, or vulnerability of the intended segment. Recruitment criteria should be explicit.

Measuring proxies without examining the mechanism

Clicks, time on page, and sign-ups may indicate interest but may not predict retention, payment, safety, or successful outcomes. Use a metric hierarchy: immediate behaviour, repeated behaviour, and meaningful customer or business outcome.

Confirmation bias and motivated reasoning

Teams may ask leading questions, ignore disconfirming cases, or move thresholds after seeing results. Pre-registration of the hypothesis, method, exclusions, and decision rule reduces this risk.

False precision

Scores from 1 to 5 help structure discussion but do not create objective probabilities. Document rationale and use sensitivity analysis where decisions are consequential.

Over-testing low-risk assumptions

Discovery can become an excuse for indefinite research. Once an assumption has adequate evidence for the decision at hand, move to the next uncertainty or make the decision.

Ignoring system effects

A feature may appear desirable in isolation but create support costs, fraud, exclusion, or harm when deployed at scale. Assumptions should be revisited across the full customer and operational journey.

10. Professional Governance and Contemporary Practice

Assumption registers should have an owner, date, evidence link, confidence level, decision status, and next review point. They are living product-management artefacts, not workshop outputs that disappear into a repository. Product reviews should ask which assumptions changed, which evidence was generated, and what investment decision follows.

AI-enabled products require particular care. Teams should distinguish model performance from product value: a high-accuracy model may solve an unimportant problem, while a useful workflow may tolerate imperfect automation if users can review and correct outputs. Testing should include representative data, subgroup performance, error severity, human oversight, privacy, explainability, and failure recovery. Synthetic data can accelerate prototyping but may conceal distributional and consent problems. Automated systems should not be released solely because a benchmark score exceeds a threshold.

Contemporary discovery also increasingly includes sustainability and responsible innovation. Relevant assumptions may concern energy use, accessibility, labour effects, supplier dependence, environmental externalities, and the reversibility of harmful decisions. A mature product team expands the question from “Can we make it work?” to “For whom does it work, under what conditions, and with what consequences?”

Best-Practice Checklist

Before testing, the team should be able to answer:

• What decision will the test support?
• Which assumption is most consequential and least supported?
• Is the hypothesis falsifiable?
• Who exactly is included and excluded from the test?
• What behaviour or outcome is measured?
• What threshold indicates proceed, revise, or stop?
• What biases or confounders could distort interpretation?
• Are privacy, accessibility, safety, and fairness addressed?
• What will happen if the result is negative?
• Who owns the decision and when will it be reviewed?

Chapter Summary

Assumption mapping exposes the beliefs hidden within a product concept. Product teams should classify assumptions across desirability, feasibility, viability, usability, and ethics because success in one dimension cannot compensate automatically for failure in another. Hypotheses convert assumptions into specific, falsifiable propositions with a defined population, context, outcome, metric, threshold, and time period.

High-priority assumptions are generally those with high consequence and low confidence, especially when they are prerequisites for later decisions. Risk scores and expected-loss reasoning can support prioritisation, but numerical ratings are decision aids rather than objective facts. Evidence must be matched to the assumption: interviews reveal motives, prototypes reveal usability problems, pilots reveal behaviour and operational performance, and post-launch data reveals sustained outcomes.

Predefined evidence thresholds and decision rules protect teams from confirmation bias and uncontrolled escalation of commitment. Ethical and safety assumptions deserve explicit treatment and, where appropriate, veto power. The central professional discipline is to learn the most important truth at the lowest credible cost, then make a transparent decision about whether to proceed, revise, pivot, or stop.

Key Terms

Assumption: A provisional belief accepted without sufficient proof.

Assumption map: A visual or structured record of assumptions ranked by importance and confidence.

Desirability: The extent to which a product addresses a valued customer need or motivation.

Feasibility: The extent to which a product can be built, delivered, operated, and maintained.

Viability: The extent to which a product creates sustainable organisational or economic value.

Usability: The extent to which intended users can achieve goals effectively, efficiently, and satisfactorily.

Ethical assumption: A belief about whether a product’s effects and methods are acceptable and responsible.

Hypothesis: A testable proposition derived from an assumption.

Falsifiability: The property that a proposition could be contradicted by evidence.

Risk: The possibility that uncertainty produces an undesirable consequence.

Evidence threshold: The minimum result required for a defined decision.

Decision rule: A pre-agreed interpretation linking evidence to action.

Proxy metric: An indirect measure used as an indicator of a less immediately observable outcome.

Guardrail metric: A measure used to detect unacceptable side effects while pursuing a primary goal.

Behavioural commitment: An action indicating stronger intent than a stated preference.

Pilot: A limited real-world implementation used to learn before wider deployment.

False positive: Concluding that an assumption is supported when it is not sufficiently valid.

False negative: Concluding that an assumption is unsupported when it may actually be valid.

Confirmation bias: The tendency to favour evidence consistent with existing beliefs.

Assumption register: A maintained record of assumptions, evidence, owners, and decisions.

Review Questions

Short Answer Questions

1. What is the difference between an assumption and a hypothesis?
2. Name the five dimensions used in the assumption map.
3. Why is behavioural commitment generally stronger evidence than stated interest?
4. What is the purpose of a decision rule?
5. Why should ethical assumptions be tested early?

Long Answer Questions

1. Explain how a product team can construct an assumption map from an initial product idea.
2. Discuss the differences between desirability, feasibility, viability, and usability assumptions, using examples.
3. Explain the characteristics of a strong falsifiable hypothesis.
4. Compare qualitative interviews, prototype tests, and pilots as sources of product evidence.
5. Analyse the advantages and limitations of using numerical risk-priority scores.

Analytical / Application Questions

1. A team believes that small retailers will pay for an AI inventory assistant. Develop one hypothesis for desirability, one for feasibility, one for viability, and one for ethics. Define a test and decision rule for each.
2. A prototype has high sign-up rates but users rarely return after one week. Identify at least three assumptions that may be wrong and propose tests in priority order.
3. A healthcare product passes its usability threshold but users misunderstand data-sharing permissions. Should the team launch? Apply the chapter’s principles and justify your decision.

Multiple Choice Questions with Answers

Question 1

Which statement is the best example of a falsifiable hypothesis?

A. Customers will love the product.

B. The product is innovative.

C. At least 70% of target users will complete setup without assistance in a usability test.

D. The market is ready for change.

Correct Answer: C. At least 70% of target users will complete setup without assistance in a usability test.

Question 2

Which assumption dimension asks whether an organisation can reliably build and operate a product?

A. Desirability

B. Feasibility

C. Viability

D. Usability

Correct Answer: B. Feasibility

Question 3

In an assumption map, which assumptions generally deserve earliest attention?

A. Low-consequence, high-confidence assumptions

B. High-consequence, low-confidence assumptions

C. Low-consequence, low-confidence assumptions

D. High-confidence assumptions that are easy to explain

Correct Answer: B. High-consequence, low-confidence assumptions

Question 4

What does the following expression represent: Expected loss = P(failure) × Impact of failure?

A. A usability score

B. A measure of expected risk consequence

C. A conversion rate

D. A contribution margin

Correct Answer: B. A measure of expected risk consequence

Question 5

Which evidence is usually stronger than a customer merely saying, “I would use this”?

A. A team member’s opinion

B. A generic industry slogan

C. A relevant customer making a payment or completing a realistic pilot task

D. A speculative market-size estimate

Correct Answer: C. A relevant customer making a payment or completing a realistic pilot task

Question 6

What is the primary purpose of a decision rule established before testing?

A. To guarantee a positive result

B. To prevent evidence from being interpreted opportunistically

C. To eliminate the need for research

D. To replace customer involvement

Correct Answer: B. To prevent evidence from being interpreted opportunistically

Question 7

Which is an ethical assumption?

A. The API will respond within two seconds.

B. Users will understand and control who can access their data.

C. The acquisition channel will be inexpensive.

D. Users will complete the onboarding flow.

Correct Answer: B. Users will understand and control who can access their data.

Question 8

A team records that 8 of 10 representative users complete a critical task independently. Which conclusion is most appropriate?

A. The product is guaranteed to succeed commercially.

B. The result may satisfy a predefined usability threshold if that threshold was 8 of 10.

C. The product has proven technical feasibility at scale.

D. The result proves all customers will adopt the product.

Correct Answer: B. The result may satisfy a predefined usability threshold if that threshold was 8 of 10.

Question 9

Why can a landing-page experiment overestimate demand?

A. It always uses too many participants.

B. It measures actual long-term retention directly.

C. People may respond to a promise without experiencing the delivered service.

D. It cannot measure any customer reaction.

Correct Answer: C. People may respond to a promise without experiencing the delivered service.

Question 10

Which statement about risk-priority scores is most accurate?

A. They are objective probabilities of failure.

B. They eliminate managerial judgement.

C. They are structured comparison aids whose scales and rationale should be documented.

D. They should be used only after launch.

Correct Answer: C. They are structured comparison aids whose scales and rationale should be documented.