Strategic Prototyping: Build What Matters

When This Skill Activates

Claude uses this skill when:

User asks "should I build this?" or "is this worth it?"
Making architectural decisions (reusable component, abstraction, etc.)
Evaluating feature requests
Distinguishing busy-work from high-impact work
Preventing premature optimization or "product theater"

Core Frameworks

1. The LNO Framework (Source: Shreyas Doshi, ex-Stripe/Twitter/Google PM)

Leverage, Neutral, Overhead:

"Not all tasks are created equal. Some tasks compound (Leverage), some maintain (Neutral), and some drain without return (Overhead)."

Use when: Prioritizing what to build or evaluating if work is strategic

The Three Categories:

🚀 Leverage Work (10x multipliers)

Compounds over time
Enables future work
Used repeatedly
Examples: Design systems, core infrastructure, strategic features

➡️ Neutral Work (1x necessary)

Maintains current state
Necessary but doesn't compound
One-time impact
Examples: Bug fixes, minor UX tweaks, maintenance

⚓ Overhead Work (0x drain)

Busy-work that doesn't move needle
"Product theater" - looks like PM work but isn't
Process for process's sake
Examples: Excessive docs, meetings about meetings, vanity features

How to Apply:

For any work request, ask:
1. Will this be used 10+ times? (Leverage candidate)
2. Does this unblock future work? (Leverage candidate)
3. Is this maintaining vs building? (Likely Neutral)
4. Is this just "looking busy"? (Overhead - avoid)

BUILD: Leverage > Neutral > Overhead
RATIO: Aim for 70% Leverage, 20% Neutral, 10% Overhead max

Example:

Request: "Make this component reusable across the app"

LNO Analysis:
- Will we reuse it 10+ times? 
  YES → Leverage work, do it
  NO (only 2-3 uses) → Neutral/Overhead, build specific first

- Does it unblock future teams?
  YES → Leverage (design system contribution)
  NO → Wait until 3rd use case, then refactor

2. The Three Levels of Product Work (Source: Shreyas Doshi)

Impact, Execution, Optics:

"Most execution problems are actually strategy problems. Most failed launches had unclear strategy, not bad execution."

The Hierarchy:

Level 1: IMPACT (Why)

What outcome matters?
Why does this move the business?
What problem are we solving?
Failure mode: Building without clear success criteria

Level 2: EXECUTION (How)

How do we build this well?
Technical decisions
Quality standards
Failure mode: Great execution on wrong problem

Level 3: OPTICS (Perception)

How does this look to stakeholders?
Updating status, demos, comms
Failure mode: Theater - looks good but no impact

Critical Insight:

"Teams often confuse Level 2 (execution) for Level 1 (impact). You ship fast but to nowhere. Always validate Level 1 before optimizing Level 2."

How to Apply:

Before building anything:
1. Level 1: What's the outcome? (Impact)
   - Define success metric
   - Know why this matters
   
2. Level 2: How to build it? (Execution)
   - Technical approach
   - Quality bar
   
3. Level 3: How to communicate? (Optics)
   - Stakeholder updates
   - Launch narrative

Most teams skip Level 1 and jump to Level 2.

3. Pre-Mortems for Strategic Decisions (Source: Shreyas Doshi)

Imagine Failure Before Building:

"Six months from now, this failed completely. Why did it fail?"

Use when: Making big architectural decisions or starting major features

How:

Assume Failure: Imagine it's 6 months later, project failed
Work Backwards: List all reasons it could have failed
Address Top Risks: Mitigate the most likely failure modes
Decide: Build with eyes open or don't build at all

Example:

Feature: "Build AI-powered recommendations"

Pre-Mortem (Imagine it failed):
- Model wasn't accurate enough (users ignored recommendations)
- Too slow (users left before results loaded)
- Cold start problem (no data for new users)
- Team underestimated ML expertise needed

Mitigations:
✅ Start with hybrid: AI + rule-based fallback
✅ Set latency budget: <500ms or use cached results
✅ Plan cold start: Popular items + collaborative filtering
✅ Hire ML advisor or partner with ML team

4. Empowered vs Feature Teams (Source: Marty Cagan)

Product Theater Warning:

"Too many companies overhired. Product owners, product ops, agile coaches - dramatically overpaid for value they provide. It's project management, not product management."

Feature Team (Avoid This):

Given features to build
Success = shipped on time
PM is project manager
Result: Feature factory, no ownership

Empowered Team (Aim for This):

Given problems to solve
Success = business outcome
PM discovers solutions
Result: Innovation, ownership

How to Identify:

Feature Team Signs:
❌ "We need to ship X by Q2"
❌ Roadmap is list of features
❌ Success = velocity, not outcomes
❌ PM writes tickets, not strategies

Empowered Team Signs:
✅ "We need to increase retention by 20%"
✅ Roadmap is list of outcomes
✅ Success = metrics moved
✅ PM discovers solutions

Action: If you're in a feature team, shift your framing:

Feature request → User problem
Ship date → Outcome timeline
Velocity → Impact

Decision Tree: Strategic vs Tactical

