Assumption mapping makes a product idea’s dependencies visible so a team can choose what to test first. Place assumptions by the consequence of being wrong and the strength of current evidence. Then select one, define an observation that could change the decision, and update the map after the test.
Turn the idea into claims that can be wrong
A camera-rental shop wants instant online reservations. Customers currently contact staff, who check equipment availability and confirm the pickup. The proposed product lets a customer choose a body and lens, select dates, and reserve immediately. Before designing a polished checkout, ask what must be true for that promise to work.
A useful assumption names a user, situation, and required behavior or service condition. Customers like convenience is too broad. Customers can select a compatible body-and-lens pair without staff help is testable, and it points toward a different study than whether the inventory record is accurate.
| ID | Assumption | Consequence if wrong | Evidence currently needed |
|---|---|---|---|
| A1 | Availability records are reliable enough to promise a specific kit for the selected dates | A confirmed reservation could be impossible to fulfill | Compare recorded availability with actual overlapping reservations and equipment status |
| A2 | Customers can choose a compatible body-and-lens combination | Customers may reserve a kit that does not meet their task | Observe selection with realistic compatibility information |
| A3 | Customers understand that reservation and collection are separate steps | They may arrive without meeting collection requirements | Test the confirmation and pickup instructions |
| A4 | Customers prefer instant reservation enough to change their current process | A costly checkout might receive little use | Study recent rental behavior and test an appropriately placed entry point |
Plot consequence against evidence, not enthusiasm
Use the horizontal axis for stronger versus weaker evidence and the vertical axis for lower versus higher consequence if wrong. Avoid confusing confident team members with strong evidence. A founder’s certainty that stock is accurate is not the same as checking overlapping bookings, maintenance holds, and late returns.
The first map below is a planning example: A1 and A2 are both high consequence with weak evidence; A3 is lower consequence in this limited scope; A4 remains important but does not decide whether an individual reservation can be fulfilled. Your placement should change when your records or business model differ.
Write an evidence note on each card: source, date, population or cases covered, what it supports, and what it leaves open. If you have only a sales conversation about speed, it cannot establish operational inventory reliability. Leave that uncertainty visible rather than giving the whole idea one confidence score.
Choose the assumption that could change the product promise
Choose A1 first in this example. Even a customer who selects the right kit cannot complete the promised rental if the shop cannot honor instant confirmation. This choice is not a universal rule to test feasibility before desirability; it follows from the proposed promise and the consequences of getting it wrong.
Product Talk recommends testing assumptions underlying a solution rather than treating the entire solution as one experiment. Here, an inventory audit can change the initial scope before a full checkout is built. A usability prototype remains useful for A2, but it cannot prove that the physical equipment will be available.
| Assumption | Useful first test | Wrong substitute |
|---|---|---|
| A1: availability reliability | Reconcile recent attempted rentals and current records with operational facts | A clickable checkout that always says Available |
| A2: compatible selection | Observe people choosing equipment for a stated shooting task | Ask whether they like the product idea |
| A3: pickup understanding | Ask what the renter would bring and when after reading confirmation | Count confirmation-page views |
| A4: preference for instant reservation | Examine recent workarounds and try a bounded demand test | Treat an inventory audit as customer demand evidence |
Write the test before inspecting the answer
For A1, select a defined set of recent rental attempts spanning overlapping dates, maintenance holds, and late returns. For each case, reconstruct what the online system would have promised at the time, then compare it with what staff could actually fulfill. Record missing history as unknown; do not fill gaps with today’s stock state.
Use a scenario-specific decision rule: any reproducible false availability caused by an unmodeled constraint blocks instant confirmation until that constraint is represented. This is a policy for an explicit promise to customers, not a statistical claim that a small clean sample proves the system safe.
| Field | Example |
|---|---|
| Decision | Can version 1 confirm immediately, or should it send a request for staff review? |
| Assumption | The availability model includes every constraint needed for the instant promise |
| Evidence | A defined period of rental attempts plus staff records of overlaps, holds and late returns |
| Procedure | Reconstruct the offered state; compare with fulfillable kit and dates; attach each discrepancy |
| Change condition | One reproducible false availability from an unmodeled constraint changes the initial promise |
| Owner and output | Operations lead; discrepancy ledger and a scope recommendation |
| Next check | After repair, replay each discrepancy and add boundary cases before reconsidering instant confirmation |
Show how a finding changes the map and the first version
Worked outcome: suppose the audit finds that a lens marked Available is actually on a maintenance hold that the proposed online record does not contain. A1 now has stronger evidence against it in its current form. Moving its card toward stronger evidence does not mean the risk has disappeared; label it contradicted and keep the consequence visible.
The version-one decision becomes request-to-book. Customers choose equipment and dates, then see Request sent — staff will confirm availability. The operations team checks holds before sending confirmation. This narrower promise lets the team investigate A2 without falsely telling customers that a kit is reserved.
If the maintenance constraint is later integrated, retest the original case and relevant date boundaries. Only then reconsider instant confirmation. A successful test should change a scope decision or reduce a named uncertainty; otherwise the map is becoming wall decoration.
| Before | New evidence | Changed decision | Remaining uncertainty |
|---|---|---|---|
| Instant confirmation depends on A1 | Maintenance hold is missing from the proposed stock view | Start with request-to-book and staff confirmation | Other constraints and operational response time |
| A2 remains untested | No selection study has been run | Prepare a body-and-lens selection prototype | Whether compatibility guidance supports actual selection |
Use a blank card for the next assumption
Copy this card: We believe [specific condition] must hold for [user/task] because otherwise [consequence]. Current evidence is [source, date, coverage]. The next test is [procedure]. We will change [decision] if [observable result]. Owner: [person]. Review date: [date]. After testing: [supported, contradicted, or unresolved] and [next action].
Do not close an assumption simply because the test ran. Attach the result and state what it changes. Keep customer preference, task usability, technical feasibility, and operational reliability separate so one positive result does not accidentally approve the whole product.