A customer mentions a painful handoff on Tuesday. By Thursday, an agent has designed a screen, written the code and opened a pull request. The team feels fast. Then the customer explains that the handoff happens twice a year, a workaround is good enough and the real problem sits one step earlier. The software works. The decision did not.
Continuous discovery, jobs-to-be-done research and assumption testing were built for this problem before generative AI made the gap so visible. Together they keep regular customer evidence close to the team making the product decision, connect that evidence to the progress a customer wants and test the belief most likely to make a solution fail. Discovery is not a phase that finishes before delivery starts.
AI makes solution production cheaper. This method makes sure a team does not confuse that new abundance with product progress.
One evidence-producing bet
Faster building raises the cost of choosing the wrong problem.
01 · Outcome
Name the change
Choose the customer and business result.
02 · Opportunity
Show the need
Link the problem to fresh customer evidence.
03 · Assumption
Find what may fail
Identify the belief that could break the idea.
04 · Test
Learn before building
Run the least work that changes the decision.
The method: connect every solution to an outcome
An opportunity solution tree is a visual account of how a team expects to reach a desired outcome. The outcome sits at the top. Beneath it are customer needs, pain points and desires, the opportunity space. Possible solutions branch from a chosen opportunity, followed by the assumption tests that help the team compare them.
The tree's value is not its geometry. It externalises the reasoning people usually carry in their heads. A teammate can ask why this customer problem matters, whether the team considered another path and which assumption could make the proposed solution fail. The own overview describes four levels: desired outcome, opportunity space, solution space and assumption tests.
The AI-era translation: give the agent a bet, not a backlog
A backlog gives an agent things to make. A bounded bet gives it something to learn. Before asking for a prototype, analysis or product change, establish:
- Customer group: the people whose problem is being considered.
- Desired outcome: the valuable change for the customer and the business.
- Opportunity: a need or pain supported by exact research, interaction or behavioural evidence.
- Riskiest assumption: value, usability, feasibility or business viability.
- Smallest test: the least work that can materially change the decision.
- Decision rule: what would justify continuing, changing direction or stopping.
The agent can then do valuable work across the loop. It can retrieve relevant calls, draft an interview snapshot, find contradictory observations, generate multiple solution approaches and prepare a cheap prototype. It can watch for an agreed signal. What it should not do is silently convert activity into validation or observation count into proof.
Keep fresh evidence close to the decision
Continuous discovery is demanding because it asks the people making the product to remain in contact with customers. An AI summary of six-month- old interviews does not make the evidence current. Nor does a synthetic persona count as a customer touchpoint.
Use AI to make genuine contact easier: prepare a focused question from the current opportunity, recruit an appropriate participant from a consented group, capture the conversation and connect the observation to the decision it may affect. Keep the raw source available. The summary should help the team return to the moment, not replace it.
This also protects product work from internal volume. A model can generate dozens of plausible features; recent customer evidence gives the team a reason to reject most of them. The point is not to suppress imagination. It is to spend it on the opportunity that matters now.
Match the test to the question and the available volume. A prototype or concierge test can expose misunderstanding with a handful of relevant customers. Once enough people encounter the same experience, a controlled experiment can estimate whether a change caused an outcome. Do not dress five interviews up as statistics, and do not wait for an A/B test when direct observation can invalidate the idea tomorrow.
Where the practice breaks
A discovery system can become a beautiful map of weak evidence. Teams may phrase a preferred feature as a customer opportunity, interview the easiest users rather than the relevant ones, or keep redrawing the tree while avoiding a real test. AI can add false precision by clustering ambiguous comments into themes that appear more settled than they are.
The correction is simple and uncomfortable: return to exact evidence. Can the team point to the interaction, file, metric or observed behaviour? Did a customer express the need, or did the team infer it? Was the test capable of changing anyone's mind? The reviewed decision should say both what the evidence supports and what remains unknown.
Questions for the operator
- What customer and business outcome is the team trying to change?
- Which exact interaction or behaviour makes this opportunity real?
- What is the smallest test of the assumption most likely to break the idea?
Choose one outcome your team already wants to improve. Pull the last five relevant customer conversations and ask the agent to extract needs, pains and desired outcomes with links back to each source. Review the candidates yourself. Choose one opportunity and list the assumptions behind the most obvious solution.
Test the assumption that could invalidate the idea with the least work. At the end, record one of three decisions: continue, change or stop, and why. That small lineage is more valuable than another page of roadmap ideas. For the commercial side of the same discipline, read positioning before AI-generated marketing; for evidence hygiene, see how to turn messy customer data into decisions.