Your team has customer interviews, a credible opportunity, a polished prototype, and an engineering estimate. The idea can still fail because each of those artifacts may leave the same quiet beliefs untouched: that customers will change their behavior, that the workflow will create enough value, that the system can handle real conditions, and that people will understand and trust what it does.

The dangerous assumption is rarely the one being debated. It is the one nobody realizes has been made. You need a way to expose those beliefs, decide which could sink the idea, and test them before implementation turns uncertainty into sunk cost.

Key takeaways

• A product idea is a bundle of assumptions, so a positive reaction to the whole concept does not validate every condition required for success.
• Look for assumptions across desirability, viability, feasibility, usability, and ethics. A team that examines only customer demand and technical delivery is leaving major risks unnamed.
• Map the user’s journey before brainstorming assumptions. Each action, handoff, decision, and recovery step reveals another condition that must hold.
• Test assumptions with weak evidence and high importance first. Do not start with whatever is easiest to prototype.
• Define in advance what evidence would change the decision. Otherwise, almost any result can be interpreted as support for the preferred idea.

Stop asking whether the whole idea is good

“Is this a good idea?” sounds like a discovery question, but it is too broad to produce a useful answer. A solution can be attractive in a demo and still depend on false beliefs about adoption, economics, permissions, reliability, or the surrounding workflow.

Consider an AI assistant that prepares an account brief before a sales call. A customer might like the concept. That reaction does not tell you whether representatives will open the brief at the right moment, whether the connected records are complete enough, whether restricted notes stay restricted, whether users can separate facts from inferences, or whether the operating cost fits the product’s commercial model.

A whole-idea test mixes these questions together. If the response is positive, the team tends to treat the concept as validated. If the response is negative, the team may discard a useful mechanism because one part of its presentation or workflow was weak. Either way, the result is hard to diagnose.

Replace the verdict with a conditional argument:

This solution will produce the intended outcome if these specific beliefs are true.

An assumption is one of those beliefs without adequate supporting evidence. It is not merely a topic the team has not discussed. It must be a claim that could be wrong and whose failure would affect the solution.

Keep four kinds of statements separate during discovery:

• Fact: Evidence currently supports the statement. Record where the evidence came from and the context in which it applies.
• Assumption: The team believes the statement, but the available evidence is weak, indirect, old, or incomplete.
• Decision: The team has chosen a direction, such as a target segment or launch channel. A decision can be changed, but it should not masquerade as customer evidence.
• Constraint: A boundary such as a contractual commitment, permission model, budget, or platform limitation. A constraint may be negotiable, but it is not something a customer test validates.

This distinction prevents a common discovery failure: treating an internal decision as if it were an externally verified truth. “This feature is for administrators” is a targeting choice until evidence shows that administrators have the problem, authority, motivation, and workable path to value.

Write each important assumption as a complete claim:

For this solution to succeed, we believe [actor] will or can [observable behavior or outcome] in [relevant context]. We currently believe this because [evidence].

The template forces you to name the actor, the required behavior, the context, and the evidence gap. “Users want AI summaries” is too vague. “Account executives preparing for calls will open an automatically generated brief inside the CRM and use it without returning to several source systems” is testable. It also exposes several smaller assumptions hiding inside the sentence.

Surface assumptions across five failure modes

Product ideas typically depend on five families of assumptions: desirability, viability, feasibility, usability, and ethical acceptability. The categories are useful because teams naturally overproduce assumptions in the areas closest to their expertise. Engineers may see system dependencies first. Designers may see interaction risks. Commercial leaders may focus on demand and economics. The category that feels hardest to populate is often where the team needs a more deliberate review.

