How top companies build products.

Key terms

Working Backwards

Amazon’s process for new products: start from the customer experience and work back to what to build, using a written press release and FAQ.

PR/FAQ

A document written before building: a press release announcing the finished product (under one page) and frequently asked questions (five pages or fewer).

Critical user journey

A sequence of tasks that is a core part of a user’s experience, like searching for a product or completing a purchase.

HEART

A framework of user-centered metrics from Google researchers: Happiness, Engagement, Adoption, Retention, and Task success.

Gradual rollout

Releasing a change to a small share of users first, measuring, and then widening it.

A/B test

A controlled experiment: users are randomly split into groups that see the current version (A) or a changed version (B) over the same period, and a metric chosen in advance is compared.

Guardrail metric

A metric you watch during an experiment to make sure the change isn’t causing harm somewhere else.

The idea

Big companies get copied a lot. Some of what you’ll read about how they work is accurate, some is out of date, and some was never true. So this lesson sticks to what each company, or people who worked there, actually published, and links to it.

You don’t need to work at Amazon, Google, or Spotify to use any of it. Each practice answers a different question. Should we build this at all? Which parts of the experience matter most, and how would we know they’re working? Does it hold up out in the world? You’ll learn each one with the made-up furniture store, and when to reach for it.

The lesson, in eight parts

1. 1Amazon: Working Backwards.

   In 2006, Amazon’s CTO Werner Vogels described a process called Working Backwards, in which “you start with your customer and work your way backwards until you get to the minimum set of technology requirements to satisfy what you try to achieve.” The goal, he wrote, is simplicity through a continuous, explicit focus on the customer.

   Colin Bryar and Bill Carr, two former Amazon executives, later used it as the title of their 2021 book. They write that most of Amazon’s major products and initiatives since 2004 were created this way, and that its main tool is a written narrative called the PR/FAQ: a press release and frequently asked questions, written before anything is built.

   Vogels listed the documents in the order a team writes them:

   Document	What it does
   1. Press release	Says simply what the product does and why it exists, the way the world will see it at launch
   2. FAQ	Answers the questions that came up while writing the press release, and the ones others ask
   3. Customer experience	Describes in detail what customers do with it: mock-ups of each screen, or use cases
   4. User manual	What a customer reads to understand and use it: concepts, how-to, and reference

   From Werner Vogels, “Working Backwards”, All Things Distributed, November 2006.

   Notice the order. Each document is a little closer to the build than the one before. You don’t start from what you could make. You start from what a customer would want to read about.

2. 2Write a PR/FAQ.

   Bryar and Carr give it a clear shape. The press release is a few paragraphs, always under one page. The FAQ is five pages or fewer. Their template for the press release has six parts:

   • Heading: the product’s name, in words the customer understands.
   • Subheading: who the customer is, and what they gain. One sentence.
   • Summary paragraph: the city, the outlet (where the news would run), a realistic launch date, and a summary of the product and its benefits.
   • Problem paragraph: the problem, from the customer’s point of view.
   • Solution paragraph: how the product solves it, simply.
   • Quotes and getting started: one quote from the company, one from a hypothetical customer, and how to get started.

   The template

   [Product name]: [who it’s for and what they gain, in one sentence]. [City], [launch date]: Today [company] launched [product], which [what it does and its main benefit]. Until now, [customers] [the problem, in their words]. [Product] [how it solves the problem, simply]. “[Why we built it]”, said [company spokesperson]. “[The benefit, in a customer’s words]”, said [customer]. To get started, [how].

   Filled in, for the made-up furniture store

   Fit Check: know a sofa will fit before you buy it. Shoppers can now check any sofa against their own doorways, stairs, and room. Chicago, March 3: Today the store launched Fit Check, which tells shoppers in under a minute whether a sofa will get through their door and fit their room. Until now, shoppers had to leave the site, find a tape measure, and guess, and some only found out on delivery day. With Fit Check, you enter a few measurements on the product page and get a clear yes, a no, or “yes, if you take the legs off”. “Nobody should have to send a sofa back because of a doorway”, said the head of product. “Fit Check told me which sofas would make it up my stairs”, said a customer furnishing a first apartment. To get started, open any sofa page and tap Check the fit. (A made-up press release: every name, date, and quote is invented.)

   Then the FAQ, in two parts. External FAQs answer what customers and the press would ask: how does it work, what does it cost, what if it’s wrong? Internal FAQs answer what leaders and every department would ask, and name the hard problems, whether technical, financial, legal, or operational. In review, everyone reads the document silently first; Bryar and Carr note the most senior people tend to speak last. A common question from executives is “so what?” If the product isn’t meaningfully better (faster, easier, cheaper) than what’s already out there, or a real step change for customers, it isn’t worth building. And most PR/FAQs, they write, never become products. That’s not a flaw. It’s a cheap way to find out.

