Product Managers Are Not Typists: The Documentation Burden Is Real

The Job Description vs. The Actual Job

Ask a product manager what their job is and you’ll hear things like: understanding users, identifying opportunities, making trade-offs, aligning stakeholders, defining strategy. Important, high-judgment work.

Now ask that same PM how they spent their Tuesday. The answer is usually some version of: “I was in Confluence all day writing up the spec for the notifications feature.”

There’s a gap between what PMs are supposed to do and what they actually spend their hours on. A big chunk of that gap is documentation.

The Documentation Tax

I’ve talked to dozens of PMs about their workflows. The pattern is consistent. They spend 4 to 6 hours on a single PRD. Not because the thinking takes that long, but because the formatting, the structure, the templates, the cross-linking, the diagrams, the edge case tables, and the stakeholder-specific versions eat up enormous time.

A PM might make the core product decision in 30 minutes: “We need to add team-level permissions because three enterprise prospects asked for it, and here’s how it should work.” That’s the valuable part. The insight. The judgment call.

Then they spend the rest of the day turning that decision into a 12-page document with screenshots, user flow diagrams, a data model section, and an FAQ that nobody will read.

Something’s off.

The Real Value of a PM

The best PMs I’ve worked with share a trait: they’re fast at capturing decisions and slow at making them. They take their time talking to users, studying data, debating trade-offs. But when it’s time to write the spec, they don’t produce a novel. They produce a clear, concise artifact that communicates the decision and moves the team forward.

The worst PM workflows I’ve seen treat the PRD as the deliverable. As if the document IS the work. It’s not. The document is a byproduct of the work. The work is the thinking.

PRDs Are Communication Tools, Not Literature

Here’s a test: if your PRD takes longer to write than the feature takes to build, something is wrong.

A PRD needs to answer a small number of questions clearly:

• What problem are we solving, and for whom?
• What does the solution look like at a high level?
• What are the acceptance criteria?
• What’s out of scope?
• What trade-offs did we make, and why?

That’s it. If an engineer can read your spec in 10 minutes and start building with confidence, the PRD did its job. The length is irrelevant.

Stop Optimizing the Wrong Thing

Teams invest in PRD templates, documentation tools, spec review processes. All of that optimizes the document. Very little of it optimizes the thinking.

What if you could skip the formatting entirely? What if you could have a conversation about the feature, and the spec wrote itself?

That’s the idea behind tools like Projan, which turns a conversation into a structured spec with user stories, acceptance criteria, and technical notes. You talk through what you’re building. It handles the structure. You’re back to doing PM work in minutes instead of hours.

Try it free at app.projan.ai/signup and see how fast a spec can come together when you stop typing and start thinking.

Reclaim Your Time

If you’re a PM reading this, do an honest audit of your week. How many hours went into formatting documents versus talking to users, analyzing data, or making product decisions?

The fix isn’t to stop writing specs. Specs are valuable. The fix is to stop treating them as the primary output of your job. Make them fast. Make them clear. Move on to the work that actually requires your judgment.

Your team doesn’t need a beautiful document. They need a clear decision, communicated quickly. Everything else is overhead.