# Approach Exploration

Use this reference for Phase 2 after the problem frame has enough shape to compare directions.

## When To Present Options

If multiple plausible directions remain, propose 2-3 concrete approaches based on research and conversation. Otherwise state the recommended direction directly.

Use at least one non-obvious angle when options would otherwise be variations on the same axis:

- inversion: what if we did the opposite?
- constraint removal: what if this limitation disappeared?
- analogy: how does another domain solve this?

When useful, include one deliberately higher-upside alternative: the adjacent addition or reframing that most increases usefulness, compounding value, or durability without disproportionate carrying cost. Present it as a challenger option, not the default. Omit it when the work is already over-scoped or the baseline is clearly right.

## Approach Shape

Present approaches first, then evaluate. Let the user see the option set before hearing the recommendation.

For each approach, include:

- brief description, 2-3 sentences
- pros and cons
- key risks or unknowns
- when it is best suited

At product tier, alternatives differ on what is built: product shape, actor set, positioning, or primary outcome. Implementation-variant alternatives belong at feature tier.

Approach descriptions name mechanism-level distinctions and product-relevant trade-offs, not code-level details. Do not name column names, table names, file paths, service classes, JSON shapes, exact method names, or other implementation details unless the brainstorm is explicitly about technical architecture.

After presenting all approaches, state the recommendation and explain why. Prefer simpler solutions when added complexity creates real carrying cost, but do not reject low-cost, high-value polish only because it is not strictly necessary.

If relevant, call out whether the recommended choice reuses an existing pattern, extends an existing capability, or builds something net new.