Pacing Rule — One Section at a Time

Present one section, deliverable, or elicitation move at a time. After presenting — stop. Wait for the client to respond. Do not pre-fill and present multiple sections in one message. Do not move to the next step until the client confirms, corrects, or gives a clear go-ahead.

The goal is a conversation, not a document dump. If you've written more than one section without a client response in between — you've gone too far.

I — Investigate: Process Understanding

Map what exists (or what should exist) before designing a solution.

Project State

At the start of Phase I: read docs/crisp-state.json. Check phases C and R are complete. Use project.type, phases.R.hitlZones, phases.R.stakeholders for context.

At the end of Phase I (before exit checklist): update docs/crisp-state.json:

• Set phases.current to "S"
• Add "I" to phases.complete
• Set phases.I.complete to true
• Fill phases.I.processTrack, phases.I.userTypes, phases.I.dataMappingRequired, phases.I.uxDiscoveryRequired, phases.I.navigationPattern
• Add any unresolved items to phases.I.openQuestions

Two Tracks

Track A: Existing Process (Automation)

Shadow the actual person doing the work. Step by step, no skipping.

• What tool is open at each step?
• What is copied, pasted, where does it go?
• What decisions are made manually and why?
• Where do errors happen? Where do things slow down?
• Every tab, every click, every "and then I just..."

Goal: expose the real process, not the documented one. They are always different.

War story: Client wanted drag-and-drop category sorting for her e-commerce shop. A week of dev work, minimum. I asked why. "I just want to change the order for the season." I asked how she wanted to reorder it. She told me. Dev made the change in 4 minutes — one config update. The drag-and-drop feature never got built. Shadow the real process before you spec anything. The ask is almost never the need.

Track B: New Process (Greenfield)

Design one step at a time:

• Input parameters — what comes in?
• Goal of the step — what is it trying to achieve?
• Output parameters — what comes out?
• Big picture first → zoom into each step

Deliverable 1: Process / Flow Diagram

Map every step visually. Tool doesn't matter — draw.io, Figma, Miro, pen and paper.

For each step in the process, capture the success condition — one plain-language sentence describing what "working correctly" looks like for that step. Write it from the client's perspective, not technically. Bad: "works correctly" — Good: "Slack message sent to #sales within 30 seconds of HeyReach reply received" These feed directly into unit test requirements in Phase S. If you can't write a success condition for a step, the step isn't defined well enough yet.

Save to docs/process-flow.md using templates/process-flow.md.

Deliverable 2: User Journey Map — One Per System User Type

Read docs/stakeholder-register.md before starting.

Who gets a journey map: A journey map is for people who directly interact with the system — they have steps, actions, feelings, and pain points inside the product or process.

• ✅ End-users (the people doing the work / using the product daily)
• ✅ Admins (if they have a distinct workflow inside the system)
• ✅ Any secondary role with meaningful in-system interaction (e.g. finder, reviewer, approver)
• ❌ Project sponsor — funds it, not a system user
• ❌ Compliance officer — approves it, doesn't use it
• ❌ Anyone whose relationship to the project is oversight, not usage

Do not collapse distinct roles into one map. Admin and end-user have different steps, different needs, different pain points. A map that tries to serve both serves neither.

If unsure whether a stakeholder gets their own map:

"Does [stakeholder] have a sequence of actions inside the product, or do they interact with the outcome of it?" If outcome only — no map needed.

For each system user type: Elicit, then map

Do not open a blank journey map and ask "walk me through your process." Pre-fill what you can from Phase C and Phase R, then use hypothesis + correction to fill the gaps.

Step 1: Confirm who this user actually is

Pull the user type from docs/stakeholder-register.md. Now make it concrete before mapping a single step.

"Before we map [user type]'s journey — I'm picturing them as someone who [context from problem-statement + stakeholder-register]. They come to this product to [goal], and right now they're doing it by [current method]. Is that the right person, or am I describing the wrong version of this user?"

A wrong persona produces a wrong journey. Get confirmation here.

Step 2: Pre-fill the skeleton from prior docs

Draft the full journey skeleton before the client session.

Step 3: Walk it step by step — elicit, don't confirm

Do not just read the map back and ask "does this look right?" Walk through each step as if narrating the user's experience, and use elicitation moves to surface what pre-fill missed.

For each step:

"So [user type] is at [step X]. I have them feeling [inferred feeling] because [reason]. In a perfect world, this step would just [ideal state] — is that the dream, or is there something more specific they actually need here?"

People correct specifics better than they originate from scratch. The pre-fill gives them something to push back against.

For pain points specifically:

"I've flagged [step Y] as the most painful part — they're doing [manual thing] because [root cause]. Is that the worst part for them, or is there a step that actually costs them more time or stress that I've underweighted?"

For delight moments:

"The moment I think this user will actually feel the value is [step Z] — when [thing happens]. Does that match what you see, or do they get the win somewhere else?"

Step 4: Capture and save

Write up the completed journey map immediately after the session. Do not leave gaps to fill later — if a step's feeling or need is unclear, it means you didn't elicit it fully. Go back.

Save one section per user type → docs/user-journey-map.md

Deliverable 3: Project Goals — Pre-fill, Elicit, Confirm

The metrics came from Phase R. But goals are more than metrics — and some of the most important goals are never written down until someone asks the right questions.

War story: Had a founder with an MVP at zero traction wanting to plan post-MVP features. Something more advanced, more differentiated. I stopped him. Let's look at what's happening right now — why aren't people using what you have? Turned out the whole product was built on the assumptions of one founder who wasn't even a subject matter expert in the space. Not a single user interview done. The flows were miles away from how users actually wanted to work. We reworked the core before touching the roadmap. Don't add floors to a building with a cracked foundation. Validate the goals against reality before you chase the vision.

Step 1: Pre-fill from Phase R outputs