Build, launch, and learn.

Key terms

Agile

An approach to building software, set out in the 2001 Agile Manifesto: deliver working software often, work with customers, and respond to change.

Sprint

In Scrum, a fixed period of one month or less in which the team makes a usable Increment: a finished piece of the product that works.

Product Backlog

In Scrum, an ordered list of what’s needed to improve the product. It is the single source of the team’s work.

Work in progress (WIP)

In Kanban, items started but not finished. A WIP limit caps how many there can be.

PRD

Product requirements document: what a product or release should do, for whom, and why, written so the team can build and test it.

A/B test

A controlled experiment: users are randomly assigned to the current version (A) or a changed version (B), and a metric chosen in advance is compared.

Go-to-market plan

The plan for bringing a product to customers: who it’s for, what you’ll say, how they’ll hear, and whether the company is ready.

The idea

The old way was to plan everything, build everything, then release it all at once. If the plan was wrong, you found out at the end, when changing course cost the most. Many teams now work in small steps: build a piece, show people, learn, adjust.

This lesson is the toolkit for working that way. Each tool answers a practical question: what do we build first, how do we know it’s done, and did it help? The made-up furniture store’s doorway-size check runs through all of it.

The lesson, in seven parts

1. 1Design thinking: keep checking it’s the right thing.

   Agreeing on an idea doesn’t end the learning. Build the wrong thing quickly, and it’s still the wrong thing. Design thinking is one well-known way to keep checking. IDEO’s former CEO Tim Brown describes it as “a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”

   Stanford’s d.school teaches it as five modes:

   Mode	What you do	At the made-up furniture store
   Empathize	Observe and talk with people to understand them	Read support chats, then talk with shoppers whose sofa didn’t fit
   Define	Turn what you learned into a clear problem statement	“Shoppers can’t tell if a sofa will fit their door”
   Ideate	Generate many solutions before picking	A measuring guide, a doorway check, a room planner
   Prototype	Make something rough people can react to	A paper sketch of the doorway check (lesson 8)
   Test	Try it with people, and learn what to change	Five shoppers try the sketch

   Modes from the Stanford d.school. Its process guide says the modes are shown in order “for simplicity”, and that teams use them in various orders and repeat them.

   Notice the word “modes”, not “steps”. Testing can send you all the way back to Define.

2. 2Agile: what the manifesto actually says.

   In February 2001, seventeen people who built software met at the Snowbird ski resort in Utah, and wrote the Manifesto for Agile Software Development. It’s short enough to read in a minute. At its heart are four values, each written as a pair:

   They value this more	than this
   Individuals and interactions	processes and tools
   Working software	comprehensive documentation
   Customer collaboration	contract negotiation
   Responding to change	following a plan

   From the Manifesto for Agile Software Development (2001). The next line matters: “while there is value in the items on the right, we value the items on the left more.”

   That last line is the one people forget. Agile doesn’t mean no plan and no documents. Put plainly: when the plan and reality disagree, the manifesto sides with reality. The manifesto also lists twelve principles. These four do the most work for a product manager:

   • “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
   • “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
   • “Working software is the primary measure of progress.”
   • “Simplicity--the art of maximizing the amount of work not done--is essential.”

