Menu
Stage 1 of Working Backwards: Identify who the customer is and gather deep insights about their current experience, pain points, and unmet needs through systematic observation and data collection.
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-listen |
| description | Stage 1 of Working Backwards: Identify who the customer is and gather deep insights about their current experience, pain points, and unmet needs through systematic observation and data collection. |
| leadership_principles | ["Customer Obsession","Dive Deep","Learn and Be Curious","Earn Trust"] |
Listen is the foundation of Working Backwards. Before you can solve a problem, you must deeply understand who experiences it and how it affects them. This stage produces a Customer Insight Summary that documents: who the customer is (specific segment), what their current experience looks like, what data supports your understanding, and what gaps remain in your knowledge.
The output of this stage is not a persona document or a market analysis slide. It is a written narrative (1-2 pages) that makes any reader feel the customer's pain or see their opportunity. If the reader doesn't feel a sense of urgency after reading it, you haven't listened deeply enough.
Amazon's Leadership Principle #1 is Customer Obsession: "Leaders start with the customer and work backwards." This is not aspirational — it is operational. Teams are expected to cite specific customer data (support contacts, usage patterns, interview quotes, behavioral analytics) in their PR/FAQ documents. "We believe customers want X" is not acceptable without evidence.
At Amazon, customer listening takes many forms:
The discipline is: never assume you know what the customer wants. Always verify with data. The most dangerous product decisions come from teams that are "too close" to their product and project their own preferences onto customers.
Identify your target customer with enough specificity that you could find them and talk to them.
Bad segments:
Good segments:
Template: [Role/Title] at [Organization Type] who [Observable Behavior] and [Measurable Characteristic]
Collect data that characterizes the segment's size, behavior, and trends:
Sources to mine:
Numbers tell you what; conversations tell you why.
Customer Interviews (minimum 5, ideally 10-15):
Key Interview Questions:
Observation:
Group findings into 3-5 themes that represent patterns across multiple data points:
Produce a 1-2 page narrative document:
CUSTOMER INSIGHT SUMMARY
========================
Customer Segment: [Specific definition from Step 1]
Segment Size: [Number of customers, with growth rate]
Date of Research: [When data was collected]
Data Sources: [List sources: N interviews, M support tickets, analytics from X tool]
CURRENT EXPERIENCE
[Narrative description of what the customer's life looks like today.
Written in present tense. Concrete, specific, vivid.]
KEY INSIGHTS
1. [Theme 1]: [2-3 sentence description with data point]
Customer quote: "[Verbatim]"
2. [Theme 2]: [2-3 sentence description with data point]
Customer quote: "[Verbatim]"
3. [Theme 3]: [2-3 sentence description with data point]
Customer quote: "[Verbatim]"
WHAT WE DON'T YET KNOW
[List of open questions that require further investigation]
IMPLICATIONS
[What this means for the opportunity. What should we explore solving?]
Present your complete Customer Insight Summary to the user. Ask:
Wait for the user to respond with explicit approval or requested changes.
⛔ DO NOT proceed to the Define stage until the user explicitly approves or says to continue.
CUSTOMER INSIGHT SUMMARY
========================
Customer Segment: Platform engineers at mid-size SaaS companies (100-1000
employees) responsible for maintaining internal developer platforms that serve
20-100 development teams.
Segment Size: ~45,000 professionals in the US (growing 28% YoY per
LinkedIn data + Gartner 2025 Platform Engineering report)
Date of Research: March 2026
Data Sources: 12 customer interviews, 847 support tickets (Q1 2026),
product analytics (Jan-Mar 2026), 3 community forum analyses
CURRENT EXPERIENCE
Platform engineers at mid-size companies spend 60-70% of their time on
maintenance tasks: updating dependencies, rotating credentials, responding
to pager alerts for infrastructure issues, and debugging deployment
failures that block development teams. They are hired to build golden paths
that accelerate developers, but they spend most of their time firefighting.
Their internal customers (developers) are frustrated by slow response times
and inconsistent tooling. Platform engineers are frustrated because they
can see what "good" looks like but can't get there because of interrupt-driven
workloads.
KEY INSIGHTS
1. Maintenance Tax: Platform engineers spend 12-15 hours/week on unplanned
maintenance (credential rotation, dependency updates, incident response).
This leaves <30% of their time for platform improvements.
Customer quote: "I'm a glorified janitor. I was hired to build a platform
and I spend all day cleaning up messes."
2. Tribal Knowledge Bottleneck: When one platform engineer leaves, 2-3
months of context are lost. Runbooks are outdated within weeks of writing.
8 of 12 interviewees cited "lack of documentation" as their top pain point.
Customer quote: "When Sarah left, half our deployment pipeline became a
black box. We're still reverse-engineering her decisions six months later."
3. Developer Satisfaction Drives Priority: Platform teams are measured by
developer satisfaction surveys, but they lack the tools to connect their
work to developer outcomes. They operate on gut feel about what matters most.
Customer quote: "I know developers are unhappy with deploy times but I
don't know if fixing the CI bottleneck or the staging environment would
move the needle more."
WHAT WE DON'T YET KNOW
- Exact budget authority (who approves tooling purchases?)
- How they evaluate build-vs-buy for platform components
- Whether they would trust automated maintenance over manual control
IMPLICATIONS
There is an opportunity to reduce the maintenance tax dramatically, freeing
platform engineers to do the work they were hired to do. The solution must
build trust gradually (they won't hand over full control on day one) and
show clear connection between platform work and developer outcomes.
| Intention | Mechanism |
|---|---|
| "We'll talk to customers soon" | Stage gate: no advancement to Define without a completed Customer Insight Summary |
| "We already know our customers" | Required: minimum 5 new data points (interviews, recent tickets, fresh analytics) collected within 60 days |
| "One customer told us this" | Minimum 3 corroborating data points for each insight theme (no single-source insights) |
| "The data speaks for itself" | Every quantitative finding must be paired with qualitative context explaining WHY |
| "We'll validate later" | Customer Insight Summary is reviewed by a peer outside the team before advancing |
| What They Say | Why It's Wrong | What To Do Instead |
|---|---|---|
| "We don't have time for customer research" | Building without research is the most expensive form of waste — you'll build the wrong thing and rebuild later | Time-box to 2 weeks. 5 interviews + analytics review. Imperfect data > no data |
| "Our PM already knows the customer" | Individual knowledge is not team knowledge. Undocumented insights die when people move | Write it down. If the PM knows it, it should take 2 hours to document, not 2 weeks |
| "Customers don't know what they want" | Customers can't design solutions, but they are experts on their own problems and behaviors | Ask about problems and current behavior, never about hypothetical solutions |
| "We have telemetry data, that's enough" | Telemetry shows WHAT happens but never WHY. You need both behavioral data and motivational context | Combine quant (what) with qual (why). Neither alone is sufficient |
| "Our competitor already validated this market" | Competitor's customers ≠ your customers. Their problem framing ≠ your customers' problem framing | Do your own research. Competitor validation reduces market risk but doesn't eliminate customer risk |
Before advancing to Stage 2 (Define):