Defining the Customer Experience Before Building

How to define the customer experience before building: write the customer's journey through the finished product, then derive what to build.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Defining the customer experience is the step where the promise in a press release becomes a concrete sequence of things a customer does. The Working Backwards method starts, in Colin Bryar and Bill Carr's words, "by defining the customer experience," then works backwards from it until the team is clear about what to build (Amazon's excerpt from Working Backwards). The press release gives the highlights of that experience and the FAQ gives the salient details. This skill takes the next step and writes the experience out in full.

The step has a clear source. In a 2006 post, Amazon CTO Werner Vogels described the Working Backwards product definition process as four documents written in order: the press release, the FAQ, a definition of the customer experience, and the user manual (Vogels, Working Backwards). For the customer experience he wrote: "Describe in precise detail the customer experience for the different things a customer might do with the product." Products with a user interface got mock-ups of each screen the customer uses. Web services got use cases with code snippets showing how people might use the product. The goal, in his words, was "to tell stories of how a customer is solving their problems using the product."

The PR/FAQ instructions that Bryar and Carr publish do not list these documents as separate steps, so treat this skill as the part of the process that turns an approved PR/FAQ into something designers and engineers can build from. It is most useful once the press release is stable enough that the team believes in it, and before anyone estimates or plans the work.

Writing the experience first protects the customer promise during design. When teams start from components or from the system they already have, the experience ends up shaped by what is convenient to build. When they start from the story of the customer using the product, every component has to justify itself by the part of the story it supports. Vogels described the purpose of working backwards as reaching "the minimum set of technology requirements" to satisfy the customer, and a written experience is the input that makes that possible.

The output is a short set of documents: one story per important thing the customer does, with sketches or code examples, and a draft of the user manual. Together they describe the product precisely enough that the requirements can be derived from them, which is the job of Identifying Minimum Lovable Requirements.

How It Works

The customer experience is written from the customer's side of the screen. Each story follows one customer through one task from start to finish: what they want to get done, what they see, what they do, what the product does in response, and how they know they succeeded. Vogels's phrase for this is telling stories of how a customer solves their problem with the product (Vogels). A story that cannot be written without saying "and then the system handles it" has found a gap in the design.

The format depends on the product. For a product with a user interface, the stories are paired with rough mock-ups of each screen, enough to show what is on the screen and what the customer can do next. For an API or developer product, they are use cases with code snippets that show what a developer would write. For a service with human steps, such as onboarding or support, the stories describe who the customer talks to and what happens at each handoff.

The stories come from the PR/FAQ. The press release names the customer and the main benefit, and its getting-started paragraph describes the first experience. The external FAQ lists what customers will ask, and each question often implies a task: changing a plan, getting help, exporting data. The template Bryar and Carr publish asks the getting-started section to describe how easy it is to start (PR/FAQ instructions), so the first story to write is almost always the first use.

Vogels's last document, the user manual, tests the experience from the other direction. He described it as having three sections, concepts, how-to and reference, and noted that products with more than one kind of user get more than one manual (Vogels). Drafting the concepts section shows whether the product needs new ideas the customer must learn. Every concept a customer has to learn is a cost, so a long concepts section is a sign the experience is too complicated.

Once the stories exist, each step in each story implies capabilities: data the product must hold, actions it must perform, integrations it must call, and service that people must provide. Listing them next to the step that needs them gives a traceable set of requirements. Anything the team wants to build that does not appear in any story is either a missing story or something the customer does not need.

Vogels described the result as a set of documents that could explain the new product to other teams and a team that shares one vision of what it is building. That shared picture is the main benefit of this skill.

Step-by-Step Guide

Step 1: Pull the customer and promise from the PR/FAQ

Copy the customer description, the headline benefit and the getting-started paragraph from the press release into a working document. List the external FAQ questions that imply a task the customer performs. If the press release names more than one kind of customer, plan a separate set of stories for each. If you cannot find a clear customer or benefit, go back to the press release first.

Step 2: List the tasks the customer performs

Write the tasks the customer will do with the product, starting with the first use and the task that delivers the headline benefit. Add the tasks implied by the FAQ, such as getting help, changing settings or leaving. Rank them by how often they happen and how much they matter to the promise. The first few tasks on the list get full stories; the rest can be brief.

Step 3: Write each story from start to finish

For each important task, write what the customer wants, what they see, what they do and what happens, in order, until they reach the outcome. Write in plain language from the customer's side. Mark every point where the customer might get stuck, wait or make a mistake, and say what the product does then. A story is finished when someone outside the team can follow it without asking questions.

Step 4: Sketch the screens or write the code examples

Pair each story with the artifact that fits the product: rough mock-ups for a user interface, code snippets for an API, a sequence of handoffs for a service. Keep the sketches low fidelity, because their purpose is to show what the customer sees and does. Check the sketches against the story and fix whichever one is wrong.

Step 5: Draft the user manual

Write a short draft of the concepts, how-to and reference sections, using the stories as the how-to. Count the concepts a customer must learn and ask whether each one is necessary. If the reference section grows long, look for settings and options the customer does not need. Write a separate manual for each kind of user.

Step 6: Derive the capabilities from each step

Go through each story step by step and list what the product must do or hold for that step to work, including data, actions, integrations, service and operations. Put each capability next to the step that needs it. Note capabilities that several stories share. Flag anything the team had planned that no story needs.

Step 7: Check the experience with customers and builders

Walk a few target customers through the stories and mock-ups and ask where they would get stuck and what they expected instead. Walk the engineers and operations staff through the capability list and ask what is missing or much harder than it looks. Update the stories and, if the experience changes the promise, the press release. Hand the stable stories and capability list to requirements scoping.

Best Practices

• Start with the first use. It is where a customer first judges the product, and writing it usually exposes the most gaps.
• Write stories about specific people in specific situations. A named customer with a concrete task produces more precise steps than a generic user.
• Keep sketches rough. Polished mock-ups invite comments on colors and spacing instead of whether the steps make sense.
• Write the unhappy paths. What happens when the customer makes a mistake, loses a connection or needs help is part of the experience, and it can drive much of the work.
• Keep the stories and the press release in agreement. If writing the experience shows the promise cannot be delivered as written, change the press release instead of quietly weakening the stories.
• Treat the concept count as a design signal. Each new concept a customer must learn is friction to justify.

Common Mistakes

• Describing features instead of tasks: A list of screens or features is not an experience. Write what a customer is trying to do and follow them through it.
• Starting from the existing system: Stories written around the current architecture inherit its limits. Write the story the customer would want, then find out what it costs.
• Skipping the unhappy paths: Experiences written only for the ideal case look simple and ship incomplete. Add what happens when things go wrong.
• Stopping at the stories: Stories that are never turned into a capability list do not change what gets built. Finish the decomposition and share it with the builders.
• Writing one experience for several kinds of user: A buyer, an administrator and an everyday user do different things. Give each their own stories and, if needed, their own manual.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Working Backwards

Related Skills

• Writing an Internal Press Release for a Product Idea
• Identifying Minimum Lovable Requirements
• Drafting the FAQ Section of a PR/FAQ
• Iterating PR/FAQ Documents Through Feedback
• Running PR/FAQ Review Meetings
• Using Working Backwards in PM Interviews

Sources

• Werner Vogels: Working Backwards
• About Amazon: excerpt from Working Backwards
• Working Backwards LLC: PR/FAQ Instructions and Template

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.