DECISION: Should I build this?
│
├─ LNO Check ──────────────────────────┐
│  Is this Leverage work? ──YES──────→ PRIORITIZE
│  Is this Overhead? ───YES──────────→ SKIP
│  Is this Neutral? ────YES──────────↓
│
├─ Three Levels Check ─────────────────┤
│  Clear Level 1 (Impact)? ──NO──────→ PAUSE & DEFINE
│  Clear Level 2 (How)? ─────YES─────↓
│
├─ Pre-Mortem ─────────────────────────┤
│  Top failure risks mitigated? NO───→ REDESIGN
│  Confident in approach? ────YES────↓
│
├─ Feature vs Empowered ───────────────┤
│  Solving problem or building feature?
│  Problem-focused ──────────────────→ BUILD
│  Feature-focused ──────────────────→ REFRAME AS PROBLEM
│
└─ BUILD WITH STRATEGY ←──────────────┘

Action Templates

Template 1: LNO Assessment

# Work Item: [Name]

## LNO Classification
- [ ] **Leverage** - Compounds over time, enables future work
- [ ] **Neutral** - Maintains, necessary but doesn't compound
- [ ] **Overhead** - Busy-work, no meaningful impact

## Evidence
- Times this will be used: [number]
- Future work it enables: [list]
- Business impact if skipped: [high/medium/low]

## Decision
- Priority: [High/Medium/Low]
- Rationale: [explain using LNO framework]

Template 2: Three Levels Check

# Feature: [Name]

## Level 1: IMPACT (Why)
- Problem we're solving: [describe]
- Success metric: [specific number]
- Business outcome: [revenue/retention/acquisition/etc.]
- **✓ Clear?** [yes/no - if no, stop and define]

## Level 2: EXECUTION (How)
- Technical approach: [describe]
- Quality bar: [standards]
- Timeline: [estimate]
- **Only proceed if Level 1 is clear**

## Level 3: OPTICS (Communication)
- Stakeholders: [list]
- Update cadence: [frequency]
- Launch story: [how we'll talk about it]

Template 3: Pre-Mortem

# Pre-Mortem: [Feature Name]

**Scenario:** It's 6 months from now. This completely failed.

## Why It Failed (Brainstorm)
1. [failure reason]
2. [failure reason]
3. [failure reason]
4. [failure reason]
5. [failure reason]

## Top 3 Risks
1. **Risk:** [most likely failure]
   **Mitigation:** [how to prevent]

2. **Risk:** [second most likely]
   **Mitigation:** [how to prevent]

3. **Risk:** [third most likely]
   **Mitigation:** [how to prevent]

## Go/No-Go Decision
- [ ] Risks acceptable and mitigated
- [ ] Still believe in the approach
- [ ] **Decision:** [Build / Redesign / Skip]

Quick Reference Card

🎯 Strategic Build Checklist

Before Committing:

Classified as Leverage/Neutral/Overhead (LNO)
If not Leverage, questioning if worth building
Level 1 (Impact) crystal clear
Success metric defined
Pre-mortem completed
Top risks mitigated

During Build:

Avoiding "product theater" - building real value
Focusing on outcomes, not just output
Making decisions with strategy in mind
Building for reuse only when justified (3+ use cases)

Red Flags (Stop & Reassess):

Can't articulate the "why" (Level 1 unclear)
Building because "stakeholder wants it"
No clear success metric
Feels like busy-work

Real-World Examples

Example 1: Stripe's API Design (Shreyas Doshi at Stripe)

Challenge: Should we build this new API endpoint?

LNO Analysis:

Used by 1000+ developers → Leverage
Enables ecosystem growth → High leverage
Alternative: Developers build workarounds → Tech debt

Decision: Build (high Leverage work)

Example 2: Feature Factory Trap (Marty Cagan)

Challenge: Product team shipping fast but metrics flat

Diagnosis: Feature Team, not Empowered Team

Roadmap = list of features
PM = project manager
No ownership of outcomes

Fix:

Shifted to outcome-based roadmap
PM discovers solutions, not just builds features
Measured impact, not velocity

Result: Fewer features, better outcomes

Example 3: Premature Abstraction

Request: "Make this component super reusable"

LNO Assessment:

Currently used: 2 times
Abstraction adds complexity
Not clear if we'll need it again

Decision: Build specific, wait for 3rd use case

First 2 uses: Copy-paste (acceptable tech debt)
3rd use: Refactor into shared component (data-driven)

Common Pitfalls

❌ Mistake 1: Optimizing Execution Without Strategy

Problem: Building fast but in wrong direction Fix: Always validate Level 1 (Impact) before Level 2 (Execution)

❌ Mistake 2: Overhead Disguised as Work

Problem: Updating stakeholders, writing docs, tweaking process Fix: Audit your week - what % was Leverage vs Overhead?

❌ Mistake 3: Building for "Someday"

Problem: "We might need this later" → premature abstraction Fix: YAGNI (You Aren't Gonna Need It) - build when needed

❌ Mistake 4: Feature Team Mentality

Problem: Success = shipped, not impact Fix: Reframe every feature as a problem to solve

Related Skills

zero-to-launch - For scoping MVP strategically
decision-frameworks - For structured decision-making
prioritization-craft - For choosing between options
strategic-pm - For moving from tactical to strategic thinking
ship-decisions - For when to ship vs iterate

Key Quotes

Shreyas Doshi:

"The hardest thing about product management isn't the frameworks - it's distinguishing Leverage work from Overhead disguised as work."

Marty Cagan:

"If you're just delivering output, you're a project manager. Product managers deliver outcomes."

Shreyas on Pre-Mortems:

"Most teams do post-mortems when it's too late. Do pre-mortems when you can still change course."

Further Learning

references/shreyas-doshi-frameworks.md - Deep dive on LNO and Three Levels
references/marty-cagan-empowered.md - Feature teams vs empowered teams
references/strategic-vs-tactical.md - Case studies and examples

strategic-build