Menu
Stage 2 of Working Backwards: Articulate the customer's problem or opportunity with precision, using data to quantify impact and framing it in the customer's language — not engineering jargon.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Applying Amazon's raise-the-bar principle to every code review. What reviewers look for — clarity, correctness, design, reuse, operational readiness. "Ship It" means the change raises or maintains the quality bar.
Blameless post-incident analysis focused on timeline, 5 Whys, mechanisms over people, and concrete action items with owners.
Internal /build flow mechanism that maintains fixed-size procedural memory of durable implementation-quality lessons.
Review a technical design before specs or implementation. Evaluate problem clarity, requirements, alternatives, trade-offs, architecture, dependency behavior, security, operations, cost, testability, and simplicity.
Bridge between an approved Design Document and code. Decompose the system-level blueprint into N vertical specs (requirements → design → tasks), each independently deliverable. Fail fast by ordering hardest-first. Execute wave-by-wave with approval gates.
Stage 4 of Working Backwards: Write the PR/FAQ — a press release announcing the product as if it already exists, plus a comprehensive FAQ addressing hard questions. This is the core Amazon mechanism that forces clarity, customer-centric thinking, and rigorous pre-mortems before any code is written.
| name | wb-define |
| description | Stage 2 of Working Backwards: Articulate the customer's problem or opportunity with precision, using data to quantify impact and framing it in the customer's language — not engineering jargon. |
| leadership_principles | ["Customer Obsession","Dive Deep","Insist on the Highest Standards","Ownership"] |
Define transforms customer insights into a precise, data-backed problem statement. The goal is to articulate the problem so clearly that anyone — engineer, designer, executive, or new team member — can read it and immediately understand: what's broken, for whom, how badly, and why it matters now.
A good problem statement is the single most valuable artifact in product development. It constrains the solution space (preventing scope creep), aligns the team (preventing debates about what we're solving), and provides evaluation criteria (any proposed solution must address THIS problem for THESE customers).
The canonical template:
"Today, [customers] have to [problem/painful activity] when [situation/trigger], which causes [quantified negative impact]."
At Amazon, the problem statement appears in the PR/FAQ as the "current state" paragraph — the section that describes what life looks like today WITHOUT the proposed solution. This paragraph must make the reader feel the pain. If leadership reads it and shrugs ("so what?"), the PR/FAQ will not be approved.
Common feedback from Amazon leadership on weak problem statements:
The problem statement discipline prevents a failure mode Amazon observed repeatedly in its early days: teams would fall in love with a technical approach and then search for a problem it might solve. The results were technically elegant products that nobody needed.
Pull forward the key findings from Stage 1 (Listen):
Prioritization matrix:
HIGH FREQUENCY
│
┌───────────────┼───────────────┐
│ │ │
│ Important │ Critical │
│ but niche │ (start here) │
│ │ │
LOW ─────┼───────────────┼───────────────┼───── HIGH
SEVERITY │ │ │ SEVERITY
│ Monitor │ Painful but │
│ (not now) │ infrequent │
│ │ │
└───────────────┼───────────────┘
│
LOW FREQUENCY
Write the problem statement using the template. Critical rules:
DO: Describe the current state from the customer's perspective DON'T: Imply a specific solution in the problem framing
| Problem Framing (Good) | Solution Disguised as Problem (Bad) |
|---|---|
| "Engineers spend 3 hours/day context-switching between monitoring tools" | "Engineers need a unified monitoring dashboard" |
| "New hires take 6 weeks to make their first production commit" | "The onboarding system lacks automated environment setup" |
| "Customers abandon checkout when shipping cost is revealed late" | "We need to show shipping costs earlier in the flow" |
The test: if your "problem" contains a verb like "need," "lack," or "should have," you've embedded a solution. Rewrite.
Every problem statement must include measurable impact. Without numbers, problems are opinions.
Impact dimensions to quantify:
Format: "This affects [X customers], happening [frequency], costing [quantified impact], and is [trending direction]."
A problem that has existed for 5 years without action needs a "why now" argument:
Before finalizing, verify your problem statement with 3-5 customers:
PROBLEM DEFINITION
==================
Problem Statement:
"Today, [specific customers] have to [painful activity] when [situation/trigger],
which causes [quantified negative impact]."
Customer Segment: [From Stage 1]
Customers Affected: [Number and %]
Frequency: [How often this occurs]
Impact Per Occurrence: [Time/money/frustration per instance]
Annual Aggregate Impact: [Total cost across all customers]
Trend: [Getting better/worse, at what rate]
Why Now: [What makes this urgent today vs. 6 months ago]
Evidence Base:
- [Data point 1 with source]
- [Data point 2 with source]
- [Data point 3 with source]
- [Customer quote that validates the framing]
What Success Looks Like (Without Specifying a Solution):
"In the future state, [customers] will be able to [desired outcome]
in [timeframe/effort], compared to [current timeframe/effort] today."
Constraints:
- [What the solution must NOT do — e.g., must not require migration]
- [What the solution must preserve — e.g., must maintain security posture]
- [Non-negotiable requirements from customers]
Present your complete Problem Definition to the user. Ask:
Wait for the user to respond with explicit approval or requested changes.
⛔ DO NOT proceed to the Invent stage until the user explicitly approves or says to continue.
PROBLEM DEFINITION
==================
Problem Statement:
"Today, backend engineers at mid-size SaaS companies have to manually
investigate and resolve deployment pipeline failures when automated
tests pass but production deployments fail, which causes an average of
4.2 hours of unplanned work per failure and blocks an average of 3
downstream teams for 6+ hours."
Customer Segment: Backend engineers at SaaS companies (100-1000 employees)
who own deployment pipelines serving 20-100 development teams.
Customers Affected: ~12,000 engineers in the US (27% of segment)
experiencing this monthly
Frequency: 3.4 times per month per engineer (average across segment)
Impact Per Occurrence: 4.2 engineer-hours investigating + 18 blocked
engineer-hours across downstream teams = 22.2 engineer-hours total cost
Annual Aggregate Impact: 12,000 engineers × 3.4 occurrences/month × 12
months × 22.2 hours = ~10.9M engineer-hours/year across the segment
(approximately $1.6B in loaded engineering cost)
Trend: Growing 40% YoY as deployment frequency increases but pipeline
complexity grows faster than tooling maturity
Why Now: The shift to microservices and daily deployments (from monthly)
has increased pipeline complexity 5x in 3 years, but debugging tools
remain designed for monolithic, infrequent deployment patterns. Customer
interviews reveal this crossed the "unacceptable" threshold ~8 months ago.
Evidence Base:
- Product analytics: 73% of deployment failures require >2 hours to
diagnose (Jan-Mar 2026, N=2,847 failure events)
- Customer interviews: 11 of 12 interviewees ranked "deployment debugging"
in their top 3 time sinks
- Support tickets: 340 tickets in Q1 2026 related to "pipeline failure
diagnosis" — up 52% from Q1 2025
- "Every time a deploy breaks, I lose my whole afternoon. And I know 3
teams are sitting there waiting on me." — Platform engineer, Series C
fintech company
What Success Looks Like (Without Specifying a Solution):
"In the future state, platform engineers will be able to identify the
root cause of a deployment failure and remediate it in under 30 minutes,
compared to 4.2 hours today, without requiring tribal knowledge about
pipeline internals."
Constraints:
- Must work with existing CI/CD tools (not rip-and-replace)
- Must not require full access to production environments
- Must maintain SOC2 compliance for audit trails
- Must work without changing the deployment pipeline architecture
| Intention | Mechanism |
|---|---|
| "The problem is obvious to everyone" | Written problem statement required, reviewed by someone outside the team |
| "We'll refine the problem as we build" | Problem statement locked before Stage 3. Changes require re-review |
| "The numbers are roughly right" | Every quantification must cite a source. No unsourced estimates |
| "Customers validated this in passing" | Explicit validation step: read the statement to 3-5 customers verbatim |
| "The problem is too complex for one statement" | If it can't fit the template, you're conflating multiple problems. Split them |
| What They Say | Why It's Wrong | What To Do Instead |
|---|---|---|
| "The problem is self-evident" | Self-evident to you ≠ self-evident to leadership, new team members, or partner teams. And "self-evident" often means "unexamined" | Write it down. If it's truly obvious, writing takes 30 minutes. If writing is hard, the problem wasn't as clear as you thought |
| "We can't quantify this — it's a quality/experience issue" | Every experience problem has measurable proxies: time-on-task, error rate, retry rate, abandonment rate, support contacts | Find the proxy metric. "Frustration" isn't measurable, but "users who rage-click the refresh button 5+ times" is |
| "The problem statement is too narrow — we'll miss opportunities" | A narrow problem is a solvable problem. Broad problems lead to unfocused solutions that half-solve everything and fully-solve nothing | Start narrow. Solve it completely. Expand later if data supports it |
| "We need to keep options open for the solution" | Keeping options open for the solution is fine. Keeping options open for the PROBLEM means you haven't done the work of Listen | A clear problem doesn't constrain solutions — it constrains scope, which is the point |
| "Our execs already defined the problem for us" | Executive framing may reflect a business problem, not a customer problem. "Revenue is declining" is a business observation, not a customer problem statement | Translate the exec framing into customer language. What customer behavior causes the revenue decline? |
Before advancing to Stage 3 (Invent):