Skip to concept
Protopilot

Explore possibilities Start before committing

What should we try before choosing a direction?

Try credible alternatives first. Each route makes a different trade-off visible before you spend effort building it.

Open the Protopilot demo Read the survey map
Coordinate
A costly situation to understand
Route
A belief made testable
Return line
Evidence that can redraw it

One study / open the question

Explore before you choose.

This public example keeps one Protopilot study in view. Pick a route to see what it makes explicit, what it tests, and what it deliberately leaves out.

Choose one route to inspect

Selected possibility

Guided test composer

Premise
A distinct interface for the same selected hypothesis, domain revision, and task.
Proposed path
Create a tester flow named “Choose a plan without assistance” for the Checkout confidence project.
Linked testable assumption
After framing a problem and hypotheses, product leads will create a tester flow before asking engineering to build.
Deliberately excluded
No participant evidence is created by this local comparison.

Guided test composer is selected locally. Compare this route before deciding what to test.

Local simulation · not recorded.

 Next: Find quality

What stays linked

A route is useful only when it can be tested.

Question
What is the least work that can change a belief?
Method
The people, setting, cost, alternate traversals, and shortest testable route.
Expected signal
Evidence from a screened tester can revise the exact claim and redraw the map.

Survey notes / before destination

Record the situation before choosing a solution.

Begin with what can be observed about the people, the setting, and the cost. A feature is not evidence that the situation exists.

OBS A / audience

Product lead

Leads a small product team and worries that AI speed turns untested assumptions into commitments.

Qualifying trait: Uses AI-assisted tools to explore or build product ideas
OBS B / context

The first version already looks shippable.

AI-assisted builders make a convincing first version feel close enough to ship.

OBS C / friction + stakes

Polish hardens a guess.

Teams turn untested assumptions into polished software too early, making it expensive to learn whether a real problem exists.

One survey / three connected spaces

Move from problem to the smallest useful test.

Each space reduces uncertainty for the next. The chain remains visible so a later finding can be traced back to the belief it changes.

  1. 01 Problem space terrain recorded

    No destination yet

    Problem is terrain.

    For product teams using AI-assisted builders, the costly situation is committing engineering time before the underlying user, problem, and solution beliefs are explicit.

    Audience
    Product teams using AI-assisted builders
    Cause
    The underlying user, problem, and solution beliefs are not made explicit or tested first.
    Severity
    blocking
  2. 02 Hypothesis space alternates exposed

    More than one route can lose

    Hypotheses are alternate traversals.

    Each route names what must be true and how contact with the field could change it.

    1. R1

      Teams at risk of premature commitment already use AI-assisted tools to explore or build product ideas.

      Test by
      screener
      Can lose if
      a qualified answer contradicts the claim
    2. R2

      Product leads using AI-assisted builders want a structured way to expose assumptions before creating a working app.

      Test by
      screener
      Can lose if
      a qualified answer contradicts the claim
    3. R3

      After framing a problem and hypotheses, product leads will create a tester flow before asking engineering to build.

      Test by
      usage
      Can lose if
      a qualified lead will not create a tester flow
  3. 03 Solution space minimum inked

    Selected route / R3

    Solution inks only the shortest testable traversal.

    The prototype does not imitate a finished product. It includes only the screens a tester needs to produce evidence about the selected assumption.

    1. 01Establish ContextCapture the audience, persona, and costly situation before choosing a solution.
    2. 02Make assumptions falsifiableTurn beliefs into linked hypotheses with a confidence and test method.
    3. 03Compose a tester flowConnect a prototype journey and screener to the assumption it should test.

    Everything beyond this test stays unbuilt.

Tester validation / outside the map

Route evidence back to the claim it can change.

Tester validation is not a fourth product space. It is the outside contact that screens for relevant experience and routes each answer to its linked assumption. The R1 screener updates audience context; it does not count prototype behavior as evidence for R3.

Incoming / qualification context

Field report

R1 return
Qualifying screen
Does your team currently use AI-assisted tools to explore or build product ideas?
Assumption evidence / R1
A participant’s “yes” supports and qualifies; “no” refutes and screens out. The linked claim is: Teams at risk of premature commitment already use AI-assisted tools to explore or build product ideas.
Separate session events
screen_view, interaction, flow_completed, and flow_abandoned remain usage events. They are not screener answers.
Evidence boundary
This answer can update qualification context. It cannot support the R3 claim that product leads will create a tester flow.

The return path redraws only the claim its question names. R3 waits for its own usage evidence.

Your first coordinate

Start with the costly situation.

Open the Protopilot demo to map the Protopilot project from problem through tester evidence.

Start the field map