From build-like-amazon
Stage 3 of Working Backwards: generates solution alternatives, classifies decisions as one-way vs two-way doors, evaluates against customer benefit and feasibility, and selects a recommended approach.
How this skill is triggered — by the user, by Claude, or both
Slash command
/build-like-amazon:wb-inventThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Invent is where creative problem-solving happens — but within disciplined constraints. The input is a validated problem statement (from Stage 2). The output is a recommended solution with a clear explanation of why this approach was chosen over alternatives.
Invent is where creative problem-solving happens — but within disciplined constraints. The input is a validated problem statement (from Stage 2). The output is a recommended solution with a clear explanation of why this approach was chosen over alternatives.
The key discipline: you must generate and evaluate at least 3 meaningfully different approaches before selecting one. This prevents the team from anchoring on the first idea (which is usually the most obvious, not the best). Each alternative must be genuinely viable — not a strawman created to make the preferred option look good.
Additionally, every major decision is classified as either a one-way door (irreversible, high-consequence) or a two-way door (reversible, lower-consequence). This classification determines how much analysis and approval is required before proceeding.
Amazon's Leadership Principle "Invent and Simplify" is paired with Jeff Bezos's concept of Type 1 vs Type 2 decisions:
Type 1 (One-Way Door): Irreversible or nearly irreversible. Consequences are severe if wrong. Examples: choosing a database architecture that data will be locked into, public pricing commitments, acquiring a company, launching a new brand.
Type 2 (Two-Way Door): Reversible at low cost. If wrong, you can walk it back. Examples: UI changes behind a feature flag, A/B tests, internal tool choices, pricing experiments on a small segment.
The failure mode Amazon guards against: treating every decision like a Type 1 decision (analysis paralysis) or treating every decision like a Type 2 decision (reckless speed). Most decisions are Type 2 and should be made quickly by small groups. Type 1 decisions deserve the full rigor of Working Backwards.
Amazon also emphasizes "disagree and commit" — once a solution is chosen through rigorous evaluation, the team commits fully even if individuals preferred a different option. The time for debate is during Invent, not during execution.
Produce at least 3 meaningfully different approaches. Use these prompts:
Approach generation techniques:
For each approach, document:
APPROACH [N]: [Name]
==================
Summary: [2-3 sentence description]
How it works: [Key technical/operational mechanism]
Customer experience: [What the customer sees/does differently]
Key assumptions: [What must be true for this to work]
Biggest risk: [Single biggest reason this might fail]
Effort estimate: [T-shirt size: S/M/L/XL with rationale]
Time to first value: [How long before customers benefit]
For each major decision within the approaches:
┌─────────────────────────────────────────────────────────┐
│ DOOR CLASSIFICATION FRAMEWORK │
├─────────────────────────────────────────────────────────┤
│ │
│ Can we reverse this decision at low cost? │
│ ├── Yes → TWO-WAY DOOR │
│ │ • Decide quickly (days, not weeks) │
│ │ • Small group can decide (2-3 people) │
│ │ • Optimize for speed of learning │
│ │ • Accept 70% confidence threshold │
│ │ │
│ └── No → ONE-WAY DOOR │
│ • Full analysis required │
│ • Senior leadership review │
│ • 90%+ confidence threshold │
│ • Consider: Can we restructure to make it two-way? │
│ │
│ CONVERSION TECHNIQUES (One-Way → Two-Way): │
│ • Feature flags (ship but don't expose) │
│ • Parallel systems (run both, switch traffic) │
│ • Contracts/APIs (isolate behind interface) │
│ • Time-limited experiments (try before committing) │
│ • Partial rollouts (limit blast radius) │
│ │
└─────────────────────────────────────────────────────────┘
Common one-way doors:
Common two-way doors (treated erroneously as one-way):
Score each approach against these criteria:
| Criterion | Weight | Description |
|---|---|---|
| Customer benefit | 30% | How completely does this solve the problem defined in Stage 2? |
| Time to value | 20% | How quickly can customers start benefiting? |
| Feasibility | 20% | Can we build this with available skills, technology, and resources? |
| Scalability | 15% | Does this approach work at 10x and 100x current scale? |
| Reversibility | 15% | If we're wrong, how easily can we change course? |
Scoring rubric (1-5):
Evaluation table example:
| Criterion (Weight) | Approach A | Approach B | Approach C |
|-------------------------|-----------|-----------|-----------|
| Customer benefit (30%) | 4 | 5 | 3 |
| Time to value (20%) | 5 | 2 | 4 |
| Feasibility (20%) | 4 | 3 | 5 |
| Scalability (15%) | 3 | 5 | 3 |
| Reversibility (15%) | 4 | 4 | 2 |
| WEIGHTED SCORE | 4.05 | 3.85 | 3.45 |
For the top-scoring approach, conduct a pre-mortem:
SOLUTION RECOMMENDATION
=======================
Problem Being Solved: [One-line from Stage 2]
Recommended Approach: [Name]
Summary: [3-5 sentences describing the solution and key mechanism]
Why This Approach:
- [Reason 1 with evidence/score reference]
- [Reason 2 with evidence/score reference]
- [Reason 3 with evidence/score reference]
Why Not the Alternatives:
- [Alternative A]: [Specific reason for rejection, not just "lower score"]
- [Alternative B]: [Specific reason for rejection]
Key Decisions:
| Decision | Classification | Rationale |
|----------|---------------|-----------|
| [Decision 1] | One-way door | [Why irreversible, what analysis was done] |
| [Decision 2] | Two-way door | [Why reversible, what speed is appropriate] |
| [Decision 3] | Two-way door | [Conversion technique if applicable] |
Riskiest Assumption: [Statement]
De-risking Plan: [How we'll validate before full commitment]
Kill Criteria: [What would make us stop and switch approaches]
Effort Estimate: [Range with confidence level]
Time to First Customer Value: [Date or sprint count]
Full Solution Timeline: [Date or sprint count]
Present your complete Solution Recommendation (including the alternatives analysis) to the user. Ask:
Wait for the user to respond with explicit approval or requested changes.
⛔ DO NOT proceed to the Refine stage (PR/FAQ) until the user explicitly approves or says to continue.
SOLUTION RECOMMENDATION
=======================
Problem Being Solved: Platform engineers spend 4.2 hours diagnosing
each deployment failure because root cause information is scattered
across 5+ tools with no unified timeline.
Recommended Approach: "Deployment Telescope"
An observability layer that automatically correlates deployment events
with infrastructure changes, log anomalies, and metric shifts into a
single causal timeline. Runs as a sidecar to existing CI/CD tools
(not replacing them). Uses change-correlation algorithms to rank
probable root causes by likelihood.
Why This Approach:
- Highest customer benefit (5/5): Directly addresses the 4.2-hour
diagnosis time by surfacing probable root cause within 5 minutes
- Strong reversibility (4/5): Runs alongside existing tools as a
read-only observer. Can be removed with zero impact on pipelines
- Incremental value delivery: First useful output (correlated timeline)
delivered in 4 weeks. Full root-cause ranking in 12 weeks
Why Not the Alternatives:
- "Pipeline Overhaul" (replace existing CI/CD with integrated platform):
Scored highest on customer benefit (5) and scalability (5), but
lowest on feasibility (2) and time-to-value (1). Requires 9-month
migration that customers won't tolerate. One-way door with
catastrophic failure mode.
- "Runbook Automation" (auto-generate and execute diagnosis runbooks):
Fast to deliver (4 weeks) but only solves known failure patterns.
Novel failures (which cause the longest diagnosis times) are
unaddressed. Ceiling on customer benefit is 3/5.
Key Decisions:
| Decision | Classification | Rationale |
|----------|---------------|-----------|
| Data correlation algorithm choice | Two-way door | Can swap algorithms behind API; customers see ranked results regardless of implementation |
| Integration approach (agent vs API) | Two-way door | Start with API polling; switch to agent-based push if latency is unacceptable |
| Pricing model (per-deployment vs per-seat) | One-way door | Once published, customers budget against it. Requires pricing experiment with 50 customers before committing |
| Data retention period (7 vs 30 vs 90 days) | Two-way door | Start at 30 days; adjust based on actual usage patterns. Storage cost is linear and reversible |
Riskiest Assumption: That deployment failures can be correlated with
root cause using only observational data (logs, metrics, change events)
without requiring instrumentation changes to the customer's pipeline.
De-risking Plan: Build a prototype correlator against 3 customer
environments (with permission). Manually validate correlation accuracy
against their incident post-mortems. Target: >70% of failures have
correct root cause in top-3 suggestions.
Kill Criteria: If correlation accuracy is <50% after 6 weeks of
iteration, switch to Approach B (Runbook Automation) which has lower
ceiling but higher floor.
Effort Estimate: 3-4 engineers for 12 weeks (high confidence for MVP)
Time to First Customer Value: 4 weeks (correlated timeline, no ranking)
Full Solution Timeline: 12 weeks to GA-quality root cause ranking
| Intention | Mechanism |
|---|---|
| "We'll consider alternatives" | Minimum 3 approaches documented with full evaluation. Reviewer checks that alternatives are genuinely viable, not strawmen |
| "We'll move fast on this" | Two-way door decisions must be classified explicitly. Only true two-way doors get the speed treatment |
| "We'll de-risk as we go" | Riskiest assumption identified upfront with explicit de-risking experiment designed BEFORE committing |
| "If it doesn't work, we'll pivot" | Kill criteria defined in writing before starting. Prevents sunk-cost fallacy from keeping a failing approach alive |
| "The team agrees on the approach" | Evaluation table with scores forces explicit tradeoff discussion. Disagreements surface in the scoring, not after launch |
| What They Say | Why It's Wrong | What To Do Instead |
|---|---|---|
| "We don't need alternatives — the solution is obvious" | The "obvious" solution is usually the most familiar one, not the best one. Familiarity masquerades as correctness | Generate alternatives anyway. If the obvious solution truly is best, the evaluation will confirm it in 2 hours |
| "All our alternatives would take too long" | Time-to-value is ONE criterion, not the only one. A fast solution to the wrong problem is worthless | Score alternatives honestly. If all options are slow, that's a sign the problem needs re-scoping, not that you should skip evaluation |
| "This is a two-way door, we don't need analysis" | Two-way door means faster decisions, not zero analysis. You still need to know WHAT you're deciding and WHY | Classify the door type, then match the analysis level. Two-way doors get 1-2 days of evaluation, not zero |
| "We need to move fast — competitors are ahead" | Panic-driven decisions are the most expensive. If a competitor has a 6-month lead, 2 weeks of analysis won't close or widen that gap | Speed comes from clarity, not from skipping thinking. A clear solution recommendation accelerates execution |
| "We should build the platform play from day one" | Premature generalization is the root of over-engineering. You don't know what the platform needs until you've solved 2-3 specific cases | Solve one specific problem well first. Extract the platform from successful specific solutions |
Before advancing to Stage 4 (Refine / PR/FAQ):
npx claudepluginhub robisson/build-like-amazon-agent-skillsGuides product development using Amazon's Working Backwards methodology, from customer insight through PR/FAQ creation. Starts with 5 Customer Questions for lightweight validation before committing to a full cycle.
Generates multiple solution approaches with trade-offs using structured frameworks (SCAMPER, First Principles) and hands off to planning. Includes Vision Mode for product-level rethinks and Design-It-Twice Mode for interface exploration.
Generates 5 probability-weighted alternative options, including at least one unconventional, with trade-offs to challenge default thinking and expose assumptions in decision points.