Product design

Phase 2 of the pipeline: turning a validated problem into the smallest product that solves it, drawn, scoped, prototyped and tested before any production code. It takes the validated problem brief from validation and hands a signed-off one-page spec, a story map with an MVP slice and a tested prototype to building the MVP. The whole pipeline is on the playbook; interface craft (heuristics, layout, forms, accessibility) is on UX/UI design principles.

Phase at a glance

The week, day by day

Entry criteria

Do not start Phase 2 without the validated problem brief from validation. Designing without it means designing for an imagined user, which is how people end up polishing a product nobody asked for.

VALIDATED PROBLEM BRIEF (input to Phase 2)
Who:            ___________________________________________
Problem (their words, quoted): ____________________________
Frequency:      ______________   Evidence: __ of __ interviews
Workaround:     ______________   Cost: ____ hours/£ per ____
Willingness to pay: _______________________________________
Channel to reach 50 more: _________________________________
Must-have outcomes:
  1. ______________________________________________________
  2. ______________________________________________________
  3. ______________________________________________________

From problem to solution

Work top-down: a job is the progress someone is trying to make; an outcome is how they would measure it; a story is a unit of product behavior that serves an outcome. Features come last.

User stories vs job stories

Adams's later post ("How we accidentally invented job stories", 2016) argues that personas focus on demographic differences when people in very different circumstances often share the same motivation.

Rules for good stories

• One behavior per story. "…and export and share" is three stories.
• The benefit clause must be a real outcome from the brief, not a restatement ("so that I can post a shift" is circular).
• Write stories in the user's words from the interviews. If no interviewee would recognize the situation, delete it.
• Acceptance criteria as Given / When / Then for anything touching money, permissions or data loss.

JOB STORY
When  <situation, trigger, context>
I want to  <motivation / what they're trying to do>
So I can  <expected outcome>
Evidence: interview #3, #5, #8 ("quote…")
 
USER STORY
As a  <role>
I want  <capability>
So that  <benefit tied to a must-have outcome>
Acceptance:
  Given <state>  When <action>  Then <observable result>

User story mapping

Jeff Patton's story map (User Story Mapping, O'Reilly, 2014; first described in his 2005 "It's all in how you slice it") replaces the flat backlog with a two-dimensional map, so you can see the whole journey and cut it horizontally.

Patton's warning (paraphrased): a flat backlog strips the stories of context, like pulling the leaves off a tree and then cutting the tree down. Prioritize how well each backbone step is done, not whether the backbone exists: an MVP that skips a backbone step does not work end to end.

STORY MAP: café rota tool (MVP slice above the line)
 
BACKBONE ►  Set up team   Build rota     Publish       Handle changes   Get paid*
            ───────────   ────────────   ───────────   ──────────────   ─────────
WALKING     add staff     copy last      send rota     post open shift  (manual
SKELETON    by phone no.  week, edit     by SMS link   staff claims it  invoice)
            ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
MVP         roles/skills  drag shifts    staff view    notify only      Stripe
(slice 1)   per person    conflict warn  (no login)    qualified staff  checkout
            ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
NEXT        import from   templates      calendar      swap requests    annual
(slice 2)   spreadsheet   by season      sync          between staff    plans
LATER       multi-site    labor-cost    printable     availability     payroll
            support       forecasting    PDF           preferences      export
 
* backbone steps may be manual in the MVP, but none may be missing

Scoping the MVP

The MVP is the smallest product that delivers the must-have outcomes to the target user, end to end, well enough that they would be upset to lose it. Not the smallest thing you can ship; the smallest thing that works.

Find the one core loop

The core loop is the repeated sequence where the user gets value: trigger → action → value → reason to return. Everything in the MVP either serves the loop or gets a user into it for the first time.

Test: describe the loop in one sentence without "and also". If you can't, you have two products.

MoSCoW

Dai Clegg's MoSCoW (Oracle UK, 1994, in Clegg and Barker's Case Method Fast-Track), later adopted by DSDM. It only works under a fixed timebox, which is exactly the MVP's situation.

