Working Backwards: begin with the customer

An idea can become surprisingly concrete before its purpose is clear. It gets a name, a set of features, a place on a roadmap, and eventually an interface. Those decisions create momentum. They can also make the original assumptions harder to question.

That is the product-design question I bring to Colin Bryar and Bill Carr's Working Backwards: how do we give an idea enough structure to examine it before the team becomes committed to building it?

The book describes practices developed inside Amazon, including a method that starts with the intended customer experience and works back toward what needs to be built. The authors explain the approach through the PR/FAQ, a press release and frequently asked questions written before the product exists. The release describes the customer, problem, and benefit; the questions examine the experience and the conditions required to deliver it. The authors' explanation of the PR/FAQ process is a useful introduction.

Make the benefit specific enough to question

For me, the useful discipline is having to explain what becomes better for someone.

Words such as faster, simpler, and smarter are easy to agree with. They leave a lot unresolved. Faster at which task? Simpler for someone learning the product or someone using it every day? What does a smarter system help a person understand or decide?

A clear product promise makes those differences visible. It gives the team something more precise to discuss and gives design a direction to explore through flows, content, and interaction details.

I would start with questions such as:

• Who is experiencing the problem, and in what situation?
• What are they trying to accomplish today?
• What would change in their experience if the idea worked?
• Which assumptions about their needs still require evidence?

These are questions about the experience. Their answers should be recognisable in the eventual interface.

Writing gives the reasoning somewhere to live

The book also describes Amazon's use of written narratives in decision-making. The authors connect the move toward prose with making ideas and their reasoning available for detailed review. Their discussion of narratives expands on that practice.

I see a useful connection to design here. Writing a coherent explanation exposes the links between a problem, a proposed response, and the expected benefit. If a paragraph only works because everyone fills in a different assumption, the idea needs more attention.

A document can also give colleagues from different disciplines a common starting point. Someone can question the user need, someone else can identify a dependency, and another person can explain where the proposed experience becomes difficult to support.

The value depends on whether that feedback is allowed to change the proposal. I would want a review to make uncertainty visible and improve the idea. The document should remain something the team can revise as it learns.

Connect the promise to the interaction

A product designer can help make the gap between a promised benefit and an actual experience visible.

Consider a hypothetical internal tool intended to help someone review an operational exception. A broad promise might be that the tool helps them respond with more confidence. The design still needs to establish what that confidence depends on: understanding what changed, seeing the relevant context, knowing which actions are available, and understanding their consequences.

Those questions lead into information hierarchy, terminology, feedback, and interaction behaviour. They also give a prototype something meaningful to test.

This is where I find the approach most relevant to design craft. A well-considered layout can make the necessary context easier to compare. Clear language can explain an unfamiliar state. An interaction can make the consequence of an action understandable before someone commits to it. The product promise becomes useful when those details support it.

A convincing narrative still needs evidence

My main caution is that clarity on paper can feel like certainty.

A team can write a persuasive account of a problem it has misunderstood. It can also describe an experience that sounds straightforward while leaving important usability questions unresolved. A hypothetical customer response remains an assumption until there is evidence behind it.

I would pair the written proposal with research and prototypes. Interviews can challenge the problem framing. Observing a task can reveal context the team left out. Usability testing can show whether people understand the experience in the way the document assumes.

The writing should change when that evidence changes the understanding. I would also keep the amount of documentation proportionate to the decision. A small, reversible interaction change needs a different level of investigation from a new product direction.

What I want to carry forward

The principle I want to keep is to make the intended customer benefit explicit, then stay willing to revise the idea as the work reveals more.

For design, that means connecting the initial promise to the research, the prototype, and the details of the finished experience. A clear description gives us something to examine. The responsibility is to keep checking whether the product actually makes that description true.

Book: Working Backwards: Insights, Stories, and Secrets from Inside Amazon by Colin Bryar and Bill Carr.