Epic Writing Guide — The Product Playbook

Part 04 ends with a card that says build. An opportunity made it through the loop: the problem was real, the experiment moved the numbers, and the validated solution got handed to the product backlog. This page is what happens next. You turn that card into work an engineering team can pick up and finish.

Two different objects sit on either side of that handoff. An opportunity is the validated customer problem from Part 04, the thing you proved was worth solving. An epic is how you deliver the solution. Keep them separate even if they live in the same place. The opportunity holds the why. The epic defines the how. Every epic stays tied to the opportunity that justifies it, and by the end of this page that link is the test for whether the work should exist at all.

A quick word on tools, because you're going to ask. I've run discovery in one tool and delivery in another, and I've used the work-tracking tools you'd expect for both. None of them manages discovery and delivery well together, and that's not a knock on any one of them. Most of these tools are built for how people already work, not for keeping one problem's discovery and delivery linked. So don't go looking for the perfect tracker. Pick whatever you've got, run the epic-story-task hierarchy the right way inside it, and don't let the tool tell you how to think.

So what is an epic, exactly? A large body of work that delivers something a customer can feel. Bigger than a single sprint, the one-to-two-week cycle most teams run. Small enough to finish in three to eight weeks. Too small and it's just a story, the smaller unit of work the next page teaches. Too big and it's a roadmap hiding in your backlog.

A note on levels before we go further. The hierarchy here is epic, then story, then task. Some organizations slot a "feature" tier between epic and story. You don't need it. Three levels, each one sized a level smaller than the one above it, is enough to tell a team exactly what to build.

One problem, many epics

The relationship between an opportunity and its epics runs one to many. One customer problem usually takes several epics to fully solve, and the split happens along three natural seams.

Multiple teams. Web, mobile, and the platform underneath each own their piece.
Phased delivery. Simplify the flow now, personalize it next quarter.
Platform components. The signup flow, the guided tour, the tracking under both.

Each epic ships on its own. That independence is what lets three teams attack one problem in parallel without waiting on each other.

Hold onto that mapping. Every epic should point at the opportunity it serves, and we'll come back to it before you mark the epic ready.

An epic is communication, not admin

Here's how you actually write one. A headline, then a narrative.

The headline is the problem formula you learned back in Part 04 (When... As... I want... So that... But...). Each slot does a job: When sets the trigger, As names who's affected, I want states what they're after, So that gives the payoff, and But captures the friction in the way today, the reason this is still broken. It travels. The same shape that defined the problem at the opportunity level now opens the body of the card, right under the title.

The narrative is the one or two paragraphs below it. It tells the story of the user, what they're trying to accomplish, and why. Write it so that when you come back to the card a month later, or someone who was never in the room reads it, they don't just get a sense of what needs to be built. They get why, and what business problem it's solving.

That's the real job of the epic. Not compliance. Not making the tracker look organized. It's the communication that answers the questions for you when you're not in the room to answer them, which is most of the time: the engineer who picks this up next month, the stakeholder who asks why, the new hire who never met you.

An epic isn't a feature request with a fancy name. It's a promise that a customer can do something they couldn't before, with a finish line.

"We already know what we're building. Writing all this down is overhead." Picture the epic that's just a title: "Build the dashboard." Six weeks later three people have quietly built three different dashboards, and nobody can say whether any of them is done, because done was never written down. Three people build the SAME dashboard only when the dashboard is defined on the card.

What makes an epic good

Five tests. Run every epic you write against all five.

Customer-focused. Written from the user's perspective, not the system's. If your epic opens with a database, start over.
Measurable. Clear success criteria. You can say, with a number, whether it worked.
Sized right. Three to eight weeks of work. As a rough convention, mine has run 15 to 40 story points (story points are the relative-effort numbers a team assigns in planning poker, the estimation method from one page back), but points are local: that's my rule of thumb, not research, and yours won't map to mine anyway.
Independent. It can be delivered without waiting on another epic to finish first.
Valuable. It delivers an outcome a customer can feel, not a milestone only your team can see.

The sizing test is the one teams blow most often. If the epic wants three months, it isn't one epic. Split it along one of the seams above, usually phases, and let each phase earn its own finish line. And anything under three weeks isn't an epic either. It's a story, or a couple of them, and the next page teaches you those.

The template, top to bottom

Title. [Action] [Capability] for [User Type]. "Automate Payment Reminders for Finance Teams." A stranger should know what this is from the title alone.

Problem statement. This is the headline from above: the When/As/I want/So that/But formula, straight onto the card. You already validated this language at the opportunity level. Don't rewrite it from memory. Carry it over.

Solution overview. Two or three sentences describing the approach. This and the line below carry the narrative from above. Resist the urge to spec here. The epic points at the solution. The stories underneath carry the detail.

Expected outcome. What users can do after this epic is complete that they couldn't before. This is the line that earns its keep: a finish line a non-engineer can check.

Success criteria and acceptance criteria. Two different jobs, and people blur them constantly. Success criteria are the measurable outcomes that make the epic done: the completion rate hit by a date you wrote down, the benchmark met, the tracking live. Acceptance criteria describe behavior, written in the Given/When/Then shape: a behavior in three parts, the starting condition (Given), the trigger (When), and the expected result (Then). That format comes from behavior-driven development, the Dan North lineage, and you'll see a real one in each worked example below. Success criteria tell you the epic worked. Acceptance criteria tell you each piece behaves.

Out of scope. Clearly list what this epic does NOT include. More on this in a minute, because it deserves more than a bullet.

Dependencies and risks. What this epic depends on, what it blocks, and what could go wrong. Naming what you depend on protects you. Naming what you block is the courtesy: the team waiting on you finds out now, not at their planning meeting.