3. 3Google: four principles, starting with the user.

   In 2024, two Google Cloud product people, Deepti Kamat and Tom Abraham, wrote down the four principles behind how Google approaches product management:

   • Focus on the user: understand people’s needs, goals, and pain points. Their advice: “prioritize landings over launches”. Shipping isn’t the finish line; what counts is whether it works for people afterwards, because good products are never finished.
   • Be data-driven: “Without data, decisions will be made based on opinion and personal bias.” But numbers alone aren’t enough, and they warn about bias in data.
   • Iterate quickly: launch, learn from real users, improve. That takes ruthless prioritization: “If everything is a P0 (high priority item), nothing is P0.” Moving fast still goes through legal, ethics, accessibility, and technical reviews.
   • Collaborate effectively: UX, engineering, business, and other teams work toward a common roadmap, with blameless postmortems (reviews of what went wrong that look for causes, not people to blame) when things go wrong, and enough autonomy for each team to decide and move.

   The first principle echoes Google’s published philosophy, “Ten things we know to be true”, which starts with “Focus on the user and all else will follow.” A principle isn’t a process, though. The next part shows one way a Google PM turned these ideas into a working framework.

4. 4Google: a Product Excellence framework.

   Interview prep material often mentions “Google’s Product Excellence Framework”. Here’s where it comes from. In 2018, Product School reported a talk by Sara Zare, a product and program manager at Google who championed Product Excellence there. Her aim was a common reference for PMs, user researchers, and engineers, who otherwise use different language. She described seven parts:

   • Know your users: watch for bias, and the curse of knowledge. Analyze existing data, observe people using the product, and ask them.
   • Critical user journeys: map the path a person takes to reach a goal, given who they are and what they want.
   • Prioritization: put yourself in your users’ shoes, and ask whether you’ve thought of everyone. Not everyone can use a product that relies only on visual cues, so accessibility belongs here.
   • Pitfalls: prepare for the usual ones, such as navigation, feedback, consistency, language, performance, and error states.
   • Principles: a shared shorthand for excellence. Hers are focused utility, simple design, and crafted execution.
   • Measurement: design measures that fit your goals. For consumer products, HEART; for business products, she suggested SUPER (serviceability and system health, user sentiment, productivity, engagement, revenue).
   • Bring it together: launch and iterate. As Product School summed up her point, a minimum product that delights users can keep improving as you iterate.

   The ideas travel well. Take critical user journeys: Google’s Site Reliability Engineering (SRE) workbook, written for the engineers who keep its services running, defines one as “a sequence of tasks that is a core part of a given user’s experience and an essential aspect of the service.” For the made-up furniture store, a short list might look like this:

   Critical user journey	What “finished” looks like	Where it can fail
   Find a sofa that fits my room	The shopper saves or adds a sofa that fits	Filters ignore room size; no way to check fit
   Buy a sofa	The order is placed and confirmed	Payment errors; surprise delivery fees
   Get it delivered	The sofa arrives in the room, on the promised day	Missed window; it won’t fit through the door
   Return or exchange	A return is booked in a few minutes	Hard to find; unclear costs

   A made-up example. Pick the three or four journeys that matter most, and walk each one end to end, the way a customer would.

   One honest note. This is Product Excellence at Google as one Google PM presented it, reported secondhand by Product School, not an official Google publication.

5. 5Google: measure the experience with HEART.

   You met HEART in lesson 4. Here’s where it fits among Google’s practices. It comes from Google researchers Kerry Rodden, Hilary Hutchinson, and Xin Fu, in a paper presented at CHI 2010, a conference on human-computer interaction. It names five categories of user-centered metrics. They’re categories to choose from, not a checklist: the authors say it isn’t always appropriate to use every one.

   Category	What it covers	Made-up furniture store example
   Happiness	Attitudes: satisfaction, perceived ease of use, likelihood to recommend	Survey after purchase: “How easy was it to choose a sofa?”
   Engagement	How much people use it: frequency, intensity, or depth, usually per user	Room-planner sessions per active user each month
   Adoption	New users who start using it in a period	Shoppers using Fit Check for the first time this week
   Retention	Users from one period still using it later	Room-planner users who come back within 90 days
   Task success	Efficiency, effectiveness, and error rate	Share of Fit Check attempts that end with a clear answer

   Categories from Rodden, Hutchinson, and Fu, “Measuring the User Experience on a Large Scale” (CHI 2010). The examples are made up.

   The same paper pairs HEART with a simple process: Goals, Signals, Metrics. Write the goal first. Then the user behavior or attitude that would signal success. Then the metric you’ll track. Lesson 4 covers choosing metrics in depth.

