CHAPTER 13 / 13 · READ → DECIDE → BUILD
Make the next version better.
Observe the product, learn from failures, and choose the next useful change.
Watch the journey you promised
Monitor signals that tell you whether people can complete the task. For the board, observe claim success, expected conflicts, unexpected failures, and request latency. Avoid logging private task contents when counts and correlation IDs would be enough. An alert should explain user impact, name an owner, and link to a useful diagnostic step. A stream of alerts nobody can act on is not operational readiness.
Leave a path for the next person
Write a runbook with the service purpose, dependencies, release identification, logs, safe diagnostics, common failures, recovery steps, and access owners. Keep credentials elsewhere. Rehearse a simple failure using synthetic data. If an incident happens, preserve a timeline and distinguish confirmed events from hypotheses. Improvements should have concrete completion criteria rather than promises to be more careful.
Close the learning loop
Compare what you built with the original PRD. Did a test user complete the journey? Which support questions or failures repeated? What did the measurements reveal? Choose one next hypothesis and a bounded change. You may learn that a feature should be removed or deferred. Use the relevant library prompt to turn evidence into the next brief, and keep your documents aligned with the product as it actually behaves.
Your project workbook is your handoff
Export your workbook and review it for gaps. It should tell a coherent story from user need to architecture, implementation, checks, and release evidence. Entries marked unverified remain work to do. Course completion acknowledges that you completed the exercises and decisions. Before using the project with real people, resolve material gaps and ask for an experienced review when the stakes warrant it.
SEE THE DIFFERENCE
A small example. A better decision.
We launched. Next, add five more features.
Three test users could claim tasks, but two could not find their claimed task later. The next iteration will add a clear My tasks view and verify that journey.
This is a fictional example of choosing work from observed friction. Use your own evidence rather than copying the example as a real result.
Your build steps
- Define a few signals for the critical journey and their owners.
- Write a runbook another person could follow.
- Compare your evidence with the original outcome and choose one next hypothesis.
- Export the workbook, inspect unresolved gaps, and share only a version free of private data.
FROM THE PROMPT LIBRARY
A useful brief for this step.
Write an actionable service runbook ↗Makes an unfamiliar service operable during a real failure.Design alerts that need action ↗Reduces noise from alerts that nobody can usefully respond to.Investigate a post-release regression ↗Connects changed behavior to evidence from the actual rollout.All operations & iteration promptsMAKE THE CALL
Think like the reviewer.
BUILD YOUR WORKBOOK
A runbook and next-iteration brief
Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.
Before moving on
Loading your workbook…