Template pack

§Everything below is the operational side of Product Foundation: the documents the body of the whitepaper deliberately kept out. Each is short, and each encodes one decision from the chapters so that the team makes it once.

§ A.1Requirement with an appetite#

§One page. Who: the person with the problem, named the way they would describe themselves. What they must be able to do: one sentence, in their words, that is true when the work ships. What is out: three to five things this piece of work explicitly does not do. Appetite: the time the team is willing to spend, in person-weeks. How we will know: three to six acceptance criteria written as things a stranger can do. The question it answers: the discovery question this work traces to. If that last line is blank, the requirement is not ready.

§ A.2User story with acceptance criteria#

§"As a [person], I can [action] so that [outcome]." Then the criteria, each beginning with a person and ending with an observable result. Test each story against INVEST from chapter 7 before it enters the week: independent, negotiable, valuable, estimable, small, testable. A story that fails "small" is two stories. A story that fails "testable" is a wish.

§ A.3RACI in one paragraph#

§For a team of five, the whole matrix fits here. What to build and for whom: product accountable, engineering and design consulted, everyone informed. How to build and how long: engineering accountable, product consulted. What ships this week: product accountable, engineering responsible. Whether to take on technical debt to hit a date: engineering accountable, product consulted, the cost recorded in the debt ledger. What the product looks like: design accountable where there is a designer, product otherwise. Write the paragraph once, pin it where the team can see it, and rewrite it when someone joins.

§ A.4Ritual calendar#

§Weekly planning, thirty minutes, ends with an appetite per piece of work or it did not happen. Demo whenever something is usable, fifteen minutes, acceptance criteria read aloud against the thing. Retrospective when something went wrong, not on a schedule. Customer conversation, at least one per week, run by the owner, synthesized the same day. Debt ledger read before planning. That is the whole calendar for a team of five. Add nothing until something is visibly missing.

§ A.5UX audit checklist#

§Before anything ships, walk the five planes from chapter 5 and the seven questions from the honeycomb. Strategy: who is this for and what job does it do; can you say it in one sentence. Scope: is the job finished when they are done, or half finished. Structure: draw the path from landing to done; count the dead ends. Skeleton: on the most important screen, is the next step the most visible thing. Surface: does it look like something a stranger would trust with their data. Then the seven: useful, usable, findable, credible, desirable, accessible, valuable, each answered by watching one stranger, not by the team.

§ A.6Debt ledger#

§A running list, owned by engineering: the shortcut, the date, why it was taken, what it costs to unwind, and whether the code it lives in will survive the next version. Read at planning. Pay down what is due; let the rest ride.