// 01 · what it does

Force the cut.

one-pager compresses any argument into a single page calibrated for a specific audience and ask type. Ask type is required: approve, fund, prioritize, feedback, or awareness. The output (400–600 words) leads with the ask, states the problem, proposes an approach, explains why now, sizes the impact, names the cost, lists key risks, and closes with next steps. The audience and ask determine what's included and what's cut — a "prioritize" one-pager for a VP Product is structured differently than a "fund" one-pager for a CPO.

A one-pager's job is not to explain everything — it's to make the reader capable of making one specific decision. Everything that doesn't serve that decision is cut. one-pager enforces that discipline by requiring the PM to name the ask before the argument is built. If you can't name what you're asking the reader to do, the skill will surface that before proceeding.

Day 17 follows the launch checklist because by now the PM has a fully formed initiative — a business case, a prioritization rationale, and a launch plan. The one-pager is what you hand a stakeholder when you need a decision in 3 minutes, not 30. It also forces a question that the business case doesn't: if you had to cut every word that doesn't serve the decision, what would you keep?

// 02 · sample prompts

Two ways in.

prompt.basic.txt
/one-pager

Audience: our VP of Product.
Ask: Prioritize — add this to our next quarter roadmap.
Initiative: build a notification system that reminds adventurers about upcoming experiences 48 hours before the event, with weather information attached. We've had requests for this from users and it could reduce no-shows.
prompt.advanced.txt
/one-pager

Audience: Dana Park (VP Product).
Ask: Prioritize — add the adventurer repeat engagement loop to the post-Android-GA Q3 roadmap alongside guide activation and Instant Book flexible mode.

Context: I need Dana to decide to add this to the Q3 roadmap at our quarterly planning meeting next week. She has 3 minutes for this doc, not 30.

Initiative: build a personalized re-engagement loop for adventurers who have completed at least one booking. Core components: post-experience push notification 3 days after an experience (surface related listings), personalized "you might like" suggestions on app open based on past activity, and a booking history page that shows completed experiences with re-booking options.

Evidence:
- Current repeat rate: 38% (target: 45%)
- CAC: ~$38 per adventurer
- 7-point improvement × 47,000 MAU × $185 avg booking value = ~$609k additional GMV annually without new acquisition spend
- Day 7 feedback synthesis: "I forget to come back unless I'm planning a vacation" appeared in 6 instances across NPS verbatims, adventurer interviews, and post-booking surveys
- Day 8 data: no current cohort analysis on time-to-second-booking — this is a known gap, not a blocker for the decision

Engineering estimate: 3–4 sprint weeks across iOS, Android, backend. Single Android engineer is the constraint — this work cannot start until Android GA ships in 6 weeks.

Competing priorities: guide activation listing setup guidance and Instant Book flexible mode are also legitimate Q3 investments. The Day 11 prioritization recommended this sequence: guide activation first (lower Android dependency), repeat loop second (can start post-Android GA), Instant Book flexible mode third.

Why now: we have the evidence, the engineering is available post-GA, and every month without a re-engagement loop is CAC spend we can't recover with repeat bookings.
// 03 · reflection

Three questions.

  1. 01What did the one-pager cut from the business case that you thought was important — and was the cut right for this audience and ask?
  2. 02Does the "why now" argument hold up if Dana asks one follow-up question — and what is that question?
  3. 03What would the equivalent one-pager look like for Sam Rivera (Head of Engineering) — and what would be different?