From Discovery to Delivery: One-Pagers, PRDs and Turning Decisions into Backlog Items

Version note: This post is conceptual; it uses the numbers from the Bookstore cart abandonment work in earlier posts of the series (the funnel in post 07, the experiment in post 08).

Guess First

Two documents reach the Bookstore team in the same week. The first is a Jira ticket: "Show the shipping cost on the product page. Acceptance criteria: the fee appears below the price." Three lines. The second is a fourteen-page PRD (Product Requirements Document) from another team: screenshots, pixel sizes for every field, thirty-two numbered requirements, but not a single sentence on the first page about why it's being done.

Which one is easier to work with? What's missing from both? And consider this: the developer who starts work from the three-line ticket, whom will they ask, and when, how shipping is calculated when there are several books in the cart?

One-Pagers and PRDs: What Are They For?

Discovery produces a decision: which problem we tackle, for which outcome, with which candidate solution. Delivery turns that decision into code. A bridge is needed in between; without one, the decision stays in the meeting and the code does whatever the Jira ticket says. The one-pager and the PRD are that bridge.

A one-pager, as the name says, is a single-page document whose purpose is alignment: do the team, the product owner and stakeholders understand the same problem, the same goal and the same boundaries? A PRD is more detailed and traditionally carries the full list of requirements. In practice the line between the two is blurry; many teams say "PRD" and write a one- or two-page document. Some companies have their own formats too: in Amazon's "working backwards" approach, the team starts by writing the press release and FAQ that will be published when the product ships.

Regardless of format, a good document answers two questions: why are we doing this, and how will we know we succeeded? Neither of the two opening documents answers them. The Jira ticket says what to do but not why; the fourteen-page PRD says how it should look but not why or how it will be measured.

The Skeleton: Problem, Outcome, Non-Goals, Risks, Open Questions

The skeleton of the one-pager the Bookstore team wrote for the cart abandonment work, and the content of each section:

Every row in the table corresponds to a post in the series. The problem statement comes from the four-part template in post 02, the target outcome and guardrails from the metric tree in post 06, the evidence from posts 03, 07 and 08, the risks from Cagan's four risks in post 01. A one-pager doesn't produce new thinking; it gathers the thinking produced in earlier steps onto a single page. That's why writing a one-pager for work without discovery is hard, and that difficulty is a good signal.

The Value of Non-Goals

The most skipped section of the document is the non-goals, yet it's the section that saves the team the most time. A non-goal is "something we consciously won't do within the scope of this work," and it does two jobs.

First, it stops scope from quietly growing. When the suggestion "if we're showing the shipping cost, let's add international orders too" comes up, the answer is written down and the discussion doesn't take a meeting. Second, it manages expectations. The general manager's one-click checkout idea sits openly on the non-goal list; that doesn't mean the idea was rejected, it means it isn't the subject of this work, and nobody asks why it wasn't built when the work ends.

A good non-goal is something someone could reasonably expect. "We won't move the database to MongoDB in this work" isn't a non-goal, because nobody expected it. "We won't lower the shipping fee" is a good non-goal, because someone reading interviews where customers say "shipping is expensive" might expect it.

From Decision to Backlog

Once the one-pager is approved, the decision turns into the backlog. In a Scrum team that means an epic in the Product Backlog with Product Backlog items under it; the mechanics of the Product Backlog are the subject of the Scrum series. What matters here is how you split: items should be split into end-to-end working slices, not by layer. An epic split into "Backend: shipping cost endpoint" and "Frontend: product page component" produces its first value only when both items are done. "Show the shipping cost on the product page to a registered customer with an Istanbul address" is a thin slice that can go to production and be measured on its own.

That's why the Bookstore team split its epic in this order: first the fee on the product page for registered customers with a known address, then a default city's fee and a "choose your city" link for guests whose address is unknown, then the same information in the cart, and last the free shipping threshold meter. Each slice brings along the work of adding the experiment and variant properties to the events from post 07, and the cleanup item that removes the flag after the experiment ends.