Assumption family	Question to answer	Example for an AI account-brief assistant
Desirability	Will the intended person choose the required behavior strongly enough to create value?	Representatives will open the brief before a call and change how they prepare.
Viability	Can the organization support, distribute, and sustain the solution under its business constraints?	The value and adoption will justify the continuing inference, integration, and support burden.
Feasibility	Can the product work under representative technical and operational conditions?	Connected data will be current, permission-aware, and sufficient to generate a useful brief.
Usability	Can people understand, operate, and recover from the solution without inappropriate help?	Representatives can distinguish sourced facts from model inferences and correct a misleading item.
Ethical	Could the solution create avoidable harm, unfairness, deception, or inappropriate data use?	The brief will not expose restricted notes or present uncertain inferences as established facts.

The third column is not evidence. It is a set of claims that need evidence. That distinction matters because a well-written assumption can feel true merely because it sounds precise.

Desirability is about behavior, not polite approval

Customers can want an outcome without wanting the actions your solution requires. They may want better account preparation but refuse to connect sensitive systems. They may like an AI-generated brief but continue using a familiar document. They may value accuracy while rejecting the review effort needed to maintain it.

Ask what the customer must start doing, stop doing, disclose, learn, trust, or pay for. Then test that behavior or commitment as directly as the stage of discovery allows. General enthusiasm is weak evidence when success requires a specific workflow change.

Viability is broader than a revenue forecast

A feature can attract users and still be a poor business choice. It may create an expensive support obligation, depend on a sales motion the organization cannot execute, conflict with product positioning, or consume more resources than its value can support.

Name the business mechanism. Is the solution expected to improve acquisition, activation, retention, expansion, efficiency, or strategic differentiation? Which customer behavior connects the feature to that effect? If nobody can explain the chain, the team has a desired business result rather than a viability hypothesis.

Feasibility includes the conditions around the model

For an AI product, “the model can generate a good answer” is only one feasibility claim. The useful question is whether the complete system can generate an acceptable result with the data, permissions, latency, cost, integrations, failure modes, and operating controls that the product will actually have.

Use representative inputs and boundary cases when you investigate feasibility. A hand-selected prompt with clean context may demonstrate possibility while saying little about production conditions. Also separate what can be built once from what can be operated repeatedly.

Usability includes recovery, not just the happy path

A person must be able to notice when something is wrong, understand the consequence, and recover without creating a larger problem. This is especially important when generated output looks fluent even when its basis is incomplete or uncertain.

Map how users inspect sources, edit output, reject a recommendation, undo an action, request help, and return to the task. If safe recovery depends on expert knowledge that the target user does not have, the interaction is not yet usable for that audience.

Ethics belongs inside discovery

Ethical questions are product assumptions because they affect who receives value, who carries risk, and whether the solution deserves continued use. Ask whose data is used, who did not choose the workflow, who could be misrepresented, and which mistakes are difficult to reverse.

Do not reduce this category to a final compliance check. A permission audit can reveal that the proposed value depends on data the product should not expose. A harm scenario can show that automation needs human review. Those findings change the product concept, not merely its launch checklist.

Use the user journey to expose what brainstorming misses

A blank page invites generic claims such as “customers will trust it” or “engineering can build it.” A journey forces the team to inspect the mechanism through which value is supposed to appear.

Assume the solution already exists. Map what each actor does from the first trigger to the intended outcome. Do not map engineering tasks, architecture components, or sprint sequencing. The subject of the map is the person using, configuring, approving, supporting, or being affected by the product.

1. Name every consequential actor. For a business product, that may include an end user, administrator, manager, approver, affected customer, or support operator. Do not collapse people with different incentives into “the user.”
2. Start with the trigger. State what makes the actor enter the workflow and why this moment matters.
3. Map visible actions. Include finding the entry point, supplying information, making decisions, reviewing output, sharing it, and acting on it.
4. Add handoffs and waiting states. Value often depends on another person, system, permission, or data refresh. Those dependencies deserve their own steps.
5. Add failure and recovery paths. Show what happens when information is missing, an integration fails, a recommendation is wrong, or the actor rejects the output.
6. End at the outcome, not feature use. Opening a brief is usage. Entering a better-prepared customer conversation is closer to value.

