# Wb Invent > Stage 3 of Working Backwards: Generate multiple solution approaches, classify decisions as one-way vs two-way doors, evaluate alternatives against customer benefit and feasibility, and select the recommended solution with clear rationale. - Skill: `robisson/wb-invent` (Agent Skill) - Install (CLI): `npx skillmds@latest add robisson/wb-invent` - Raw SKILL.md: https://api.skillmd.com/api/skills/robisson/wb-invent/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: robisson (https://skillmd.com/u/robisson) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/robisson/wb-invent --- # WB-Invent: What Is the Solution? Why This One Over Alternatives? ## Overview 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. ## When to Use - After completing Stage 2 (Define) with a validated problem statement - When the team has jumped to a solution without considering alternatives - When there's internal disagreement about the right approach - When evaluating build vs. buy vs. partner decisions - When a proposed solution feels over-engineered or under-ambitious ## Amazon Context 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. ## The Process ### Step 1: Diverge — Generate Solution Approaches Produce at least 3 meaningfully different approaches. Use these prompts: **Approach generation techniques:** 1. **The obvious solution:** What would a senior engineer suggest in 5 minutes? 2. **The radical simplification:** What if we could only build 1/10th of what we initially imagined? 3. **The "what if money/time were no object" solution:** Dream big, then work backwards to feasibility 4. **The platform play:** What if we solved this once for many teams/customers? 5. **The buy/partner option:** Who else already solves this? Can we leverage existing solutions? 6. **The "do nothing" option:** What happens if we consciously choose not to solve this? (Baseline) **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] ``` ### Step 2: Classify Decisions as One-Way vs Two-Way Doors 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:** - Public API contracts (once external developers depend on them) - Data model choices (migration cost grows with data volume) - Pricing structures (customers budget based on published pricing) - Brand/positioning (market perception is slow to change) - Team structure decisions (reorgs are expensive and disruptive) **Common two-way doors (treated erroneously as one-way):** - UI/UX changes (A/B testable, revertible) - Internal tooling choices (swap later if wrong) - Feature scope for v1 (launch small, expand based on data) - Marketing messaging (test different framings cheaply) - Internal process changes (try for 2 weeks, revert if worse) ### Step 3: Evaluate Approaches 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):** - 5: Exceptional — best possible outcome on this dimension - 4: Strong — clearly above the bar, minor gaps - 3: Adequate — meets the minimum, no more - 2: Weak — significant gaps that require mitigation - 1: Unacceptable — disqualifying on this dimension alone **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 | ``` ### Step 4: Stress-Test the Leading Approach For the top-scoring approach, conduct a pre-mortem: 1. **Assume it failed.** Write 5 reasons why. 2. **Identify the riskiest assumption.** What single thing, if wrong, kills this approach? 3. **Define the kill criteria.** What evidence would make you abandon this approach? 4. **Plan the de-risking experiment.** What's the smallest thing you can do to validate the riskiest assumption? 5. **Identify the "plan B" trigger.** At what point do you switch to the second-ranked approach? ### Step 5: Write the Solution Recommendation ``` 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] ``` ### Final Step: Present and Wait for Approval Present your complete Solution Recommendation (including the alternatives analysis) to the user. Ask: - "Here's what I have for the Invent stage. Do these alternatives make sense? Are you happy with the recommended solution?" - "Anything you'd like to adjust before we move to Refine (PR/FAQ writing)?" Wait for the user to respond with explicit approval or requested changes. - If they request changes → revise the Solution Recommendation → re-present → ask again. - If they approve → proceed to Stage 4 (Refine). ⛔ DO NOT proceed to the Refine stage (PR/FAQ) until the user explicitly approves or says to continue. ## Example Output ``` 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 ``` ## Mechanisms Over Good Intentions | 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 | ## Common Rationalizations | 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 | ## Red Flags - Only one solution was seriously considered (the rest are strawmen) - No explicit classification of one-way vs two-way doors - The "riskiest assumption" is something easily verified — suggests the real risk is being avoided - Evaluation criteria are customized to make the preferred solution win - No kill criteria defined ("we'll make it work no matter what") - The do-nothing option wasn't considered (sometimes the right answer is "not now") - Solution is described in technology terms but not customer experience terms - Effort estimate has no range (single-point estimates are always wrong) - No de-risking experiment planned for the highest-risk assumption - The team can't articulate why Alternative B was rejected in one sentence ## Verification Before advancing to Stage 4 (Refine / PR/FAQ): - [ ] Minimum 3 genuinely viable approaches documented - [ ] Each approach has: summary, mechanism, customer experience, assumptions, risks, effort - [ ] Evaluation table completed with scores and weights - [ ] All major decisions classified as one-way or two-way doors - [ ] One-way doors have explicit analysis and senior review planned - [ ] Two-way doors identified for fast execution (don't over-analyze) - [ ] Pre-mortem completed for the leading approach (5 failure reasons) - [ ] Riskiest assumption identified with de-risking experiment designed - [ ] Kill criteria defined in writing - [ ] Solution described in customer experience terms (not just technical terms) - [ ] "Do nothing" option explicitly considered and rejected with reasoning ## Tenets 1. **Alternatives are mandatory, not optional.** You cannot claim you've chosen the best approach without evaluating others. Minimum three. No strawmen. No pre-determined winners. 2. **Classify the door before walking through it.** One-way doors get full analysis. Two-way doors get speed. Confusing the two wastes time (over-analyzing reversible choices) or creates catastrophes (rushing irreversible ones). 3. **Name the riskiest assumption out loud.** Every approach has a "if this isn't true, nothing works" assumption. Identify it. Test it. Plan for what happens if it's wrong. 4. **Simplicity is a feature, not a compromise.** The best solutions are the simplest ones that fully address the problem. Complexity should be added only when simplicity provably fails. 5. **Commit fully once decided.** After rigorous evaluation, the chosen approach gets 100% of the team's energy. Second-guessing during execution is more expensive than making the "wrong" choice with full commitment.