The Initiative DocumentInitiative DocumentThe PR/FAQ-shaped document where an initiative's context lives — customer, solution, plan, business case, and success metrics. is the strategic north star for an effort. It is shaped after the PR/FAQ tradition: you write the press release and the hard questions before the work, so the team argues about the idea while it is still cheap to change. The Initiative AuthorInitiative AuthorThe person accountable for an initiative's context — they write and keep the Initiative Document honest. creates it at inception and refines it over the life of the initiative. The bar to clear is simple — a new joiner should read it and get up to speed in 30 minutes, and everyone in the company should be able to read it at all.

Open with a title and a one-line tagline at the top, then carry the whole context of the work in five mandatory sections, plus optional FAQs. Write the sections in order; the order is the argument.

1. Customer

Start with the customer and the problem, in their words. If you cannot state the problem without naming your solution, you do not yet understand it.

• Who is the customer? One sentence, specific enough that you could find them on the phone or target them in a campaign — “parents with two or more kids intending to travel,” not “families.” A marketplace can have two customers (buyer and seller, or buyer and user); name both.
• What is the problem or opportunity? Fill the template literally: “TODAY [customer type] HAVE TO [problem or opportunity] WHEN [situation].” If you cannot complete the sentence without naming your solution, you do not yet understand the problem.
• How do you know what they need? Name the validation method — questionnaires, prototypes, personal experience — and the metrics that size the need. A claim with no evidence is an assumption, and assumptions belong on the Uncertainty ListUncertainty ListThe team's living list of open unknowns — sized 1/3/5, phrased as questions, reviewed daily and in planning, chipped away each week..
• How are customers solving it today? Their current workaround is your real competition.

2. Solution

Describe the solution in one to three paragraphs that capture its essence — plain enough that your mother would understand it. Enough to orient the reader, not enough to constrain the team. The week-by-week detail belongs in The ApproachThe ApproachThe multi-week narrative roadmap — titled weekly outcomes ("The one where…"), each with a demo, planned backwards from success., not here.

Then show it. An 8–12 panel storyboard or comic strip walks the customer through the experience, panel by panel. Drawing the storyboard is where vague solutions fall apart — if you cannot sketch the sequence, you have not designed it.

3. Planning & Team

• Expected timeline — a key achievement per week if the effort is under twelve weeks, per month if it runs three months or more.
• Time-critical events — conferences, infrastructure freezes, dependency deadlines, anything the calendar imposes on you. If there are none, say so explicitly and say why.
• Relationship to other projects — dependencies you create or inherit, and the risks that ride along with them.
• Team shape — the roles and responsibilities the work needs (User Research, Business Intelligence, and so on), not a list of names.

4. Business Case

• Market — Total Addressable Market or the size of the customer segment.
• Budget — in euros or person-months.
• Back-of-napkin case — one or two paragraphs that show the maths roughly holds. An extended calculation is optional; the napkin is not.

5. Measure Success

State, up front, what signal would tell you this worked. Vague metrics are the single most common failure mode of this artifact.

Use a mix of lead and lag metrics, kept close to the customer problem. Resist the urge to make revenue the primary metric — it is too far from the work to guide a weekly demo. Then define achievement levels: Gold / Silver / Bronze, so the team and the Product BoardProduct BoardTwo or more stakeholders who see the team's weekly demo and coach it — the human in the loop, with no single lead. share one definition of done.

Optional: FAQs

Two FAQs catch the questions the five sections don’t.

• Internal FAQ — the questions colleagues will ask, each with an answer or an honest “TBD.”
• External FAQ — the questions customers will ask.

A “TBD” here is not a failure; it is a candidate for the UncertaintyUncertaintyWhat the team does not yet know — sized and tracked deliberately rather than hidden inside estimates. List.

Fill-in template

Copy this block to start a new Initiative Document.