Q&A
What's the biggest mistake people make writing a PRD?
Short answer
The biggest mistake is writing a PRD as a long feature list without stating the outcome you're chasing. Teams end up busy building features instead of solving user problems. A good PRD starts with the problem and success metrics, then works down to features. AI speeds up the draft, but outcome clarity stays the PM's job, not the tool's.
I've been writing and reviewing PRDs since I was a junior product manager at Tokopedia, and now I lead four product teams at a superapp in the MENA region. The mistake I keep running into, in my own teams and in other people's, is always the same: the PRD is just a list of features.
The format looks fine. There's a title, background, mockups. But ask what problem a feature solves and how you'll know it worked, and most people stumble. The features are clear. The outcome is blank.
The damage shows up later. A team spends weeks building a long list of features, and the core metric doesn't move. Dig into it, and half those features were nice-to-haves that never connected to the real user problem. I saw this firsthand leading the identity and family authentication platform at Tokopedia: the first draft of the PRD was a wall of technical requirements. I pushed the team to answer one question first: if we ship all of this, what number changes? The list got cut hard, and what survived was the stuff that actually moved the metric we cared about.
Now I always open a PRD with three things before touching a single feature:
- The specific problem the user has, not what the team assumes it is.
- The metric that should move, and where it sits right now.
- Why this needs to happen now, not next month.
Features come after, as answers to those three questions, not as a pile of stakeholder wishes stacked on top of each other.
AI has made the writing part of a PRD much faster. I use it to draft the document, structure sections, and check that different parts don't contradict each other. But that only speeds up the writing, not the thinking about outcomes. AI can't guess which metric matters for your business or which user problem hurts the most. That's still the PM's job. Feed it a brief that's just a feature list, and you'll get a polished PRD that's wrong at the root.
So if you're about to write a PRD, don't open the document with a feature title. Open it with one sentence: what is this problem costing the user, and what number am I trying to move.
If you want to learn how to use AI to move faster on product work without losing that judgment, check out AI Circle.