A healthy MVP is mostly Musts. DSDM guidance is to keep Musts to no more than about 60% of effort so there is contingency; for a 2–4-week MVP, treat anything that isn't a Must as already cut.

Kano model

Noriaki Kano and colleagues, "Attractive quality and must-be quality" (1984), classify features by how their presence and absence affect satisfaction.

Categories drift over time: today's delighter becomes tomorrow's basic expectation. An MVP wins on one performance axis (faster, simpler, cheaper, more specific to a niche), meets the basics adequately, and ignores the rest.

The cut list

Keep a literal list of everything you removed and why. It is the most useful artifact of the week because it lets you say "not now" without arguing, and it becomes the start of the iteration backlog in launch & iterate.

Appetite: fixed time, variable scope

Ryan Singer's Shape Up (Basecamp, 2019) is the most useful framing for a founder who keeps overrunning. The key move is to set the appetite (how much time is this worth?) before designing, instead of estimating after. In Singer's words: "Estimates start with a design and end with a number. Appetites start with a number and end with a design."

Singer also argues "good" is relative to the appetite: a hot dog is the right meal when you're hungry and in a hurry. For an MVP, "good" means the core loop works reliably, not that every edge case is handled.

BREADBOARD: post an open shift
 
 Rota (week view)          Open shift form           Shift posted
 ────────────────          ───────────────           ────────────
 [shift cell]  ─────────►  role (prefilled)          "Sent to 4 staff"
 "Mark as open"            time (prefilled)   ─────► list: who was
                           note (optional)           notified
                           [Offer shift]             [Back to rota]
 
 Staff SMS link            Claim page
 ──────────────            ──────────
 "Shift Sat 7am" ───────►  shift details
                           [Claim]  ─────────► owner notified,
                                               rota updated

The one-page spec

One page, written in plain language, that you (and any co-founder or contractor) can build from. If it runs to three pages, the scope is too big.

ONE-PAGE SPEC (PRD-lite)                     v__  date: ________
 
PROBLEM
  In their words: "________________________________________"
  Evidence: __ of __ interviews; workaround costs ____/week
 
USER
  Primary: _____________________ (who pays? who uses? same?)
  Not for (yet): _______________________________________
 
CORE JOB
  When ______________, I want to ______________,
  so I can ______________.
 
SUCCESS METRIC (for the MVP)
  Activation: % of sign-ups who ____________ within __ days
  Core loop:  ____ completed per user per week
  Target by week 4 after launch: ______________
 
APPETITE
  Build: __ weeks (hard cap 6). Circuit breaker on: ________
 
SCOPE IN (walking skeleton + MVP slice)
  1. ______________________________________________________
  2. ______________________________________________________
  3. ______________________________________________________
 
SCOPE OUT (not now)
  - ____________________  (manual workaround: ____________)
  - ____________________
 
KEY FLOWS
  1. First run: sign up → ______ → first value ("aha") at ____
  2. Core loop: ________ → ________ → ________
  3. Payment:   ________ → ________
 
RABBIT HOLES (and the decision taken)
  - ______________________ → decided: ______________________
 
OPEN QUESTIONS (owner, due date)
  - ______________________  (_____, ____)
 
RISKS
  Value: will they use it?        test: ______________________
  Usability: can they use it?     test: prototype, 5 users
  Feasibility: can we build it?   spike: _____________________
  Viability: will they pay?       test: ______________________

The four risks in the last block are Marty Cagan's framing (Inspired, 2nd edition, 2017): value, usability, feasibility, business viability. Each needs a named test, not a hope.

User flows and information architecture

Map flows before screens. For an MVP you need exactly three: first run (sign-up to first value), the core loop, and payment. Everything else is a secondary flow and probably on the cut list.

FIRST-RUN FLOW (target: first value in under 3 minutes)
 
landing ─► sign up (email link) ─► "Add your team" (paste names
+ phone numbers) ─► rota pre-filled with a sample week ─► edit one
shift ─► "Send rota" ─► staff receive SMS ─► AHA: owner sees
"3 of 5 staff have viewed the rota"

Information architecture for an MVP is usually one navigation level with 3–5 items. Label with the words users used in interviews. Navigation patterns, IA rules and card sorting are covered in UX/UI design principles.

