Journeys — where products die

Chapter 0.2 left us with four people, and there is a trap hiding in that accomplishment: a persona is a portrait, and portraits hold still. Mai does not hold still. She discovers us on a Tuesday, evaluates us skeptically on a Wednesday, and by Friday she has either sent a message between two browser tabs or closed the tab forever. A product is not judged by people; it is judged by people in motion — and products die at specific, findable places along that motion. This chapter maps them.

We take our four personas and walk each one's journey — and we mark, in every journey, the single stage that decides it. The tutorial calls these the ★ moments, and by the end of the chapter you will have found the ones in your own product.

The anatomy of a stage

A journey map is only as honest as its stages, so before we walk anywhere, let's dissect one. Every stage in our maps records the same six things: what the person is doing, what they are thinking, what they are feeling, where it hurts, what we could do about it — the opportunity — and a measure that would tell us whether we did.

Here is the dissection applied to the specimen we learn the most from — Mai's second stage, Evaluate, which the journey document calls the most under-served stage in this category. What is she doing? Reading — the quickstart without running it, the WebSocket protocol spec, the pricing page, the status page history — and pointedly not signing up. What is she thinking? Have these people actually run this in production? What is she feeling? Skeptical — she is scanning for reasons to eliminate us. Where does it hurt? A quickstart that demands signup before showing code; reconnection and ordering behaviour left undocumented — the strongest negative signal available to her; pricing that makes her guess three variables. The opportunity: publish the entire API reference without authentication — nothing else in this stage matters as much — and document reconnection, ordering, and idempotency precisely. The measure: docs-to-signup conversion, and time spent on the protocol pages.

