Hours and hours spent trying to make it work. So much effort, love and devotion put forth without any meaningful recognition. In the end, it turns out the person across from you doesn’t care, or even really notice. Weeks—sometimes months—wasted. And for what?
No, I’m not describing a bad relationship. I’m describing the work product managers put into product requirement documents, or PRDs—and it’s the essence of product management done wrong.
You may have had flings with PRDs before, and if so, you know firsthand how much of your time is dedicated to a project that just doesn’t seem worth it—especially when you present to management and they hardly pay attention, let alone read your cross-referenced notes.
But fear not, it’s possible to change. And there’s a better way.
Make Your Time Count
The truth is, when considering return on your time investment, PRDs are simply not worth it. The finished product is inevitably dense, sometimes to the point of being inscrutable. In a fast-moving, Agile world, it’s unreasonable to expect your fellow product managers—let alone your engineering team—to read a 50+ page document outlining unvalidated market needs.
In fact, we just had a chat with Satya Patel of Homebrew where he mentioned his experience writing 150-page PRDs, and listed it among “all the things you shouldn’t do”. (Skip to the 1 minute mark to hear his take!)
Besides, according to Jonathan Rosenberg and Eric Schmidt, your coworkers need to hear something about 10 times before it sinks in anyways. And they sure won’t read your PRD 10 times.
Instead, spend your time actually validating your hypotheses. Try to spend those weeks of work engaging with customers, prospects, and industry leaders rather than writing a novel. You will know your buyer and user personas better, and will be better able to articulate the specifics of the problem you’re solving. This will serve you and your team much better in the long run.
Hold On to the Good Parts
Of course, PRDs are not entirely without merit—and you’ll still need to communicate requirements and intent to your team. Don’t worry, this doesn’t mean you have to suffer through another bad PRD fling. There is a better way!
Instead of writing lengthy PRDs, some of the best product managers we know break these long reads into smaller pieces that their teams are exposed to over and over. A shorter message is easier to review and retain, making life easier for the author and consumer of this content.
This breakdown is often done at the feature or use case level, where the problem and deliverable are both complete and recognizable. These features can then be worked on immediately, or prioritized in your backlog and grouped logically for a future release. Taken together, these features make up what would otherwise be a PRD but can be delivered in a steady drip, depending on the pace of your development team.
Ultimately, if your communication doesn’t look like a social media post, you shouldn’t be shocked when nobody gets the message. So for your own sake, get out of that bad PRD relationship and please, stop the madness.
What's your approach to documenting & sharing product requirements? Let us know in the comments or @thewizeline.