Product Discovery in the Experience-First Model

Product discovery has always been about reducing uncertainty before commitment.

But the traditional discovery process was designed for a world where exploration was expensive. We wrote specifications because building was slow. We created decks because alignment took weeks. We separated "discovery" from "delivery" because the cost of being wrong late was catastrophic.

That world is disappearing.

When AI can generate prototypes in minutes, synthesize research in seconds, and scaffold entire systems before lunch, the economics of discovery fundamentally change.

This is what product discovery looks like in the experience-first model.

The Core Principle

AI accelerates learning, not decisions.

AI helps explore, reframe, challenge, and synthesize ideas. It does not decide what we build.

This distinction matters because accountability cannot be delegated to a language model. Viability, usability, feasibility, and scope validation are performed with stakeholders, users, architects, and engineers. AI supports preparation, not judgment.

The earlier the artifact, the cheaper it is to change. AI is most valuable when uncertainty is high and commitment is low.

Phase 1: Ideation as a Living Document

Every initiative starts with a lightweight markdown document.

Not a specification. Not a commitment. A thinking tool.

The goal is clarity, not correctness.

What the document contains

Problem statement
Who this is for
Why now
Initial hypothesis
Known constraints
Open questions

How AI participates

AI helps brainstorm and expand rough ideas, turn vague thoughts into structured problem statements, reframe ideas from different angles, and surface implicit assumptions.

But the human decides which reframe is valuable. AI generates options; judgment selects among them.

This aligns with Principle 8: Prototype to learn, validate to decide.

At this stage, we're not prototyping software — we're prototyping understanding. The document is the prototype. AI accelerates its evolution.

Phase 2: Stress-Testing Before Stakeholders

Before involving stakeholders, deliberately try to break the idea.

This reduces confirmation bias and improves the quality of subsequent discussions.

How AI participates

AI critiques from sales, engineering, and leadership perspectives. It runs generic viability checks and identifies loopholes and weak assumptions.

The output is not a verdict. It's a better set of questions.

Who validates viability

Viability validation is cross-functional:

Product — problem framing, value proposition, prioritisation
Engineers — early sanity checks on delivery and technical implications
Architects — platform fit, dependencies, scalability signals
Sales & Leadership — market demand and strategic alignment

AI prepares for these conversations. Humans have them.

This is Value 2: Customer Control over Product Control.

The customer — whether internal or external — defines what viable means. AI helps us ask better questions. It doesn't answer them.

Phase 3: Alignment Through Conversation, Not Decks

Slides are not the source of truth. They exist to communicate the current state of thinking, enable discussion, and create shared understanding.

How slides are created

Derived from the ideation document, focusing on:

The problem and opportunity
Why this matters now
Key assumptions and risks
Open questions

AI tailors tone, summarises for specific audiences, and sharpens messaging.

What happens after discussions

Meetings are recorded when possible. AI summarises discussions, extracts objections, captures decisions, and lists unresolved questions.

The ideation document is refined. Assumptions are corrected or removed.

This creates a lightweight learning trail and avoids re-litigating decisions.

This is Principle 2: The system must teach itself through its own feedback, not training manuals.

The documents evolve as understanding evolves. There is no separation between "the spec" and "what we learned."

Phase 4: Convergence into Commitment Artifacts

The move from ideation to commitment happens only when:

Viability is sufficiently validated
Stakeholders are broadly aligned
Remaining risks are understood

The PR+FAQ format

Using a working-backwards approach, AI helps draft a press release and FAQ document that forces clarity on:

What we're building
Who it's for
Why they'll care
What questions they'll ask

This format exposes fuzzy thinking. If the FAQ can't be answered cleanly, the idea isn't ready.

This is Value 3: Clarity over Cleverness.

A clever idea that can't be explained simply isn't ready for commitment. The PR+FAQ format is a clarity gate, not a marketing exercise.

Phase 5: Prompt-Driven Prototyping

Important distinction: at this stage, we're primarily working on the prompt, not the prototype itself.

What prototype.md contains

Using validated artifacts, create a structured prompt for AI-powered prototyping tools:

Purpose & scope: what the prototype should demonstrate
Target users / personas
Key user flows (happy path + critical edge cases)
Screens & interactions to be generated
Design constraints (design system, accessibility, brand)
Open questions & riskiest assumptions to test
Non-goals (what the prototype should explicitly not solve)