Now move through the map one step at a time. For each action, ask:

• Why would this actor take this step now?
• What must the actor know, notice, understand, or trust?
• What information, permission, integration, or system behavior must be available?
• What business condition must remain true for this step to be supportable?
• Who else could be affected if this step succeeds or fails?
• What happens when the expected path breaks?

A focused product trio can use a 60-minute story-mapping exercise and aim to generate at least 15 to 20 assumptions. Treat that count as a forcing function, not a quality score. The first few statements usually describe the visible idea. Later statements tend to reveal switching behavior, dependencies, edge conditions, and consequences that were bundled into it.

Run a pre-mortem after the first pass. Imagine the solution launched but did not produce the intended outcome. Ask each participant to write plausible reasons independently before discussing them. Independence matters because the first explanation spoken aloud can anchor the rest of the room.

Turn each failure reason into an assumption. “Administrators never finished setup” becomes “An administrator with the required permissions will complete setup before the end user needs the feature.” “Representatives ignored the briefs” becomes “The brief will appear early enough in call preparation to replace part of the existing routine.” The failure language helps expose the mechanism; the assumption language makes it testable.

Do not debate each assumption while generating the list. Early evaluation narrows the search and rewards the person with the most confidence. Capture the claims first. Consolidate duplicates and improve wording afterward.

Find the leap-of-faith assumptions before choosing tests

A long assumption list is not a discovery plan. If every item receives equal attention, the team will often test what is convenient: a button label, a prototype preference, or a technical question that can be answered quickly. The consequential uncertainty remains untouched.

Map assumptions on two dimensions:

• Importance to success: How much does the solution depend on this being true?
• Strength of existing evidence: How well does current evidence support the claim in the relevant context?

Relative placement is enough. The purpose is to decide which beliefs deserve attention first, not to manufacture precise risk scores. A team can place the assumptions quickly, spending no more than about 10 minutes, and select two or three that combine high importance with weak evidence. Those are the leap-of-faith assumptions.

Judge importance by dependency, not drama. Ask what happens to the idea if the claim is false:

• Does the value mechanism collapse?
• Can the affected step be removed or redesigned?
• Would the solution still work for a narrower segment?
• Would failure create a recoverable inconvenience or a serious trust, data, or business consequence?
• Would learning later force an expensive change to the product’s architecture, workflow, or positioning?

Judge evidence by its fit to the claim. Evidence is stronger when it comes from the intended actor, relevant context, required behavior, and realistic conditions. It is weaker when it is based on internal conviction, analogy to a different segment, a customer’s general opinion, idealized inputs, or a proxy several steps removed from the behavior you need.

Evidence can also be real and still be insufficient. Customer interviews may establish that a problem matters, but they may not establish that customers will grant data access or replace an existing workflow. A technical prototype may show that generation is possible, but not that the result is reliable under representative permissions and data quality. Match the evidence to the exact sentence you are trying to support.

When participants disagree about placement, do not average the disagreement away. Ask what evidence each person is using. You may discover that one participant has relevant information nobody else has seen, that two people are interpreting the assumption differently, or that confidence rests on an undocumented belief. The disagreement is discovery data.

Keep more than one solution in view when possible. If the team is attached to a single concept, assumption testing can become a search for permission to proceed. Comparing alternatives changes the question from “Can this idea survive?” to “Which path reaches the outcome with the fewest unsupported critical beliefs?”

Match the test to the assumption and the decision

Do not choose a prototype, experiment, interview, or technical spike before you identify the assumption. A test is useful only when its result can change a decision.

Create a small test card for each leap-of-faith assumption:

