Distinguishes strategic vs tactical work during development using Shreyas Doshi's frameworks and Marty Cagan's empowered teams principles. Use when making architectural decisions, choosing what to build, preventing "product theater", or applying the LNO framework (Leverage, Neutral, Overhead). Helps avoid feature factory and build work that compounds.
Claude uses this skill when:
Leverage, Neutral, Overhead:
"Not all tasks are created equal. Some tasks compound (Leverage), some maintain (Neutral), and some drain without return (Overhead)."
Prioritizing what to build or evaluating if work is strategic
The Three Categories:
🚀 Leverage Work (10x multipliers)
➡️ Neutral Work (1x necessary)
⚓ Overhead Work (0x drain)
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
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)
Level 2: EXECUTION (How)
Level 3: OPTICS (Perception)
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.
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:
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
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):
Empowered Team (Aim for This):
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:
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 ←──────────────┘
# 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]
# 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]
# 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]
Before Committing:
During Build:
Red Flags (Stop & Reassess):
Challenge: Should we build this new API endpoint?
LNO Analysis:
Decision: Build (high Leverage work)
Challenge: Product team shipping fast but metrics flat
Diagnosis: Feature Team, not Empowered Team
Fix:
Result: Fewer features, better outcomes
Request: "Make this component super reusable"
LNO Assessment:
Decision: Build specific, wait for 3rd use case
Problem: Building fast but in wrong direction Fix: Always validate Level 1 (Impact) before Level 2 (Execution)
Problem: Updating stakeholders, writing docs, tweaking process Fix: Audit your week - what % was Leverage vs Overhead?
Problem: "We might need this later" → premature abstraction Fix: YAGNI (You Aren't Gonna Need It) - build when needed
Problem: Success = shipped, not impact Fix: Reframe every feature as a problem to solve
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."