SpeqForgeThe Hidden Cost Nobody Talks About
Ask a product manager how they spend their time and they'll say things like: customer discovery, stakeholder alignment, roadmap planning. Ask them to open their calendar for the last two weeks and you'll see something different.
A significant chunk of PM time, often 30 to 50 percent by our informal surveys, goes to what you could broadly call document production. Writing specs, updating docs, reformatting feedback summaries, preparing planning decks, drafting acceptance criteria. This is the unglamorous connective tissue of product work, and it's massively underacknowledged as a time sink.
Running the Numbers
Let's make this concrete. Imagine a PM at a 40-person SaaS company. They manage a backlog of roughly 60 active items. Each sprint, 8 to 10 items need full specs. Writing a good spec (reading the relevant feedback, synthesising it, writing the story, defining acceptance criteria, estimating effort, getting stakeholder review) takes anywhere from 45 minutes to 2 hours per item.
Call it 90 minutes average, 9 items per sprint, two-week sprint. That's 13.5 hours per sprint, or nearly 28 hours per month, just on spec writing. Out of roughly 160 working hours, that's 17 percent of total capacity gone before you've done a single customer interview.
Add quarterly roadmap decks (8 to 12 hours), feedback triage (4 to 6 hours per week), and stakeholder update summaries (2 to 3 hours per week), and you can easily hit 40 to 50 percent of total working time spent on document production rather than discovery, strategy, or actual decision-making.
Why This Matters More Than People Realise
The obvious problem is capacity. PMs who are drowning in docs can't do customer interviews, can't think deeply about strategy, can't build the cross-functional relationships that make product orgs work well.
The less obvious problem is quality. Spec writing done under time pressure is spec writing done badly. When you have 90 minutes to turn feedback into a spec before your planning meeting, you write from memory. You skip the synthesis. You write vague acceptance criteria because figuring out the specific ones would take too long. The spec looks complete but leaves too many questions for engineers to resolve on their own.
Poor specs generate engineering questions during the sprint, which means more PM time answering Slack messages, which crowds out even more of the work that matters.
What Actually Moves the Needle
The highest-leverage change is not asking PMs to work faster or be more organised. It's reducing the time cost of synthesis. If going from raw feedback to a structured spec takes 15 minutes instead of 90, a PM can process the same volume in a fraction of the time. Or more usefully, they can process more feedback with the same time, which improves the quality and coverage of the backlog.
The second highest-leverage change is standardisation. A consistent spec format (user story, acceptance criteria, effort estimate, evidence quote) takes the decision-making out of the writing. You're not deciding what to include each time, you're filling in a template. Consistency also makes specs faster to review, reducing stakeholder revision cycles.
These two changes alone, faster synthesis and consistent format, can realistically cut spec production time by 60 to 70 percent. That's 10 to 15 hours per sprint returned to discovery, strategy, and the work that actually requires human judgment.
The Metric Worth Tracking
If you want to make the case to leadership that this matters, track "time from feedback to spec" as an explicit metric. Most product orgs have no idea what this number is. Once you measure it, the opportunity for improvement becomes obvious, and the investment in tools or process changes that reduce it becomes easy to justify.