From sketch to prototype

When to skip Figma and prototype in code

A fluent React/Next.js developer can often build a throwaway clickable version on the real stack as fast as a Figma prototype. Go straight to code when:

• the UI is standard patterns (lists, forms, tables, a dashboard) and the risk is flow, not visuals;
• realism matters for the test: real typing, real latency, real data shapes (a paste-your-CSV step, a drag interaction);
• you commit in writing to deleting or heavily rewriting it. Keep it on a prototype branch with hard-coded data, no auth and no database.

Stay in Figma (or on paper) when the core concept is still in question, when you'd get attached to code, or when you need to show several alternative directions. The trap is spending the design week building infrastructure disguised as a prototype.

Prototype testing

Test the prototype with at least 5 people from the target segment, ideally people who were not in your validation interviews, and never friends or other founders.

Nielsen's five users

Jakob Nielsen ("Why you only need to test with 5 users", NN/g, March 2000), building on Nielsen and Landauer (1993), models the share of usability problems found with $n$ test users as

where $N$ is the total number of problems and $L$ the share one user reveals, 31% on average in their data.

Nielsen's recommendation was three rounds of 5 (fix between rounds), not one round of 15.

Test script

PROTOTYPE TEST (30–45 min, remote or in person, record with consent)
 
1. Intro (3 min)
   "We're testing the design, not you. Think aloud. Nothing
   you say will hurt my feelings. I didn't design it alone."
2. Context (5 min)
   "Tell me about the last time <problem> happened."
3. Tasks (20 min) — realistic scenarios, not instructions
   T1 "You've just signed up. Get your team's rota for next
       week out to your staff."
   T2 "Sam just canceled Saturday 7am. Sort it out."
   T3 "You want to keep using this after the trial. Do that."
   For each: success Y/N, time, where they hesitated, quotes.
   Don't help. If stuck > 2 min, note it and move on.
4. Debrief (5 min)
   "What was hardest?" "What did you expect that wasn't
   there?" "What would you do right now instead of this?"
5. Value check (2 min)
   "If this existed today, what would you stop doing?"
   Ask for a commitment: pilot, pre-order, intro to a peer.
 
SCORING
  Task success: __/5 users   Median time: ____
  Severity: 4 blocks the core loop · 3 major · 2 minor · 1 cosmetic
  Fix all 4s and 3s before build; log the rest.

Signals that matter: task success and where people hesitate. Signals that don't: "I like it", "looks clean", feature requests from people who couldn't finish T1. Asking for a small commitment at the end (a pilot, a deposit, an introduction) is the only part of the session that says anything about demand.

Design sprints, full and compressed

The Design Sprint was developed by Jake Knapp at Google and refined at GV (Google Ventures); it's described in Knapp, Zeratsky and Kowitz, Sprint (Simon & Schuster, 2016). A Decider makes the calls; a Facilitator runs the clock.

A 2–3-day solo version

A full five-day sprint is built for a team in a room. Solo, the value is the forced sequence: map → diverge alone → decide → fake it → test with five.

Book the five tests on day 1. Recruiting is the step that slips.

Design principles for MVPs

Define the aha moment as an event, not a feeling: "owner sends first rota and ≥ 1 staff member opens it", "user receives first payment through an invoice". It becomes the activation metric in the event plan below and in launch & iterate.

Pricing decisions at design time

Keep this short; the experiments come later in launch & iterate. But three decisions shape the design, so make them now.

A pricing page is itself a validation tool: publish it in the prototype and during launch, and treat clicks on "Start trial" or "Buy" as a signal. Prototype testers who balk at the price are telling you about the value, not the number. Price anchoring and willingness-to-pay interviews belong in validation.

Data model sketch

Sketch the data model as a design artifact, not an implementation detail. It exposes scope ("do shifts belong to a location or to a team?"), multi-tenancy and ownership questions that are expensive to change later.

