IDST
Course contents

Session 5 of 8

Session 5: Four Gates, a Design Studio & Three Roadmaps

Final session of the planning half. Before a professional project gets money and people, its plan is reviewed by executives who can each send it back. In this session your Shelf Life spec faces four of them, and you sit in all four chairs. Then the design studio, then the delivery plans, one per platform, and by the end of the session: a baselined plan, signed and frozen, that three build sessions cannot wander from.

Part 1: Tune the reviewers (~10 min)

First, run:

/plan-tune

It calibrates how the review skills question you, how often, how hard, how much they trust your defaults. Ten minutes now makes the next hour's conversations fit you instead of a generic user. (Notice the theme: you keep meeting tools that adapt to you. They're all just documents learning.)

Part 2: The four gates (~55 min)

A stage gate is a formal checkpoint: the project may not proceed until a reviewer, looking at real evidence, says it may. Four reviewers, four lenses, run one at a time, and each one is an interactive conversation where you make the final call on every finding:

  1. /plan-ceo-review The founder's lens: is this worth building at all? Is the smallest version being built first? What would make you abandon it?

  2. /plan-eng-review The engineering manager's lens: is it technically sound? What's risky? What's secretly two features? (Your marked-up homework list belongs in this conversation, and expect the shared data model to take fire.)

  3. /plan-design-review The designer's lens: will a human enjoy using this? What's confusing on a 6-inch screen at 7am in front of an open fridge, and does the web page feel like the same product?

  4. /plan-devex-review The developer-experience lens: will this be pleasant to build and change? Is anything about the plan going to fight the person (and agent) doing the work?

These four chairs should feel familiar: on Session 2, /autoplan convened exactly this board for you, automatically, in minutes, for a slice. That was the right tool then, because slice-sized stakes suit a delegated reviewer. In this session the stakes are three platforms and three build sessions, so the delegation runs the other way: you sit in every chair yourself. Small stakes get the automated board; capstones get the manual one. Knowing which is which is the actual skill.

Each gate produces findings. Sort every one into three piles, the same triage from Session 1, now with stakes: accept (change the plan), defer (note it for later, out loud), or reject (disagree, with a reason). A reviewer told to find problems will find problems, always, even in a sound plan. The judgement about which findings matter is the actual skill, and nobody can outsource it, not even to the reviewer.

Record each gate's outcome on the stage-gate checklist: what was reviewed, what was decided, your sign-off. Yes, actually fill it in. The ritual is the point, those four signatures are what "this project was reviewed" actually means in industry.

Part 3: The design studio (~30 min)

Waterfall designs before it builds, all of it, now, while change is cheap.

/design-consultation

It studies what Shelf Life is for, researches the landscape, and proposes a complete design system: colours, typography, spacing, motion, with previews you can react to. One system, two homes: the same colours and type must work on a phone screen and in a browser, because a household seeing two different-looking Shelf Lives will trust neither. You're not asked to be a designer; you're asked to choose, which is a different skill and one you already have.

Then the architecture goes on paper, a new tool for a bigger project:

/diagram, draw Shelf Life's structure: the iPhone app, the web page, the shared database, and what flows between them.

Three boxes and a database. That diagram is a formal deliverable, filed with the spec, and for the first time this course, the picture has arrows between platforms, which is exactly why it needs drawing. (Professionals draw before building for the same reason you sketch a lab setup before running it: the drawing is where the collision happens cheaply.)

Part 4: Three roadmaps (~20 min)

A spec says what; a roadmap says in what order. One product, three platforms, so three delivery plans. Ask Claude:

Draft a delivery roadmap for each platform from the baselined spec: plans/roadmap-ios.md, plans/roadmap-web.md, plans/roadmap-backend.md. Each roadmap is 3–4 stages; each stage is one session of building with a named QA check at the end.

Read each one against the spec, stages that are secretly two sessions get split now, not discovered later. Then the decision that makes three roadmaps one project, sequencing:

  1. Session 6, iOS first, local-first. The app works entirely on the phone before any cloud exists. Hardest platform, most new ground, gets the most runway.
  2. Week 3, backend, then web, then wiring. The database goes up, the web page reads and writes it, then the phone app joins the party. Each piece verified before the next depends on it.
  3. Week 4, the test gate. Everything, proven together, formally.

Record the sequencing on the stage-gate checklist. This is the part of in this session most like real engineering management: nothing here is code, and everything here determines whether the code lands.

Part 5: Baseline (~10 min)

Commit everything, spec, gate checklist with four sign-offs, design system, diagram, three roadmaps, as one commit. Ask Claude to label it plan-baseline.

That word matters: from this commit on, the plan is frozen. The build (starting the next session) implements this, exactly. If reality disagrees with the plan, it will, once, at least, we don't quietly edit the plan; we raise an exception and decide formally. That discipline sounds heavy. The build sessions are where you see what it buys.

/context-save, and stop there. The planning half is over: five sessions, two products live, one capstone fully planned. Sessions 6 to 8 are the build, and the solo work between they are where most of the capstone actually gets made, which is why those three want a gap either side rather than a packed diary.

What you just learned without noticing

Governance and release planning. Stage gates, multi-perspective review, findings triage, sign-offs, baselining, and phased delivery across platforms: this is how regulated industries (medicines, aviation, banking) decide software is allowed to proceed. You ran a miniature of the real thing, and you were the review board.