AI-Augmented Product Management Operations

Challenge

PRD authoring consumed a disproportionate share of product managers' time, and most of it was not the thinking — it was the assembly. Gathering context scattered across prior documents, restating background a reader needs, formatting to the house template, and reconciling terminology across teams.

The first wave of individual LLM use made this unevenly better. Some PMs got large speedups; others got confident, plausible drafts that were wrong in ways that took longer to correct than writing from scratch. The difference was not the model. It was that everyone was improvising their own prompting, with no shared notion of what good input looked like.

An unreliable tool that is fast is worse than a slow reliable one, because you cannot tell in advance which kind of output you got.

Approach

Target assembly, not judgment. The valuable part of a PRD is the product thinking — the tradeoffs, the scope calls, the things deliberately not built. That is the PM's job and delegating it produces confident, generic documents. The target was everything around it.

Make grounding mandatory. The wrong-output failures traced almost entirely to drafting without source material. Frameworks that required real inputs — existing docs, actual data, real constraints — produced drafts worth editing. Frameworks that let a model invent context produced fiction.

Build reusable frameworks, not one-off prompts. A prompt that works once is a trick. We built structured, parameterized frameworks that encoded what context a given document type requires, so quality did not depend on individual prompting skill.

Keep the PM accountable for every claim. A drafted number is a claim the PM signs their name to. The workflow requires verification against source before anything ships — the same guardrail that governs this site's own content.

Solution

1. Document-type frameworks for PRDs, BRDs, and stack-ranking, each specifying required grounding inputs.
2. Context assembly patterns for pulling prior art and constraints into a draft.
3. Agentic pipelines using Claude Code and MCP servers to connect the drafting workflow to real project data instead of pasted fragments.
4. A verification step where every generated claim is checked against source.

Results

• PRD authoring cycle time fell 27% across the team — a team-wide result, not a power-user result, which was the actual goal.
• Consistency improved. Shared frameworks meant documents arrived in a predictable shape, which sped up review as much as drafting.
• Time reallocated to product thinking — the tradeoff analysis and scope decisions that the tooling deliberately does not touch.

What I'd carry forward

The result that generalizes is that the win came from constraining the tool, not from applying it more broadly. The instinct is to point an LLM at as much of the job as possible. The frameworks that worked did the opposite: they were narrow, demanded real grounding, and refused to draft when context was missing.

Insisting on team-wide rather than individual improvement also changed what we built. Optimizing for the PMs already good at prompting would have produced sharper tools with worse aggregate outcomes.