The Product Manager Persona
Stories, criteria, and scope
The PM persona takes the approved PRD and produces a prioritised set of user stories, each with explicit acceptance criteria covering both success and failure paths. A story without complete AC is not ready for implementation.
The PM persona is activated after the BA's PRD has been reviewed and approved. Its inputs are the PRD and any additional context about priorities or stakeholder preferences. Its outputs are user stories: short, verifiable descriptions of functionality from the user's perspective, each paired with acceptance criteria that describe exactly what done looks like.
The critical quality requirement is that stories cover failure paths, not just happy paths. An AI implementing a story with no failure criteria will invent handling for empty inputs, network errors, and edge cases — and it may invent it incorrectly. The PM persona is responsible for making those paths explicit before any implementation begins. If a story's acceptance criteria cannot tell you when the story has failed, it is not ready.
Stories should be sized for a single AI session: small enough to implement and verify in one pass, large enough to deliver something testable. The PM prioritises against the constraint set from the PRD, not against an ideal wish list. Stories that fall outside the PRD's scope are either deferred or become new PRDs — they do not expand the current artifact chain.
Key Concepts
- Stories sized for a single AI implementation session — one story, one session
- Acceptance criteria must cover failure paths, not just happy paths
- Prioritisation against PRD constraints, not an ideal wish list
- Stories outside PRD scope are deferred — they do not expand the current chain
- PM does not make architecture decisions — those belong to the Architect