ERD SKETCH: café rota MVP
 
 account (tenant) 1 ──< user (owner/manager)
     │
     1
     └──< staff_member ──< skill (role: barista, kitchen…)
     │         │
     1         └──< shift_assignment >── shift
     └──< rota_week ──< shift (start, end, role, status:
                                 scheduled|open|claimed)
 event (id, account_id, user_id, name, props jsonb, at)
 subscription (account_id, provider_customer_id, status)

Table design, constraints and indexes are on PostgreSQL and database design; the TypeScript schema is on Drizzle. Phase 3 turns this sketch into a real schema (recipe).

Analytics event plan

Decide what you'll measure before you build, so instrumentation lands with the feature rather than weeks later. Name events object_action in snake_case, past tense, and keep the MVP to 5–10.

Write down now: activation = rota_published and ≥ 1 rota_viewed within 7 days of account_created; core loop completed = shift_opened followed by shift_claimed. How to implement the tracking is in building the MVP.

Friction points and fixes

Where people stall in Phase 2, and what to do about it.

Exit criteria / handoff

Phase 2 is done when every box below is ticked. The package goes to building the MVP as its entry criteria.

PHASE 2 EXIT CHECKLIST (handoff to Phase 3: Build)
 
[ ] One-page spec signed off (by you and any co-founder), with
    success metric, appetite (build weeks, hard cap 6), scope
    in/out, rabbit holes decided, open questions owned
[ ] Story map with backbone, walking skeleton and a single MVP
    slice drawn; nothing in the slice that isn't on the core
    loop, first run or payment flow
[ ] Clickable prototype of the core loop tested with >= 5 target
    users (heuristic, not a law); all severity 3-4 issues fixed
    in the design; >= 4 of 5 completed the core task
[ ] At least some testers asked for a commitment (pilot,
    pre-order, intro); responses recorded
[ ] User flows: first run (with aha event and target time),
    core loop, payment
[ ] Data model sketch: tenant, core object lifecycle, event
    table, what must never be lost
[ ] Analytics event plan: 5-10 object_action events, activation
    and core-loop definitions written down
[ ] Pricing decision: charge from day one? one plan, value
    metric, where payment sits in the flow
[ ] "Not now" list (cut list) with the manual workaround for
    each item a customer might ask for
[ ] First 20-50 names for the launch list started (from
    interviews and testers)

References

• Jeff Patton with Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product (O'Reilly, 2014): backbone, walking skeleton, release slices
• Jeff Patton, "The new user story backlog is a map" (opens in a new tab): the original 2008 post introducing story maps
• Alan Klement, "Designing features using job stories" (Intercom, 2013) (opens in a new tab): the job story format, crediting Paul Adams
• Paul Adams, "How we accidentally invented job stories" (Intercom, 2016) (opens in a new tab): why situations and motivations beat personas
• Ryan Singer, Shape Up (Basecamp, 2019) (opens in a new tab): appetite, shaping, breadboards, fat-marker sketches, rabbit holes, no-gos, pitches, circuit breaker; free online
• Noriaki Kano, Nobuhiku Seraku, Fumio Takahashi, Shinichi Tsuji, "Attractive quality and must-be quality", Journal of the Japanese Society for Quality Control 14(2), 1984: the Kano model
• Dai Clegg and Richard Barker, Case Method Fast-Track: A RAD Approach (Addison-Wesley, 1994): origin of MoSCoW
• Agile Business Consortium, "MoSCoW prioritization" (DSDM) (opens in a new tab): the no-more-than-60%-Must-effort guidance
• Jakob Nielsen, "Why you only need to test with 5 users" (NN/g, 2000) (opens in a new tab): the 5-user curve and its assumptions
• Laura Faulkner, "Beyond the five-user assumption" (Behavior Research Methods, 2003) (opens in a new tab): the variance behind the 85% figure
• Jake Knapp, John Zeratsky, Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (Simon & Schuster, 2016): the design sprint
• GV, "The Design Sprint" (opens in a new tab): the five days as GV describes them
• Marty Cagan, Inspired: How to Create Tech Products Customers Love (2nd ed., Wiley, 2017): value, usability, feasibility and viability risks
• Nielsen Norman Group, "10 usability heuristics" (opens in a new tab): the checklist for reviewing the prototype