Recommended resources
The freely available resources this lesson will direct you to.
Hello! In the previous lesson, you used decision principles to choose between credible designs for a customs-filing integration. A principle can explain why a team favors showing disputed source facts over silently completing a field. It cannot tell the team whether customers have the needed data, whether the connection will work, or whether it will improve filing work.
This lesson is about those uncertain beliefs. You will identify the assumptions beneath an integration proposal, then distinguish the ones worth investigating first from those that are merely unknown. The result is not a verdict on whether to build; it is a clearer account of what the proposal depends on.
Make the proposal specific enough to question
Consider a hypothetical proposal: connect a logistics SaaS product to an existing source system so filing specialists can retrieve manufacturer information for an ISF draft. The product would show where each value came from and flag conflicting values for review. The intended user outcome is more supportable drafts ready by an internal cutoff; improved customer retention is a possible downstream business impact.
Suppose an illustrative review found that 31 of 120 drafts were paused. That observation makes delays worth examining. It does not show that missing manufacturer information caused those pauses, that this connection would prevent them, or that affected customers would use it. Each claim needs its own evidence.
An assumption is a belief that must hold for some part of the proposal to work but has not yet been adequately established. “The integration should preserve source information” is a design decision shaped by the previous lesson’s principle. “The source system supplies reliable provenance for the values we need” is an assumption: it could prove false and materially change the design.
David J Bland’s short How to Get Started with Assumptions Mapping video, from Precoil, provides a way to begin surfacing such beliefs.
Precoil - How to Get Started with Assumptions Mapping
Watch David J Bland’s How to Get Started with Assumptions Mapping for the three initial lenses—desirability, viability, and feasibility—and examples of questions that uncover assumptions.
Watch the three lenses for the distinction between customer value, business sense, and ability to deliver. Then watch the questions for prompts about customer problems, continued use, technical obstacles, and legal barriers. Apply the questions to the proposed connection rather than to a new standalone product.
For an integration, these lenses quickly expose different ways the same proposal might fail. Specialists might not need another route to the information (desirability). The connection might require costly maintenance for each customer (viability). A source system might not permit timely, attributable access (feasibility). None of these is answered simply because a team can draw the proposed interface.
Surface assumptions across the whole workflow
The first pass is to ask: What must be true for this connection to improve supportable drafts? Look beyond the API. Consider the moment a specialist requests a value, the source that returns it, the person who can resolve a disagreement, and the organizational permission needed to exchange data.
Product Talk’s Assumption Testing: Everything You Need to Know to Get Started broadens the initial three lenses. Its additional usability and ethical categories are useful here: an integration can function technically yet be difficult to interpret or cause harm when a disputed fact appears authoritative.
Assumption Testing: Everything You Need to Know to Get Started
Read the selected parts of Product Talk’s Assumption Testing to widen your search beyond whether customers want the connection and whether engineers can build it.
In “What are the types of assumptions that product teams tend to make?”, read the five categories. Then, in “How do you identify the product assumptions that your ideas depend upon?”, read the identification methods. Focus on walking through a user’s journey and asking what must be true at each point; the category labels are prompts, not a classification test.
For the proposed connection, an initial inventory might look like this:
| Lens | Belief the proposal depends on |
|---|---|
| Desirability | Missing or conflicting manufacturer information causes a meaningful share of the delays this connection aims to reduce. |
| Usability | Specialists can tell an imported value from a verified value and know when a conflict needs review. |
| Feasibility | Authorized source systems can provide the needed values and provenance early enough to affect draft preparation. |
| Viability | A reusable connection can be maintained at a cost justified by the value it delivers across customers. |
| Potential harm | Showing the source and conflict status will not lead users to treat an unsupported value as confirmed. |
These are candidate beliefs, not findings. Some need splitting. For example, “authorized source systems can provide the needed values and provenance early enough” contains questions about access, data content, and timing. Separating them makes it possible to discover which dependency threatens the proposal.
Notice also the distinction between a risk and a requirement. The team must respect applicable permissions and filing obligations regardless of where an assumption lands on a prioritization map. Mapping uncertainty helps determine what to investigate; it is not permission to bypass a hard constraint.
Map importance against evidence
An inventory may contain more assumptions than the team can investigate immediately. Assumptions mapping asks two questions about each one:
- Importance: If this belief is false, does the proposal fail, require a major redesign, or have a reasonable workaround?
- Evidence: What observable information supports this specific belief for the relevant customers and workflow?
Read Strategyzer’s How Assumptions Mapping Can Focus Your Teams On Running Experiments That Matter for the evidence-and-importance map. Its account also shows why “we believe” is useful wording: it keeps a confident-sounding claim open to correction.
How Assumptions Mapping Can Focus Your Teams On Running ...
Read Strategyzer’s explanation to see how a team turns its beliefs into an initial risk priority, rather than ranking them by who argues most strongly.
Under “Write down your hypotheses,” read from testable beliefs. Under “Draw your 2x2 diagram,” read the axes, including the evidence and importance explanations. Finish with “Focus on the top right quadrant for experimentation,” reading the priority quadrant. Look for the question the authors use to judge importance when a belief proves wrong.
The axes are gradients, even though the drawing has four quadrants. “Have evidence” is not the same as “proved,” and “no evidence” should mean no relevant evidence found so far, not that the belief is necessarily false. Record what the evidence actually covers. A specialist saying a connection sounds useful is evidence of a stated preference; repeated use in a comparable workflow would speak more directly to adoption. Neither, by itself, proves that drafts become ready sooner.
Return to the illustrative 31 paused drafts. The count supports “pauses occurred in this sample.” Without reasons for those pauses, it offers little support for “manufacturer information caused a meaningful share of them.” Even if reasons were known, a single sample might not represent the customers targeted by the proposal. The evidence must match the claim.
Select the beliefs that could change the decision
Here is an illustrative first-pass map. The placements are provisional because the case supplies very little evidence; a real team would check operational records, customer behavior, technical documentation, and relevant permissions before settling them.
| Candidate assumption | Importance if false | Evidence in this case | Initial priority |
|---|---|---|---|
| Missing or conflicting manufacturer information explains a meaningful share of preventable pauses for the target customers. | High: the connection may address the wrong cause. | The 31-of-120 count shows pauses, not their cause. | Investigate early |
| The necessary systems can supply timely values with usable source attribution and authorized access. | High: the proposed connection may not be deliverable as designed. | None supplied. | Investigate early |
| Specialists can recognize and resolve flagged conflicts before the cutoff. | High: importing data may move, rather than remove, the delay. | None supplied. | Investigate early |
| A particular icon will make the conflict flag easier to notice. | Lower: other presentation choices are available. | None supplied. | Defer until the broader review workflow is clearer. |
The first three beliefs are not equally hard to investigate, but all sit near the important, little-evidence corner. The icon belief is also unsupported; that alone does not make it a leading risk. A useful priority conversation asks not only “What don’t we know?” but “What would we need to reconsider if we learned we were wrong?”
After mapping, sharpen the leading beliefs. For example, “the data is available” is too broad to evaluate. A more precise version is:
We believe the source systems used by the target customers can, with appropriate authorization, return a manufacturer value and its identifiable source early enough for a specialist to review an ISF draft before the internal cutoff.
That statement identifies the customers, information, conditions, and timing the proposal relies on. It remains an assumption, not a success claim. If evidence later shows that values arrive only after the cutoff, the team might need a different source, an earlier workflow intervention, or a different opportunity altogether.
The map should change as evidence arrives. A belief can move toward “have evidence,” be contradicted, or turn out to matter less because the team finds a workable alternative. Keep the reason for each change visible. That makes the map a record of learning rather than a permanent ranking of fears.
Takeaway
The riskiest assumptions are the beliefs most consequential to the proposal and least supported by relevant evidence. To find them, define the proposed integration and intended outcome, surface beliefs across customer value, use, delivery, business sustainability, and potential harm, then compare each belief’s failure consequence with the evidence actually available. For the customs-filing example, a count of paused drafts is a starting signal—not proof of the cause or of the proposed connection’s value.
Next, you will construct an opportunity-solution tree. The assumptions identified here will help you examine whether a proposed solution credibly connects a customer opportunity to the outcome you want, rather than treating the connection itself as the goal.