What is spec-driven discovery for AI product teams?

Spec-driven discovery is a way of running product discovery where research, strategy, assumptions, experiments, decisions, and product specs are written as machine-readable documents.

The goal is simple: humans and AI should work from the same source of truth.

That usually means:

• markdown documents
• clear templates
• version control
• linked artifacts
• explicit decisions
• current assumptions
• product context close to code and data

The spec is not a handover document at the end.

It is the working surface for discovery.

Most product teams use AI in shallow ways.

They ask it to summarise interviews.

They ask it to draft PRDs.

They ask it for generic ideas.

That can save a little time, but it rarely changes the quality of the work.

The reason is context.

The AI does not know the product history, the current strategy, the technical constraints, the experiments already run, or the decisions the team has already made.

So it guesses.

The output sounds useful, but it is often too generic to trust.

Spec-driven discovery fixes the context problem first.

Product thinking often lives in too many places.

Research sits in one tool. Strategy sits in another. Decisions disappear into chat. Specs drift away from code. Metrics live in dashboards most people do not check during discovery.

AI tools then sit beside the work, trying to help without the full picture.

That creates context islands.

Spec-driven discovery brings the important context together:

• what the product is trying to achieve
• who it serves
• what the team believes
• what the team has learned
• what has already been tried
• what constraints exist
• what decisions have been made
• what still needs evidence

This does not mean one giant document.

It means a linked set of small, structured files that stay current.

A practical spec-driven discovery workspace can start with a structure like this:

product/
├── CONTEXT.md
├── STRATEGY.md
├── DISCOVERY.md
├── research/
│   ├── interviews/
│   ├── themes.md
│   └── behavioural.md
├── experiments/
│   ├── active.md
│   └── completed/
└── decisions/
    └── ADRs/

Each file has a job.

CONTEXT.md explains the product, audience, constraints, and important metrics.

STRATEGY.md explains the desired outcomes, bets, and priorities.

DISCOVERY.md holds the current opportunity tree, active hypotheses, and open questions.

Research files preserve evidence.

Experiment files preserve what was tested and what was learned.

Decision records preserve why the team chose one path over another.

This is not documentation theatre.

It is operational context.

When the discovery base is structured, AI can do more than summarise.

It can help the team reason.

For example:

• after an interview, ask whether the notes add a new opportunity or strengthen an existing one
• after reviewing an opportunity tree, ask for hypotheses tied to a specific opportunity
• before running an experiment, ask which assumptions could falsify the idea
• before shipping a spec, ask whether it conflicts with prior decisions or known constraints
• as the knowledge base grows, ask the system to find contradictions or stale assumptions

The difference is not that the AI is smarter.

The difference is that it has better context.

It can see the chain from research to opportunity to hypothesis to experiment to decision.

The most useful format is cross-functional.

A designer, PM, engineer, and sometimes data partner work together in the same discovery workspace. One person drives the document. The others contribute judgement. AI reads the same context and helps pressure-test the work.

A session might look like this:

1. Review new research and update the opportunity tree.
2. Pick the highest-priority open opportunity.
3. Generate and critique hypotheses.
4. Design the smallest experiment that can test the riskiest assumption.
5. Update the discovery files with decisions and next steps.

The AI is not the decision-maker.

It is also not the note-taker at the end.

It is a collaborator with access to the shared context.

Spec-driven discovery changes the quality of collaboration.

First, AI output becomes more specific because it is grounded in current product context.

Second, onboarding becomes easier because the state of the problem is readable in one place.

Third, handovers become less brittle because decisions, evidence, and constraints are linked.

Fourth, feasibility can enter discovery earlier. If the discovery base is connected to code and system context, teams can see technical constraints while shaping the idea, not after the idea has already become a polished story.

The point is not to make product teams write more.

The point is to make the thinking durable enough for people and AI to use.

You do not need a new platform to start.

Start with two files:

1. CONTEXT.md
2. DISCOVERY.md

In CONTEXT.md, write:

• who the product serves
• the current business goal
• the main user problem
• the known constraints
• the important metrics
• the systems or teams involved

In DISCOVERY.md, write:

• the current opportunity
• active hypotheses
• evidence gathered so far
• open questions
• experiments running now
• decisions made

Keep those files current for one month.

Then use AI against them.

Ask sharper questions. Look for contradictions. Generate hypotheses. Review specs. Trace decisions back to evidence.

The practice matters more than the tooling.

A good spec-driven discovery system should pass one test:

Could a smart new team member understand the current product problem without needing five meetings?

If the answer is no, AI will struggle too.

The same context that helps a person onboard helps AI reason.

That is the deeper point.

Spec-driven discovery is not about making documents for machines. It is about making product thinking explicit enough that people and machines can work from it together.

Richard Simms is Principal Product Designer at SEEK, where he leads design for the Career Discovery Agent and Career Feed. He also builds Sentiuma, a personal AI knowledge infrastructure layer.