From 10 Interviews to a One‑Page Spec: A 90‑Minute Template + Worked Example

A one‑page spec is not a replacement for detailed docs — it’s a decision artifact you use to align team priorities and start building. In 90 minutes you can move from messy interview notes to a prioritized feature set framed by problem, user, and evidence. That reduces ambiguity for engineering handoffs and keeps early builds honest to customer needs.

This one‑page approach borrows from lean research and product one‑pagers used across UX teams and collaborative whiteboard templates: capture the job to be done, three core user stories, acceptance criteria, and a short prioritization rationale. The goal is fast clarity — enough context for design and engineering to scope an MVP sprint without waiting for a lengthy MRD.

Set a 90‑minute session with one facilitator (product founder or PM), one synthesizer, and optionally a designer or engineer for feasibility checks. The agenda: 0–10m align on interview cadence and top hypotheses; 10–40m rapid extraction (note cards); 40–70m affinity mapping + vote; 70–85m build the one‑page spec; 85–90m assign next experiments. Timeboxing forces tradeoffs and prevents hours of rumination.

For extraction, use a simple note card per meaningful quote or observed pain (digital sticky notes in Miro, Mural, or FigJam work well). Each note should include: verbatim quote (or short paraphrase), inferred need, and interview id. During affinity mapping cluster by problem, not by suggested solutions — that preserves why the user cares rather than how they imagine a fix.

Use this exact layout when you build the one‑page spec: Title; Target user (1‑sentence); Core problem statement (1 sentence); Supporting evidence (3 bullet quotes with interview ids); Top 3 jobs‑to‑be‑done or user stories; Acceptance criteria (1–2 checks per story); Priority and rationale (RICE-lite or simple High/Med/Low); Quick feasibility note and next experiment. Keep text concise — the document must be skimmed fast.

Worked example (indie app idea: 'Inbox for freelance invoices'): Target user — solo freelancers who invoice monthly. Core problem — tracking sent invoices and client payment status is time consuming and error prone. Evidence — three short quotes pulled from different interviews showing frequency and impact. Top stories and acceptance criteria follow directly from those clusters; priority explains why a payment‑status dashboard (MVP) beats automated reminders (later).

Prioritize clusters by a combination of: frequency across interviews, the intensity of emotional language (how painful the problem felt in the quote), and relative engineering cost. For speed use a three‑bucket system (High/Med/Low) and one feasibility note from an engineer or through a quick search of existing solutions. That’s enough to pick an MVP slice for a single sprint.

Convert the one‑page into an experiment plan: hypothesis, prototype type (clickable vs. code), primary metric, cohort, and duration. Use your interview evidence in the hypothesis (e.g., “Because 7 of 10 freelancers said X, we believe a payment‑status dashboard will increase on‑time payments by making status visible”). After the experiment, update the spec with measured learning — that closes the loop and preserves evidence for future roadmap decisions.