3. 3Run the work: Scrum Sprints, or a Kanban board.

   Agile is a set of values. Scrum and Kanban are two concrete ways to run the work. The Scrum Guide, by Ken Schwaber and Jeff Sutherland, calls Scrum “a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

   It defines three accountabilities. The Product Owner maximizes the product’s value and manages the Product Backlog (in many companies, that’s the product manager). The Developers (everyone building it, not only engineers) plan and do the work, to a Definition of Done: the team’s shared description of what “finished” means, often kept as a checklist. The Scrum Master helps everyone use Scrum well. The work happens in events:

   Event	What it’s for	Longest it can take, in a one-month Sprint
   Sprint	Holds all the other events; the team creates a usable Increment	One month
   Sprint Planning	Agree why this Sprint is valuable (the Sprint Goal), what can be done, and how	8 hours
   Daily Scrum	Developers check progress toward the Sprint Goal and adjust the plan	15 minutes
   Sprint Review	Inspect the outcome with stakeholders, and decide what to do next	4 hours
   Sprint Retrospective	Plan ways to increase quality and effectiveness	3 hours

   From The Scrum Guide (2020). Shorter Sprints usually have shorter events. Scrum also names three artifacts, the things the team keeps visible: the Product Backlog, the Sprint Backlog (this Sprint’s goal, chosen items, and plan), and the Increment.

   In a two-week Sprint at the made-up furniture store, a good Sprint Goal is “Shoppers can check whether a sofa fits through their door before they buy.” Not “finish tickets 41 to 58” (the team’s work items). It lets the Developers change the how without losing the why.

   Not every team runs in Sprints. The Kanban Guide, by John Coleman and Daniel Vacanti, defines Kanban as “a strategy for optimizing the flow of value through a process.” Kanban doesn’t need Sprints. It often suits work that arrives in a steady stream, like fixes and small requests, where a two-week plan would keep breaking. Sprints suit work you can shape into a goal for the next few weeks. To set up a board:

   • Write down the steps work goes through, like Building, Testing, Done, and put every item on the board.
   • Limit how much work is in progress. A common way: cap how many items each step can hold. When a step is full, finish something before starting more.
   • Track the four flow measures the guide asks for: WIP (how many items are in progress), throughput (how many finish in a period), work item age (how long a started item has been open), and cycle time (how long an item took from start to finish).

4. 4Build a Now, Next, Later roadmap.

   A roadmap shows what the team plans to work on and why, in order. The trouble with a timeline roadmap, one with a date on every feature, is that it promises more than you know. Janna Bastow, a co-founder of ProdPad, created the Now, Next, Later format with her co-founder to get away from that. It began as three columns called “current”, “near term”, and “future”, based on the idea that the further out you look, the less certain things are.

   Here’s how to build one:

   • Start from the goal, and the customer problems that stand in its way.
   • Write each item as a problem, not a feature: “Shoppers worry a sofa won’t fit”, not “Build doorway tool”.
   • Now: work in progress. Detailed, with how you’ll measure success.
   • Next: coming up. You’re still exploring solutions.
   • Later: where you’re heading. Little detail yet, on purpose.
   • Add dates only where there’s a real deadline. In Bastow’s words, “The key thing is not to penalize yourself by giving dates for everything unnecessarily.”
   • Review it often. Items move toward Now as you learn.

5. 5Write it down: a PRD, or a press release first.

   A conversation reaches two people. A document reaches the whole team, and it’s still there next month. In his 2005 paper “How to Write a Good PRD”, Marty Cagan says the PRD’s purpose is to “clearly and unambiguously articulate the product’s purpose, features, functionality, and behavior.” He splits it into four areas:

   Area	What goes in	Doorway check (made-up)
   Product purpose	The problems to solve, not the solution; who it’s for; real scenarios	Shoppers can’t tell if a sofa will fit their door, so some don’t buy and some return it. Success: more sofa-page visitors buy, and fewer sofas come back for not fitting
   Features	What the product should do, described as what the user does and sees (interaction design and use cases), each tied to the need and goal it serves	Shopper enters doorway width and height; the page says it fits, it’s tight, or it won’t fit, and how to measure
   Release criteria	The real minimum for things like performance, reliability, usability, and supportability	Works on phones; answer appears within a second on a phone; support has a help article ready
   Schedule	A target window, and the reason for it, not a random date	Before the spring sofa sale, so sale shoppers get it

   From Marty Cagan, “How to Write a Good PRD”, SVPG, 2005. He also says to rank every requirement, and that “must-have” should mean the product doesn’t ship without it. A year later, in “Revisiting the Product Spec”, he argued that most specs “take too long to write, they are seldom read”, and that a high-fidelity prototype, a realistic version of the experience, makes the best spec.

   The template

   [Name] helps [who] [do what], so they no longer [problem]. Until now, [how it works today, and why that’s painful]. Here’s how it works: [two or three plain sentences]. “[What a customer might say about it]”

   Filled in, for the made-up furniture store

   Doorway Check helps sofa shoppers know a sofa will fit before they buy, so they no longer gamble on delivery day. Until now, shoppers had to measure and hope. Enter your doorway’s width and height on any sofa page, and you’ll see whether it fits. “This saved me a return.” (A made-up quote.)

   There’s another way to start. Colin Bryar and Bill Carr, who worked at Amazon, write that most of its major products since 2004 came out of a process called Working Backwards. Its main tool is the PR/FAQ, written before anything is built: a press release of less than one page, then frequently asked questions of five pages or less (more on it in lesson 10). In their words, “The primary point of the process is to shift from an internal/company perspective to a customer perspective.”

