In this section: Chapters
- Ch.1: The Day After
- Ch.2: Tribal Knowledge Is the Bottleneck
- Ch.3: Contracts Are the Answer
- Ch.4: The Capabilities Graph
- Ch.5: Extraction Over Refactoring
- Ch.6: The Contract Lifecycle
- Ch.7: The Architect
- Ch.8: The Developer
- Ch.9: The PM / PO
- Ch.10: The Designer
- Ch.11: The Leadership Team
- Ch.12: The Company That Gets There First
- Appendix
- Appendix A: Contract Schema Reference
- Appendix B: Legibility Audit Framework
- Appendix C: Extraction Priority Matrix
The PM / PO
Every important decision about a capability gets made in a room. A business rule gets set, a constraint gets named, a whole feature category gets ruled out for reasons the PM understands better than anyone else there, because they're the one who's been talking to the customer for six months. They leave that room holding something nobody else has in the same complete form: not just what gets built, but why it exists and what the team deliberately chose not to do.
Then they open Jira and write a ticket. The ticket says what will be built. It doesn't say what was decided. It can't carry the regulatory constraint that shaped the limit, or the customer whose contract drew the boundary, or the direction the team considered and rejected. Chapter 9 makes the case that this was never a failure of documentation. The ticket, the PRD, the wiki page, none of them were built to hold what a PM actually knows. For years the gap got absorbed quietly, by developers who'd sat in enough meetings to fill in the blanks, by architects who caught the edge cases in review.
Agents don't sit in those meetings. They read the ticket, and only the ticket. Chapter 9 is about what changes when the spec itself becomes the artifact that carries intent, and what it looks like for a PM to write one that an agent can actually be trusted to build from.