Notice what the anatomy forces. "Feeling: skeptical" is not decoration — it predicts her behaviour (eliminate, don't explore). And the measure turns a soft story into an instrument we can read. A journey map without feelings is a flowchart; a journey map without measures is a wish.

Mai's eight stages — and the one that decides everything

Mai's full journey runs from the day messaging lands on her roadmap to the quiet months of operating it:

DISCOVER → EVALUATE → SIGN UP → FIRST MESSAGE → BUILD → TEST → LAUNCH → OPERATE
                                      ★

Her emotional arc dips twice: once when evaluation meets pricing reality, and once — deepest — in the tense minutes before her first message either arrives or doesn't. Signup is pure friction ("just give me the key"); Build is weeks of productive integration; Test is where she turns deliberately adversarial, simulating the 2am failures before they happen; Launch is short and exposed; Operate is the longest stage, where the ideal feeling is nothing at all.

But one stage decides everything, and the journey document gives it the star. Stage 4 — the first message. Mai pastes the quickstart, installs the SDK, opens two browser tabs, types "test", and hits send with the emotional state the document records as please just work. Success converts tense concentration into sharp relief and delight. Failure converts it into immediate abandonment — nearly all abandonment happens before the first message is delivered. The target is brutal and specific: under ten minutes from API key to a message travelling between two tabs, with more than 60% of signups getting there.

And the document names the single most common way this stage fails: confusion between the API key and the user token — which credential goes where. It deserves, and gets, its own explicit explanation in the docs, an error message that names the mistake, and a dev-mode token helper so Mai is not forced to build JWT signing before her first hello. The highest-leverage feature in the entire product lives in this stage too: a live event stream in the dashboard, where Mai watches her connection appear and her message arrive. It converts anxiety into confidence faster than any documentation can.

David — the journey with no star

David's journey runs alongside Mai's, typically waking up near the end of her Build stage, and it moves through four phases: awareness (Mai proposes buying), diligence (he reviews pricing, security, terms, incident history), approval (he signs off on spend — unbounded cost exposure is his blocker, hard spending caps are what unblock him), and oversight (he checks cost monthly and is paged during incidents).

Look for David's ★ and you will not find one — and the absence is the lesson. The other three journeys are decided at a moment; David's is not, because he can stop the project at any point. His power is a continuous veto, which is why his journey maps as gates — what blocks him, what unblocks him — rather than stages with feelings. Some stakeholders decide at a moment; buyers decide continuously. The design implication is written into the journey document: spending caps, usage attribution, and honest incident communication are not dashboard decoration — they are the features that get the purchase approved, and that keep it approved every month afterward.

Priya's Tuesday — and the stage that fails silently

Priya's journey is a scenario, not a lifecycle: a driver disputes a penalty, claiming the dispatcher never sent a delivery address, and an abuse complaint lands in her queue the same Tuesday morning. Six stages: ticket → locate → reconstruct ★ → judge → act → record.

The star sits on reconstruct, and the journey document's argument for it is the sharpest piece of requirements thinking in Part 0. The driver says the address never arrived. Three possibilities: it was never sent; it was sent and deleted; it was sent and edited afterwards. A history model that cannot distinguish these three is useless for her purpose — and most homegrown chat systems cannot. Hard deletes make "never sent" and "removed" indistinguishable. In-place edits destroy the original text. Client-side timestamps make the sequence of events a claim instead of a fact.

In the mapped Tuesday, Priya expands the edit history on a suspicious message and finds it: the dispatcher edited the address message eleven minutes after sending it. That's the whole case — resolved from the record alone, without interviewing either party. This single stage justifies four decisions we will implement in Part 2 and beyond: tombstones (a deletion is visible as a deletion, in place, in order), immutable edit history (every prior version, timestamped), server-assigned sequence numbers (order as fact), and complete history access for moderators. When someone later proposes cutting any of them, this is the journey that gets re-read first.

Tuan's two minutes — the moment the platform was built for

Tuan's journey is measured in seconds, and he takes it two hundred times a day. The journey document maps it at the level of a single message sent under bad conditions, because that is the unit at which the platform earns or loses his trust. The scenario: Tuan is driving into an underground car park; the dispatcher asks which entrance he's at; he types "B2, north ramp" and hits send as the signal dies.

TYPE → SEND → LOSE SIGNAL → RECONNECT → CONFIRM → MOVE ON
                   ★

The star sits on lose signal — the moment, the document says, that the platform was actually built for. The send is in flight; the socket dies; the message shows a clock icon; Tuan puts the phone down and keeps driving. He expects the app to sort itself out, because messaging apps always do — an expectation set by consumer messengers with hundred-person infrastructure teams, now held against Mai's two-person team, which means we must meet it on their behalf.

Everything that happens next is invisible and load-bearing. The SDK has already queued the message locally, with an idempotency key generated before the failure — so whatever happens next, retrying is safe. Ninety seconds later the phone catches the car-park wifi and reconnects with backoff and jitter — jitter, because forty drivers' phones reconnect in the same second, and a thundering herd of synchronized retries is a self-inflicted outage. The client presents its resume cursor; the server backfills the dispatcher's "ok, coming down", sent while Tuan was offline; the queued "B2, north ramp" flushes with its original key, and the server either persists it or recognises the duplicate. When Tuan glances at his phone by the lift: one "B2, north ramp", marked sent, the reply below it because sequence numbers say so. Total journey: two minutes, zero conscious decisions.

The asymmetry that defines this journey: executed perfectly, it produces no feeling at all — no review, no ticket, no signal. Executed badly, it produces a duplicated message, a lost address, a dispute in Priya's queue, and a one-star review of the customer's app naming "messages don't send" as the reason. Infrastructure's failures are always attributed to someone else's product. That is the deal, and it is why the reliability requirements carry the priorities they do.

Where the effort goes

Four journeys produce more opportunities than any team can build at once, so the journey document ends by ranking them where the funnel leaks most: the first message above all; public, complete documentation; the request log; usage attribution; environment isolation. Three of Mai's stages — discover, sign up, launch — rank low not because they don't matter but because they need restraint (removing friction) rather than capability.

But the ranking carries a warning about its own scope. It ranks Mai's stages because adoption is the current constraint — and it explicitly does not rank Priya's and Tuan's journeys against them, because those are not optional. Tuan's journey is the Phase 1 exit criterion: the product does not exist until his message survives the tunnel. Priya's journey gates the moderation surface: it either supports her Tuesday or it doesn't. The document compresses this into the line worth memorising: Mai's journey determines whether anyone adopts the platform; Priya's and Tuan's determine whether it deserves to be adopted.

Your turn

Time to map your own product's journeys — from the persona set you built in chapter 0.2, not from imagination. (Veterinary clinic scheduler? Keep it.)

Exercise 1 — the primary persona's journey. Take your primary persona and map their path from first contact to steady use in five to eight named stages. For each stage, record the anatomy: what they are doing, thinking, and feeling, plus one concrete pain point and one measure that would tell you the stage is working. Use the Evaluate specimen above as your template — and hold yourself to the standard it sets: a feeling that predicts behaviour, a measure you could actually instrument.

Exercise 2 — the invisible persona's journey. Now take the persona from your set who never chooses your product, and map their journey at a different granularity: not a lifecycle but a single interaction under bad conditions — the vet clinic's pet owner receiving (or not receiving) one appointment reminder, the way Tuan sends one message through a tunnel. Seconds, not weeks. Map what they do, what they expect, and what your system must guarantee at each step for them to feel nothing at all.

Then mark the stars. For each journey, mark exactly one stage with a ★ and write the reason in one sentence: if this stage fails, the rest never happens. If you cannot choose between two stages, you have not yet found the one the journey actually hinges on — keep arguing with yourself until you can.

Self-checks. Each answers yes or no:

1. Does every stage record a feeling — not just actions?
2. Does each journey have exactly one ★, with the reason written down?
3. Does at least one mapped journey belong to a persona who never signs up?
4. Is at least one pain point per journey something your team could cause this quarter — by accident, with good intentions?

If check 1 fails, you have drawn a flowchart. If check 3 fails, revisit chapter 0.2's invisibility test — the journey that is hardest to map is usually the one holding your hardest requirements.

Keep the journey maps with your 0.1 and 0.2 artifacts, in the repository. Chapter 0.4 turns these maps into requirements with IDs, priorities, and verification methods — and your ★ moments will tell it where the P1s live.

Takeaways

If you read nothing else in this chapter, keep these:

• A persona is a portrait; a journey is that person in motion — and products die at specific stages of that motion, not diffusely.
• A stage has an anatomy: doing, thinking, feeling, pain, opportunity, measure. Without feelings it's a flowchart; without measures it's a wish.
• Mark the ★: three of our four journeys are decided at one stage — Mai's first message, Priya's reconstruction, Tuan's lost signal — and effort concentrates there. David's journey has no ★ on purpose: a buyer's veto is continuous, so his map is gates, not stages.
• Map the people who can't file feature requests. Priya's and Tuan's journeys produced the hardest requirements in the SRS; adoption journeys decide whether the product spreads, invisible journeys decide whether it deserves to.