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

#

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: robisson
• Source: robisson/build-like-amazon-agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.