Tutor notes. For the person running the sessions.
Session 4: tutor notes
Objective: they leave with an interrogated business case, a locked, committed spec for multi-platform Shelf Life, and a lean CLAUDE.md, and the belief that deciding-before-building is a power move, not paperwork. This is the session where your 25 years earn their keep: it's a PRINCE2 project initiation wearing casual clothes.
Timings (2h)
| Time | Segment |
|---|---|
| 0:00 | Homework review, them "couldn't slice it" answer opens the cliff |
| 0:10 | Complexity cliff, map THEIR wrongs lists to lifecycle stages |
| 0:25 | /office-hours, the business case |
| 0:45 | Initiation: repo, CLAUDE.md exercise (your 4-liner as exhibit A) |
| 1:00 | /spec, the interview (the main event; don't rush it) |
| 1:55 | Commit, /context-save, tee up the gates |
PM-to-PM framing (keep it under the surface with them)
This session is business case + initiation + requirements: /office-hours is their business case interrogation, and the spec is their PID and requirements baseline in one document. The next session is the end-stage assessment before build. Use the vocabulary freely in your own head and sparingly out loud, "business case", "baseline" and "out of scope" are worth saying; "product breakdown structure" is not. The waterfall arc exists so they feels stage discipline once, every gate honest, every deliverable real, and after two sessions of agile they have the contrast fresh: they know what formality costs, so they can see what it buys.
The business case beat
Let /office-hours be the bad cop; you watch. The pitch is Shelf Life, so the stakes are different from a free-choice pitch: the investor's job here is to make them own the why, who it's for, why it needs both a phone app and a web page, what gets cut first if it must shrink. Intervene only if the questioning talks them out of the multi-platform shape entirely (that shape IS the syllabus for the rest of the course). Name the rhyme when it lands: "same interview as /spec on Session 2, different hat."
Why the multi-stack capstone gets waterfall
Three honest reasons, share them if asked: (1) three platforms against one shared data model is exactly the "agree before anyone builds" situation waterfall exists for, a wrong table design gets built on top of three times; (2) the phone in their pocket makes "shipped" visceral in a way a URL now isn't; (3) they're lived the other side, the fast web loop of sessions 2–3 rewarded iteration; iOS's slower build-test loop and a multi-platform plan reward deciding up front. The course's two stacks each argue for their lifecycle, and now they're heard both arguments in consecutive sessions.
The CLAUDE.md exercise
Show your real 4-liner, then a deliberately awful 80-line anti-example (write it in advance, file-by-file descriptions, "write clean code", stale instructions). Ask which one the agent will actually obey. Their first draft will include things the agent can read from the code, apply the deletion test line by line, together.
Running /spec well
- Let the skill do the interviewing: resist answering for them. Your job is to occasionally veto scope creep ("barcode scanner → out of scope") and to name what's happening: "it's asking because otherwise it would guess, and you'd meet the guess in the final build session as a bug."
- Steer the shape: 3 iOS screens max (list, add/edit, maybe settings), one web page (the household view), one shared table, one notification feature on the phone only. Exactly one cloud decision: the shared database (Supabase, anon keys only, but don't teach it in this session; it's a final-build-session build detail, not a Session 4 spec detail). No accounts, no photos, no barcode scanner. If the spec grows past that, the build won't fit in the build sessions and the final gate will fail, which is a worse lesson than a tight scope.
- The data model is the hill. Make them decide the table's columns in this session, out loud, name, expiry date, category?, added-by? Every column they wave through is a guess three platforms inherit. This is the session's version of reading the spec aloud.
- Alternatives if Shelf Life doesn't land: Revision Timer (study timer on the phone, weekly totals on a web page, shared session log) or Plant Nanny (watering schedule + notifications, household plant list on the web). Same shape: app + page + one shared table. Decide in this session; spec-shopping across sessions breaks the arc.
- Have their read the final spec aloud, section by section. Reading aloud catches what skimming doesn't, and it makes the baseline feel signed.
Sticking points
- "Can't we just sprint it?": they asked this last session if the turn landed; answer it properly now: "which slice would you ship first, the app, the page, or the database? Whatever you pick, the other two have already been decided by it. That decision is the waterfall part." Then the honest experiment framing: two lifecycles down, one to go; by the end they'll have earned an opinion on all three.
- Spec fatigue at the 40-minute mark. Break, tea, then finish. Don't let the last sections get waved through, the notification details they rushes in this session are the final build session's bug.
- They want to change a decision after the commit. Perfect, that's the next session's teaching moment about baselines and change control. Note it, don't edit it.