Automating the Paperwork So I Could Focus on the Product
Automating the Paperwork So I Could Focus on the Product
Ask any Product Owner what eats their week, and somewhere near the top of the list is documentation.
Not the thinking, the thinking is the fun part - but the writing-it-down-properly part: the PRD that needs every section filled in, the user stories that need to actually satisfy INVEST, the acceptance criteria that QA won't send back with "what happens if this field is empty?"
So I built PM Copilot, an AI workflow that does the first draft of that paperwork for me.
You feed it three things: a feature idea, the customer problem behind it, and the business goal it's meant to serve. From there, it routes to one of several specialized paths depending on what you actually need:
A full PRD — Problem Statement, Background, Stakeholders and Dependencies, Scope (split into MVP, V1, and Nice-to-Have), Personas, Success Metrics, Compliance considerations, Risks, and a Release Plan. Every assumption it makes is flagged explicitly, so nothing invented sneaks in disguised as fact.
User stories — written to genuinely satisfy INVEST, not just formatted like they do. If a capability is too big to be one clean story, it splits it and explains why, rather than writing one bloated story that looks tidy but isn't testable.
Acceptance criteria — the exhaustive, QA-ready version: Given/When/Then scenarios covering the happy path, error handling, boundary conditions, and permissions, grouped under plain-language headers instead of generic "happy path / negative path" labels.
A general PM Q&A mode — for when I just want a second opinion on a tradeoff, reasoned through rather than answered with a textbook framework.
It's not the drafting. Plenty of tools can draft.
It's that the system does its own internal scoping before it writes anything user-facing.
For user stories and acceptance criteria, there's a hidden reasoning step first: break the feature into its real components, note who else might be affected, flag compliance or performance concerns, and only then write the polished output, grounded in that thinking instead of freelancing from the prompt alone.
It mirrors, honestly, how I try to work as a PO: think before you draft, and don't let the final document hide the reasoning that produced it.
Partly to save myself time. But mostly because writing PRDs and stories, over and over, taught me exactly which parts are pattern and which parts require real judgment.
Automating the pattern was the only way to see the boundary clearly, and it's made me faster and more precise at the parts that still need a human in the loop.