6. 6Spotify: Think It, Build It, Ship It, Tweak It.

   In 2013, agile coach Henrik Kniberg, who was working with Spotify at the time, wrote “How Spotify builds products”, based on conversations with people there and on Spotify’s internal “Think It, Build It, Ship It, Tweak It” framework. He’s careful to call it a simplification of reality, with a lot of local variation. Its core philosophy: prototype early and cheaply; “we don’t launch on date, we launch on quality”; and keep improving after launch.

   Stage	What happens	It ends when
   Think It	A small team (typically a developer, a designer, and a product owner) writes a short product definition, including the narrative, and builds prototypes	Management and the team agree it’s worth building, or agree to drop it
   Build It	The team builds a minimum viable product (MVP) good enough for real users; Kniberg suggests “Minimum Loveable Product” as a better name	It fulfills the basic narrative and is good enough to release
   Ship It	Roll out gradually, typically to 1 to 5% of users first, and test the hypotheses	It’s available to all users
   Tweak It	Keep experimenting, A/B testing, and improving	It’s shut down, or reimagined (back to Think It)

   From Henrik Kniberg, “How Spotify builds products” (January 2013).

   Two details are worth borrowing. First, Think It starts with a narrative. “What will the press release look like?” Kniberg asks, and the narrative is written before the product is built. Sound familiar? Second, the first version must be “narrative-complete, not feature-complete.” His example: release only a wheel, see nobody use it, and you might wrongly decide nobody wants the bike.

7. 7Spotify: test ideas with controlled experiments.

   Spotify’s engineering blog explains how it tests ideas: teams write hypotheses and test them by running experiments, normally A/B tests (lesson 8 shows how to run one), to learn what works and what doesn’t. A 2023 post puts the reason plainly: “if you’re not running controlled experiments, then you’re not confronting your ideas with reality.”

   Its experimentation platform asks teams to set two kinds of metrics: success metrics, to find evidence for the hypothesis, and guardrail metrics, to find evidence that the experiment isn’t introducing harmful side effects. Here’s what that could look like for Fit Check at the made-up store:

   • Hypothesis: if shoppers can check fit on the product page, fewer sofas will come back because they didn’t fit.
   • Who: a random 5% of sofa-page visitors see Fit Check; everyone else sees the page as it is today.
   • Success metric: the share of sofa orders returned for fit, within 60 days.
   • Guardrail metrics: product-page load time, and the share of shoppers who add a sofa to their cart. A fit check that scares people off isn’t a win.
   • Decision rule, written before you start: which results mean roll out, keep testing, or stop. For example: once 60 days have passed for the test’s orders, roll out if fit returns fell and add-to-cart held steady; stop if add-to-cart dropped; otherwise run a second round. (Made up.)

   Writing the decision rule first matters more than it looks. Without it, it’s tempting to find a reason to ship whatever you already liked.

8. 8What to borrow, and when.

   None of these is a whole way of working to copy. Each one answers one question, at one moment in the work:

   When you’re asking	Borrow	From
   Should we build this at all?	Write the press release and FAQ first	Amazon’s Working Backwards
   Are we chasing too many things at once?	Ruthless prioritization: if everything is a P0, nothing is	Google’s four principles (Kamat and Abraham, 2024)
   Which parts of the experience matter most?	List the critical user journeys, and walk them	Google’s SRE workbook
   How will we know it helps users?	Choose from HEART, then goals, signals, metrics	Google researchers (Rodden, Hutchinson, Fu)
   Is it ready for real users?	A narrative-complete first version, rolled out gradually	Spotify, as Kniberg described it
   Did this change actually help?	A controlled experiment with success and guardrail metrics	Spotify’s engineering blog

   One caution. These describe how big companies, with lots of traffic and people, work. A small store may not get enough visitors for a quick A/B test, or have time to polish a PR/FAQ through many rounds. Keep the idea. Size the practice to your team: a one-page press release and a short FAQ, a slower rollout you watch closely, or a few customer conversations before you build.

With AI: AI can draft a press release in seconds, and that’s the risk. The value of a PR/FAQ is the thinking it forces: who exactly the customer is, what their problem is, and what’s hard to build. A fluent draft can skip all of that and still read well. Use AI to list FAQs you missed, to play a skeptical executive asking “so what?”, or to check an experiment plan for missing guardrails. Then do the hard part yourself, and check every claim about how a company works against what that company actually published.

PRESS RELEASE (under one page)
  Heading: [product name customers understand]
  Subheading: [who it's for, and what they gain, in one sentence]
  Summary: [city], [realistic launch date]. [What it is, and its main benefit.]
  Problem: [the problem, from the customer's point of view]
  Solution: [how it solves the problem, simply]
  Company quote: [why we built it]
  Customer quote: [the benefit, in a customer's words]
  Getting started: [how]

EXTERNAL FAQ (customers and press)
  How does it work?
  What does it cost?
  What if it's wrong, late, or breaks?

INTERNAL FAQ (leaders and every department)
  Why now, and why us?
  What's hardest to build? (technical, legal, operational)
  What will it cost, and how will we know it worked?
  What are we choosing not to do?

THE "SO WHAT?" TEST
  Is it meaningfully better (faster, easier, cheaper), or a step change, compared with what customers use today?

IF WE BUILD IT
  Critical user journey it serves:
  HEART categories that matter (pick 1 to 3):
  Rollout: who first, and how many:
  Success metric:
  Guardrail metric:
  Decision rule (write it before launch):

Ask AI about this lesson

All lessons