A common way to visualize this split is the story map Jeff Patton describes in "User Story Mapping" (2014): the user's journey on the horizontal axis, the work for each step on the vertical axis, what goes into the first release above a line. The details of story mapping, writing user stories and acceptance criteria are the subject of the upcoming Requirements Analysis series.

What a Developer Should Ask in a PRD Review

When a one-pager or PRD reaches the team, one of the people who should read it most carefully is the developer. The product owner knows the problem and the goal well; edge cases, where the data comes from and where the system will strain are best seen by whoever knows the code. The questions the Bookstore team's developers asked in the review:

• Edge cases: If the cart has books from different sellers or warehouses, is shipping calculated once or separately? What about pre-order books?
• Data: Where does the fee come from, the carrier's API or our own table? If the two differ, which one counts as correct?
• Performance: The product page's p95 response time is a guardrail; if the fee is calculated on every page view, will that target hold, or should it be cached per city?
• Migration: Do we need a new column in the orders table to track the difference between the fee shown and the fee charged? What will its value be for existing orders?
• Rollout and rollback: Does the change ship behind a flag, and is rolling back a single configuration change?
• Measurement and privacy: Which events and properties are needed, are they in the taxonomy, do they contain personal data?

These questions are not there to criticize the document but to complete it. Each answer goes either into the document's "Open questions" section or into a backlog item's acceptance criteria. Every question not asked in the review turns into a message a developer sends the product owner in the middle of the Sprint; more expensive and later.

In Production

The document lives. A one-pager isn't frozen on the day it's approved; it's updated as open questions are answered and experiment results arrive. But changes should leave a trace: adding a short decision log at the end of the document ("12 November: default city for guests is Istanbul, because the largest share of guest orders goes to Istanbul") answers "why did we do it this way?" six months later.

Make the document reachable from the backlog. The epic's description should link to the one-pager; a developer reading any item should be two clicks from the reason. Just as an Architecture Decision Record lives in the repository alongside the code, product decisions should sit next to where the work is done.

Close it when it's done. When the work is complete, a results section is added to the one-pager: was the target outcome reached, how are the guardrails, what was learned. That section goes into the evidence section of the next piece of work.

Common Pitfalls

The first pitfall is using the PRD like a contract. The document is handed to the team as "do what's written here," the team does what's written, and if the result doesn't hold, "that's what the document said." This is the document form of the feature factory from post 01. A one-pager is an alignment tool; the team writes it together, or at least reviews it together.

The second is a document that starts with the solution. A document that opens with "we will add the shipping cost to the product page" adds the problem and the goal later as justification. Everyone who reads it accepts the solution without questioning it. The first section of the document is always the problem.

The third is an unmeasurable success metric. "Improve the user experience" is not a success metric. If the document doesn't contain one of the metric definitions from post 06 and its target value, nobody can say whether the work succeeded.

The fourth is the long document nobody reads. Usually nobody on the team reads a fourteen-page PRD from start to finish, and an important sentence gets lost on page seven. The first page should be understandable on its own; detail can live in appendices.

A Small Experiment

★☆☆ Open the document for your team's last big piece of work (a Jira epic, a PRD, a wiki page) and look for the rows of the table in this post. Which sections are missing? In particular, are there non-goals and a success metric?

★★☆ Write a one-page one-pager for a problem in your product: the problem (with a number), the target outcome, a success metric and at least two guardrails, at least three non-goals, a sentence for each of the four risks, and open questions.

★★★ Review the next PRD that reaches your team with the six question headings in this post, and place each question either in the document's open questions section or in a backlog item's acceptance criteria. How many new items or criteria came out of the review?

The series ends here. We started with the request "build a campaign module"; we separated output from outcome, understood the problem by talking to customers, prioritized ideas, communicated them to stakeholders on a roadmap, defined metrics and measured them in code, decided with an experiment and carried the decision into the backlog. None of these steps is the product manager's job alone; in each of them a developer's question makes the decision better. Measuring and managing how those decisions flow is the subject of the Kanban series.