Iterative Discovery Goals Handler

Input: $ARGUMENTS

Overview

Handler for goals where SUCCESS IS DISCOVERING THE UNKNOWN, not executing a known plan. These goals are fundamentally different because: you don’t know what you’re looking for until you find it, the plan is to run experiments not execute steps, failure is information not setback, success comes from iteration speed not plan quality.

Steps

Step 1: Accept the Nature of Discovery

Before starting, reset expectations:

You CANNOT plan your way to discovery
You CAN plan your way to faster discovery
The goal is to INCREASE ITERATION SPEED and LEARNING QUALITY
Every experiment that doesn’t work NARROWS the search space (progress, not failure)

Step 2: Define the Discovery Space

What are you trying to discover/find/figure out?
What would “found it” feel like? (Recognition criteria, even if vague)
What have you already tried? What did you learn?
What is the search space? (How many possibilities exist?)
What constraints limit exploration? (Time, money, energy, access)

Step 3: Generate Hypotheses

Instead of a plan, create a hypothesis stack:

#	Hypothesis	Test	How Long	What I’d Learn
1	[if X then Y]	[smallest experiment]	[duration]	[what result would tell me]
2	[if X then Y]	[smallest experiment]	[duration]	[what result would tell me]
3	[if X then Y]	[smallest experiment]	[duration]	[what result would tell me]

Hypothesis quality checklist:

Is it testable? (Can you actually run the experiment?)
Is it informative? (Does the result change what you do next?)
Is it fast? (Can you get a result quickly?)
Is it cheap? (Can you afford to run it?)

Step 4: Design Experiments

For each hypothesis, design the minimum viable experiment:

EXPERIMENT:
Hypothesis: [what you're testing]
Test: [what you'll do]
Duration: [how long]
Success metric: [what a "hit" looks like]
Failure metric: [what tells you to move on]
What you'll learn either way: [information value regardless of outcome]

Experiment design principles:

Smallest possible test (don’t over-invest before you know)
Clear success/failure criteria defined BEFORE starting
Time-boxed (set a deadline — don’t let experiments drift)
One variable at a time (if possible — know what caused the result)

Step 5: Run, Measure, Learn, Iterate

Execute in rapid cycles:

Cycle 1:
  Experiment: [what was tested]
  Result: [what happened]
  Learning: [what this tells us]
  Next: [what to test next based on this]

Cycle 2:
  ...

After each cycle, update:

What do I now know that I didn’t before?
Has the search space narrowed? How?
Should I pivot direction based on what I learned?
Am I getting warmer or colder?

Step 6: Recognize Discovery Patterns

Convergence signals (getting closer):

Results are getting better across iterations
You’re finding what doesn’t work (narrowing the space)
Intuition is developing about what might work
You can articulate what you’re looking for more precisely

Divergence signals (need to change approach):

Results aren’t improving despite many iterations
You’re running the same type of experiment repeatedly
The search space isn’t narrowing
You feel stuck and can’t articulate why

If diverging: Change something fundamental:

Different dimension of the search space
Different type of experiment
Different assumptions about what “found it” looks like
Different domain or context
→ INVOKE: /ie (innovation engine) for non-obvious approaches

Step 7: Report

DISCOVERY PROGRESS:
Goal: [what you're discovering]
Experiments run: [N]
Hypotheses tested: [N tested / N remaining]

Search space status:
- Eliminated: [what you know DOESN'T work]
- Promising: [what seems worth exploring more]
- Unexplored: [what you haven't tried yet]

Current best: [closest thing to "found it" so far]
Convergence: [converging / flat / diverging]

Next experiment: [what to test next]
Why: [what you expect to learn]

Pivot consideration: [should you change approach?]

When to Use

Goal involves finding/discovering something unknown
Success requires experimentation, not execution
Need to test multiple hypotheses
The “right answer” will only be obvious in hindsight
Standard planning feels premature
→ INVOKE: /ge (guided experiments) for experiment design
→ INVOKE: /po (personal optimization) for self-experimentation
→ INVOKE: /dtl (design thinking + lean) for product discovery

Verification

Discovery nature accepted (not trying to plan linearly)
Search space defined
Hypotheses are testable, informative, fast, and cheap
Experiments have success/failure criteria defined BEFORE running
Learning captured after each cycle
Convergence/divergence assessed regularly

idg