Why the prompt matters

The prompt is the bridge between validated intent and generated artifact.

A sloppy prompt produces a sloppy prototype. The discipline of writing a precise prompt forces the same clarity that traditional specifications aimed for — but with immediate feedback.

This is Principle 5: Application logic must not dictate organisational reality.

The prompt adapts AI to our needs. We don't adapt our process to AI's assumptions.

Phase 6: Product-Owned Prototype for Feasibility

The prototype created at this stage is product-owned and exists to align on intent, scope, and feasibility — not to finalise UX or visual design.

How it works

Using the prompt, generate a first-pass prototype. Spend limited time (an hour or two) iterating to see:

What kind of prototype the prompt produces
Whether the core flows and mental model are represented
Where assumptions or gaps become visible

This prototype is intentionally rough.

Three purposes

Feasibility validation — Share with architects, engineers, and product peers. Align on the shape of the solution and overall scope.
Flow and scope alignment — Validate the big ideas around user flows. Sanity-check interactions that are "common sense" from a product perspective.
Incremental delivery thinking — Explore prototypes for MVP, what could come next, and what could be deferred.

What this prototype is not

Not aligned to the design system
Not final UX
Not a handover artifact for engineering
Not a replacement for UX design work

This is Principle 7: Design for recovery, not perfection.

The prototype exists to find problems early, not to be perfect. Rough is a feature, not a bug.

Phase 7: UX-Owned Prototype for Design Quality

Once feasibility and scope alignment are achieved, context — not a design — is handed over to the UX team.

The UX team creates their own prototype, based on:

UX expertise and philosophy
Design system and guidelines
Accessibility and consistency requirements

Why two prototypes can exist

It is normal and intentional to have two prototypes for the same initiative:

Product-owned prototype: Focused on intent, flows, feasibility, and scope alignment
UX-owned prototype: Focused on design quality, consistency, and user experience

They serve different purposes and should not be conflated.

This is Value 4: End-to-End Journeys over Isolated Interfaces.

The product prototype validates the journey. The UX prototype ensures every touchpoint in that journey is designed, not just functional.

Phase 8: Proof of Concept for Technical Validation

The Proof of Concept exists to validate the riskiest assumptions identified during feasibility validation.

These are assumptions where: If this does not work, the entire approach collapses.

How the PoC scope is defined

Extracted from the UX-owned prototype and validated intent:

Explicit riskiest assumptions
Minimal functional behaviours that must be proven
Technical unknowns that could invalidate the solution
Constraints that impact delivery, scalability, or operability

The goal is not completeness — it is proof.

How AI participates

Engineers use AI-assisted tools to generate scaffolding and exploratory code, rapidly test technical assumptions, and accelerate spike and experiment creation.

The expectation is not production-ready code, but:

"It works on my machine" evidence
Clear signals on feasibility and constraints

What the PoC produces

Realistic technical scope required for implementation
Deployment and operational considerations
Required APIs and integration contracts
Dependencies on open-source or third-party components
Clear feasibility limits and trade-offs

This is Principle 10: Friction anywhere degrades trust everywhere.

Technical friction — integration complexity, operational burden, scalability limits — is friction the customer eventually feels. The PoC surfaces it before commitment.

The Natural End of Discovery

At this point:

Desirability has been validated (UX prototype)
Viability has been assessed (stakeholder alignment)
Feasibility has been proven with evidence (PoC)

Discovery has done its job.

From here, the focus shifts to delivery with confidence.

Where AI Does Not Belong

AI does not participate in:

Final prioritisation decisions
Customer truth or user validation
Architectural sign-off
Scope commitment
Go / no-go decisions

These are human responsibilities. AI can prepare the inputs. It cannot make the call.

Why This Framework Works

This approach reduces the cost of being wrong early, surfaces risks sooner, improves clarity before commitment, and makes stakeholder discussions more productive.

AI improves thinking velocity. Quality still comes from validation, judgment, and experience.

The Experience-First Manifesto argues that experience is the product. In discovery, this means:

The experience of discovering is the product of the discovery process.

If discovery feels like bureaucratic checkbox-filling, the artifacts it produces will be bureaucratic checklists.

If discovery feels like collaborative learning with rapid feedback, the artifacts it produces will reflect that clarity.

AI doesn't change what discovery is. It changes what discovery can feel like — and therefore, what it can produce.