Metrics. Primary metric, baseline, target. Where success criteria are the pass/fail done-line ("did it work, yes or no"), this block is the raw number underneath it: the metric, where it started, and where you need it to land. Part 07 is where you learn to pick these numbers. The epic is where they get written down, so "did it work" has an answer waiting before a single line of code ships.

Labels. Most templates carry a few. I won't hand you mine, because labels are how you sort work through your own pipeline, and yours won't look like mine. Use them to sort by your workflow: a label for the team, the platform, the quarter, whatever your board actually filters on. They're meant to be flexible. Steal your team's convention, not someone else's.

Out of scope is half the definition

Most epic templates don't have an Out of Scope section. Mine makes it first-class, and that's deliberate. What you're NOT building is half the definition of what you are.

Scope creep doesn't announce itself. It arrives one reasonable request at a time. Each one small. Each one from someone you'd like to say yes to. None of them looks like the thing that sinks the epic, because the thing that sinks the epic is all of them added up. The Out of Scope section is you saying no in advance, in writing, while no is still cheap.

So write yours concretely. Not "no extra features," but the actual adjacent items people will ask for, by name. From the worked example you're about to see: partial payments (its own epic, next phase), auto-charge opt-in (needs its own validation first), the customer's internal approval workflow (not ours to build). Every line is a future argument you've already won, sitting on the card before anyone shows up to have it.

Here's the test for whether your Out of Scope list is doing its job: hand the epic to someone who wasn't in the room and ask them to name three things they assumed were included. If they're right, you under-wrote the scope. If they're surprised, the list is working.

The worked thread, as an epic

Let's run the template on the playbook's worked example. Since Part 04 we've been following an illustrative business-to-business case (a teaching thread, not client work): an invoicing tool. Businesses use it to invoice their customers, and those customers pay the invoices late, choking the businesses' cash flow. The loop validated automated reminders with a pay link, because the lateness turned out to be friction at pay-time, not unwillingness to pay.

Here's that card as an epic.

Title: Automate Payment Reminders for Finance Teams
Problem statement: When an invoice goes past due, As a finance lead, I want my customer nudged with a way to pay on the spot, So that on-time payments rise and cash flow steadies, But today every reminder is typed by hand and paying still takes a login and three screens.
Solution overview: Automatically send reminder emails on a schedule once an invoice passes due, each carrying a one-click pay link.
Expected outcome: A finance lead can turn reminders on once and watch the on-time rate, instead of chasing invoices one by one.
Success criteria: On-time payment rate from [your baseline] to [the target you set in Part 07] by [date], and the tracking that proves it live before launch.
Acceptance criteria (one of several): Given an invoice is three days past due, When the reminder schedule fires, Then the customer receives an email with a one-click pay link.
Out of scope: Partial payments (its own epic, next phase). Auto-charge opt-in (needs its own validation first). Anything inside the customer's internal approval workflow.
Dependencies and risks: Depends on the payments provider behind the pay link. Risk: reminder emails read as nagging and get marked as spam.
Metrics: Primary metric: on-time payment rate. Baseline: [from your data]. Target: [your Part 07 commitment].

On a real card, those brackets hold numbers and a date. This case is illustrative, and I don't invent metrics, so yours come from your own data and the target you committed to in Part 07. What matters here is the shape: a number to beat, a date to beat it by, and the tracking already counting.

Notice the one-to-many at work. The opportunity was "customers pay late." This epic delivers reminders and the pay link. Partial-pay sits in Out of Scope with its own epic's name on it. One problem, several epics, each with its own finish line.

A second specimen, so the shape isn't an accident

One worked example can look like luck. Here's a second, in a completely different domain, so you can see the same skeleton hold.

This one's an onboarding epic, and it's purely illustrative. Treat every number in it as a placeholder, not a result I'm reporting.

Title: Simplify First-Run Signup for New Users
Problem statement: When a new user lands on the signup screen, As someone evaluating the product for the first time, I want to get to a working account in under a minute, So that I see value before I lose patience, But today the form asks for fields I don't have yet and drops me halfway.
Solution overview: Cut the signup flow to the fields a first run actually needs and add a single social-login option, deferring the rest until the user has a reason to fill it in.
Expected outcome: A new user reaches an active account on the first try without abandoning the form.
Success criteria: Signup completion rate from [illustrative baseline] to [illustrative target] by [date], measured on real first-time traffic.
Acceptance criteria (one of several): Given a new user chooses social login, When they authorize, Then an account is created and they land on the first-run screen with no further form.
Out of scope: Profile personalization (next epic). Team invites (separate flow). Any field not required to create the account.
Metrics: Primary metric: signup completion rate. Baseline and target: illustrative, replace with your own.

Same skeleton. Different problem. A title a stranger can read, a problem statement carried from the opportunity, a finish line a non-engineer can check, and an Out of Scope list with real names in it. The numbers here are made up on purpose. The structure isn't.

Before you call it ready

The last thing you do before marking an epic Ready for Development is run the author checklist.

Problem defined in the formula, carried from its opportunity
Success measurable and time-bound
Every acceptance criterion testable
Dependencies identified, and the teams you block told
The tracking that produces your metric planned, not assumed
Out of scope explicitly stated
Estimated by the team that will build it, not by you (that's what planning poker was for)
Linked to its opportunity

That last line is the quiet tripwire. If you go looking for the opportunity behind your epic and can't find one, you haven't found a paperwork gap. You've found work with no why, and it deserves the same treatment as any other unvalidated idea: back through the loop, or out of the backlog.

None of this structure is ceremony. It's how the team knows exactly what you're building, why it matters, and when you're done.

So put it to work. Take the top card in your backlog marked build and write its epic today. Headline, narrative, finish line, and an out-of-scope list with real names in it. Then break it into stories. That's the next page.