How to Prioritize Product Features Before Writing a PRD

On the AI-First CRM for pharma reps, the initial feature list had somewhere around twenty features - voice logging, offline sync, physician deduping, compliance flags, an assistant, an audit trail, and more. Every one was defensible in isolation. The team could not build all of them.

One of those was a compliance flag system. An engineer had already started sketching a database schema for it before I remembered we had no compliance requirements in v1. I had written it on the list because it sounded right, not because anyone had asked for it.

Prioritization frameworks are easy to name and hard to actually use. RICE gives you a spreadsheet. It does not tell you which cells were guesses and which were evidence. Left alone, the framework rewards whoever writes the confidence column with the most nerve.

I wanted a habit that made the disagreement visible before it made it into the PRD.

Shape Up changed what I did in practice. Specifically the 'appetite' concept - you decide how much time something is worth before you estimate it. That reordering sounds small. It isn't. It forces a scope conversation instead of an estimate, which is a completely different meeting.

I also kept the discipline of writing a number from RICE - not for precision, but for commitment. Writing down an estimate forces you to have an opinion, which is the thing most feature discussions are quietly avoiding.

I now run a one-page check before I open the PRD template. Four columns for every candidate feature.

• User commitment: the specific behaviour I'm asking a user to change or adopt. If I can't name it, the feature is cut.
• Evidence class: what I actually know - interview quote, analytics, competitor benchmark, or hunch. Hunches are allowed, but they get labelled honestly.
• Appetite: time the feature is worth, decided before we estimate. If the estimate exceeds appetite, we shrink scope, not schedule.
• Kill signal: the metric or observation that would make me drop it after launch.

The kill signal column was one I added two weeks into using this, after I realised five items had no exit condition. I didn't start with it. I added it after keeping a feature I later regretted.

On the CRM, that page cut the list down to six before the PRD started. Three of the cuts were mine. Two were painful. One was a feature I had already told an engineer we'd build, which cost me a phone call I did not enjoy making.

The v1 CRM shipped with six features. Two more were added in the second cycle after real usage - one that hadn't been on the pre-PRD at all, one that had been cut and came back with actual evidence behind it. Nothing that shipped in v1 got removed. That's the metric I care about: not a perfect roadmap, but no regrettable builds.

The hardest habit is being honest in the evidence column when I'm the one who wants the feature. I still catch myself inflating a hunch to 'preliminary research.' The mitigation is a peer: I ask an engineer or a fellow builder to read the page and only comment on the evidence column. It takes fifteen minutes and saves weeks.

If I started the CRM again, I'd run the pre-PRD before the first stakeholder meeting instead of after. The list of twenty-odd features was itself a symptom - a sign I had absorbed everyone's wishes without weighing any of them.