1. Assumption: Write the exact claim in one sentence.
2. Importance: Explain what breaks if it is false.
3. Current evidence: Record what is known and why it is not enough.
4. Decision: Name the choice the result will inform.
5. Method: Choose the smallest credible way to close the evidence gap.
6. Signal: Define what you will observe or measure.
7. Decision rule: State what result would support, weaken, or leave the assumption unresolved.
8. Owner and evidence location: Make the learning inspectable instead of leaving it in a meeting or a person’s memory.

Set the decision rule before collecting results. If the threshold is chosen afterward, the preferred idea can influence what counts as success. Derive the threshold from the behavior, economics, operating requirement, or risk tolerance the solution actually needs. An arbitrary pass mark creates precision without relevance.

Assumption	Useful test shape	Look for	Do not mistake for proof
Desirability	Prototype task, concierge workflow, invitation, or other realistic commitment	Whether the intended actor takes the required step in context	General praise, stated interest, or enthusiasm for the outcome
Viability	Business-mechanism model using explicit inputs and sensitivities	Whether plausible customer behavior connects to a supportable business result	A top-line opportunity estimate with no adoption, delivery, or operating mechanism
Feasibility	Narrow technical spike using representative data and boundary conditions	Whether the system meets the requirement under relevant constraints	A successful demonstration using curated inputs and manual work hidden from view
Usability	Observed task with a realistic prototype, including an error or recovery path	Whether the actor notices, understands, completes, and recovers without inappropriate coaching	Preference for the design or completion after the facilitator explains it
Ethical	Permission audit, harm scenario, adversarial review, or affected-party walkthrough	Who can be harmed, how the harm occurs, and whether the concept can prevent or limit it	A generic principle or approval that does not inspect the actual workflow and data

Test one assumption at a time when you need diagnostic clarity. Combine assumptions only when the method still lets you tell which claim the evidence supports. A realistic workflow test may examine desirability and usability together, for example, but the observation plan should keep the two distinct: did the person choose to begin, and could the person complete the task?

For AI products, include failure handling in the test. Do not evaluate only whether the system can produce a convincing response. Examine what happens when context is missing, permissions differ, sources conflict, confidence is unclear, or the user disagrees. The product’s value may depend less on an ideal answer than on whether a person can detect and contain an imperfect one.

End every test with one of four explicit decisions:

• Proceed: The evidence is adequate for this assumption, so move to the next critical uncertainty.
• Modify: The underlying opportunity remains credible, but the solution or target segment needs to change.
• Run the next test: The result was inconclusive, and another specific evidence gap remains worth closing.
• Stop: A critical condition is false and no reasonable adaptation preserves the value mechanism.

“Proceed” does not mean the entire idea has been validated. It means one material uncertainty has been reduced enough for the current decision. Product discovery is a sequence of conditional decisions, not a ceremony that turns a concept from unvalidated to validated.

Make assumptions visible in routine product work

Assumption testing becomes useful when it changes how commitments are made. Add an assumption ledger to the normal discovery workspace. For each material claim, record its category, wording, importance, current evidence, evidence gaps, owner, latest decision, and links to supporting material.

Use the ledger in three moments:

• Before committing substantial delivery capacity: Show which leap-of-faith assumptions remain and why the planned investment is proportionate to the evidence.
• During discovery reviews: Start with what changed in the evidence and decision, not a tour of activities completed.
• After a disappointing result: Trace which assumption failed, whether it had been identified, and why the available evidence did not change the decision earlier.

This also improves stakeholder conversations. Instead of defending a recommendation as certainty, present it as a transparent case: the opportunity is supported by specified evidence; this solution depends on named assumptions; these are the weakest critical claims; and these tests will determine whether to proceed, modify, or stop.

Take one live solution into your next discovery session. Map the actors from trigger to outcome, generate the assumptions hiding in each step, and rank them by importance and evidence. Then choose the single assumption whose failure would most change the decision. If you cannot state what result would change your mind, fix that sentence before you build the test.

References

• Product Talk — Ch. 9: Identifying Hidden Assumptions

---