Skip to main content
ClaudeWave
ES, Spanish
Skill755 estrellas del repoactualizado 8d ago

tool-foundation-sprint-magic-lenses

Magic Lenses is a Day 2 afternoon Foundation Sprint skill that evaluates three to seven candidate approaches through four classic lenses (customer, pragmatic, growth, money) plus at least one custom lens to surface trade-offs, identify consistent winners, and reveal contradictions. Use it after Approach Options is signed and the team has prepared a team-specific custom lens; it produces a top bet approach with explicit rationale and a backup plan to guide the Decider's decision.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/tool-foundation-sprint-magic-lenses && cp -r /tmp/tool-foundation-sprint-magic-lenses/skills/tool-foundation-sprint-magic-lenses ~/.claude/skills/tool-foundation-sprint-magic-lenses
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

# Foundation Sprint Magic Lenses

Day 2 afternoon of a Foundation Sprint. The team evaluates each candidate approach from multiple perspectives, surfaces contradictions, and produces a top bet plus a backup plan. The Decider names both; without an explicit backup, invalidation of the top bet sends the team back to ambiguous debate.

Family contract: [`docs/reference/skill-families/foundation-sprint-skills-contract.md`](../../docs/reference/skill-families/foundation-sprint-skills-contract.md). This skill is a member of `foundation-sprint-skills`.

## When to Use

- Day 2 afternoon of a Foundation Sprint.
- Approach Options is signed; the team has 3-7 candidate approaches advancing.
- The team has at least 1 team-specific custom lens prepared (per ratified spec decision; classic lenses alone are insufficient).

## When NOT to Use

- Approach Options is unresolved or under-numbered (fewer than 3). Force a third option through the approach-options skill first.
- The team has pre-committed to a top bet. Magic Lenses is a sense-making exercise; if the decision is already made, the time is better spent on Founding Hypothesis.
- The team is exhausted and cannot evaluate clearly. Postpone to Day 2 morning of a follow-up sprint rather than rush.

## What This Skill Produces

A single bundled artifact with six sections:

1. **Classic lens charts**: customer, pragmatic, growth, money lenses each as a 2x2 plot or qualitative position of every approach.
2. **Custom lens charts**: at least 1 team-specific lens (defensibility, mission fit, founder excitement, learning rate, etc.).
3. **Pattern review**: consistent winners across lenses, contradictions, biggest trade-off the team is making.
4. **Top bet**: the Decider's chosen approach with rationale.
5. **Backup plan**: the runner-up approach the team falls back to if the top bet invalidates.
6. **Decision rationale**: one paragraph explaining why the top bet over the backup.

See `references/TEMPLATE.md` for the canonical structure and `references/EXAMPLE.md` for the Brainshelf example.

## The Five Canonical Lenses

| Lens | What it asks | Why it matters |
|---|---|---|
| Customer | Which approach do target customers immediately understand and want? | If customers don't get it, nothing else matters |
| Pragmatic | Which approach can the team ship at quality in [build window]? | Beautiful approaches the team can't ship are not real options |
| Growth | Which approach gives the team a story strong enough to acquire users without paid channels? | Friction at the door tells you about word-of-mouth potential |
| Money | Which approach has the cleanest path to a paying customer? | Strategic clarity must include the revenue path |
| Custom (1+ required) | Team-specific lens that captures what would otherwise be missed | Each team has a unique constraint or opportunity worth a dedicated view |

Custom lens examples: defensibility against a specific competitor, founder excitement, mission fit, learning rate, regulatory risk, partner alignment, hiring leverage.

## Sequence (105 minutes)

### Step 1: Frame the lenses (5 min)

Facilitator restates the 4 classic lenses and confirms the 1 or more custom lenses the team prepared. If no custom lens is prepared, this skill prompts the team to generate one before proceeding (per ratified spec decision).

### Step 2: Score each approach per lens (40-60 min)

For each lens, plot each approach on a 2x2 of (high/low value on that lens) by (high/low feasibility for that lens). Use dot positions rather than numeric scores; arbitrary precision (3.7 vs 3.8) is a smell that the team has confused sense-making with math.

The team discusses each lens briefly before plotting. Decider does not vote in this step; the Decider supervotes at the end.

### Step 3: Pattern review (15-25 min)

After all lenses are plotted, the team identifies:

- **Consistent winners**: approaches that score in the top half of 3 or more lenses.
- **Consistent losers**: approaches that score in the bottom half of 3 or more lenses. These drop out.
- **Contradictions**: approaches that win one lens hard but lose another. These surface the trade-offs the Decider must make.
- **Biggest trade-off**: name it explicitly. "Boring-and-shippable vs risky-and-distinctive." "Mass-market vs niche-defensible." Naming the trade-off prevents the Decider from picking by vibes.

### Step 4: Decider supervote on top bet (10-15 min)

The Decider names the top bet. The chosen approach should be:

- A consistent winner OR a contradictory approach the Decider explicitly chooses to take the bet on.
- Defensible in language ("we are betting [trade-off] because [reason]").
- Aligned with the Mini Manifesto from Day 1.

### Step 5: Decider names backup plan (5-10 min)

The Decider names the backup. The backup is NOT a second-place approach to soothe whoever advocated for it; it is the approach the team will pivot to if the top bet fails validation. The backup MUST be distinct from the top bet in strategic direction.

If the top bet and backup are too similar, the Decider has not named a real backup. The skill prompts for a more distinct alternative.

### Step 6: Decision rationale (5-10 min)

The Decider authors one paragraph explaining why this top bet over this backup. The rationale will become the spine of the Founding Hypothesis's "why we believe this" section.

## Common Pitfalls

- **Treating lens scoring as mathematical truth.** Lenses are sense-making tools; if the team argues about whether an approach scores 3.7 or 3.8 on a lens, the team has lost the plot.
- **Skipping the custom lens.** The 4 classic lenses are generic by design. The custom lens is where the team's specific situation shows up; skipping it produces a generic top bet.
- **Falling in love with the top bet.** Confidence after Magic Lenses should be calibrated, not high. The next skill, Founding Hypothesis, asks "what could pr
chainSlash Command

Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)

define-hypothesisSkill

Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.

define-jtbd-canvasSkill

Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.

define-opportunity-treeSkill

Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.

define-prioritization-frameworkSkill

Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.

define-problem-statementSkill

Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.

deliver-acceptance-criteriaSkill

Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.

deliver-edge-casesSkill

Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.