6. 6Test it live: run an A/B test.

   Does the doorway check help? An A/B test answers that with real shoppers. In the simplest version, Ron Kohavi and his co-authors explain, users are randomly assigned to the current version (A) or the new one (B). “The key here is ‘random.’” If the test is designed and run properly, the change is the only thing that’s consistently different between the groups. So when the difference in the metric is statistically significant, chance alone is an unlikely explanation, and you can treat the change as the cause. Here’s how to run one:

   • Write a hypothesis: “If we show the doorway check on sofa pages, more shoppers who view a sofa will buy one, because they no longer have to guess whether it fits.”
   • Choose one main metric before you start, here the share of sofa-page visitors who buy a sofa. Kohavi and his co-authors recommend a single overall measure. Fit returns matter too, but they arrive weeks after delivery, so watch them after the test as a guardrail (lesson 4).
   • Split users at random, and keep each person in the same group on every visit.
   • Decide the sample size before you start, using a sample-size calculator. As Evan Miller explains, significance calculations assume the sample size was fixed in advance.
   • Run whole weeks: Kohavi and his co-authors recommend at least a week or two, because weekday and weekend shoppers can differ.
   • Don’t stop early because B looks like it’s winning; that makes false wins more likely. At the end, check whether the difference is statistically significant, which means unlikely to be chance alone (the calculator tells you), then decide.

   Know what it can’t do. An A/B test tells you which version did better, and by how much. It doesn’t tell you why. Pair it with usability tests, where you hear people’s reasons. And a page with few visitors may need a very long test.

7. 7Launch it: a go-to-market plan you can actually run.

   Building it isn’t the finish line. Customers have to find it and trust it, and the company has to be ready. A good go-to-market plan answers at least these six questions. If your company has product marketing (the people who shape how a product is described and sold), write it with them:

   Question	Doorway check (made-up)
   Who is it for?	Shoppers looking at large items like sofas, especially on phones
   What will we say?	One line in customers’ words: “Know it fits before you buy.”
   How will they find it?	On every sofa page, in the delivery email, in the help center
   Is everyone ready?	Support has the help article; delivery staff know how to help when a sofa is a tight fit
   How will we roll it out?	A small share of shoppers first, then everyone, if nothing breaks
   How will we know it worked?	The main metric from the A/B test, checked again a month after launch, with fit returns as they come in

   The A/B test can be your first small rollout: a small share of shoppers is split between the two versions. If B helps and nothing breaks, widen it to everyone. Then close the loop. Read support chats in the first week, and check the metric again after a month. What you learn becomes the next roadmap item.

With AI: AI tools can help with delivery work. They can draft a PRD from your notes, summarize a week of support chats, or turn a sketch into a first draft of code. When small steps get cheaper, working in small steps gets easier. AI doesn’t decide what goes in Now, or which metric counts as success, and every requirement it drafts still needs checking against what customers need.

PROBLEM IT SOLVES (not the solution):
WHO IT'S FOR:
WORKING NAME FOR THE SOLUTION:

ROADMAP PLACE (Now, Next, or Later), and why:

PRD
  Purpose:
  Features (each linked to an objective):
  Release criteria (performance, reliability, usability, support):
  Target window, and the reason for it:

FIRST SPRINT GOAL (an outcome, not a ticket list):

A/B TEST
  Hypothesis: If we ___, then ___ will change, because ___.
  Main metric (chosen now):
  Sample size (from a calculator):
  Run for (whole weeks):

LAUNCH
  Message in customers' words:
  Where they'll find it:
  Who must be ready (support, sales, operations):
  Rollout (small share first?):
  When we'll check the metric again:

Ask AI about this lesson

All lessons