phase3-investigate

## 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**

| Journey section | Source |
|---|---|
| Core steps | `docs/problem-statement.md` — Phase C process walkthrough; `docs/process-flow.md` — step sequence |
| Needs per step | `docs/problem-statement.md` — desired outcome, ideal state per actor |
| Pain points | Phase C friction inventory; `docs/problem-statement.md` — root cause |
| Feelings | Infer: frustration at friction points, anxiety at decision points, relief at resolution |
| Moments of delight | `docs/value-proposition-canvas.md` — gain creators; what the solution makes easier |

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-fil