What is the purpose of a PRD in your org?
Posted by miianah@reddit | ExperiencedDevs | View on Reddit | 29 comments
I work with a PM who really drags their feet when it comes to writing PRDs. I personally find them valuable so I can feel assured we're building the right thing before investing engineering capacity. I think they disagree and see it as unnecessary process.
Do you use PRDs at your company? What is their purpose? How do they get written and at what stage of the development process does that happen? If you don't use PRDs, how do you know thought has been put into product discovery?
sarcasmguy1@reddit
Out of curiosity, if the PM doesn’t write PRDs, then how do they convey what needs to be built?
We have the opposite problem. We have a PM who loves to write PRDs but spends far too long researching the most simple things and figuring out the UI, leading to PRDs taking far too long and blocking the rest of the process. I’m trying to fix it, but struggling.
wayfaast@reddit
A Jira ticket with no description and 15 teams meetings and 50 Mattermost DMs
Oldmanbabydog@reddit
My PM doesn’t write PRDs or communicate what needs to be built. We (senior engineers) scope out projects with rough ticket stubs, estimate the effort in points, get told it’s too much, cut it into phases, and only ever do phase 1. Ship it and repeat.
miianah@reddit (OP)
what does your PM do
Disastrous_Truck6856@reddit
The company where I work just laid off all the remaining PMs and head of product. We’re going exactly in the same direction now
Oldmanbabydog@reddit
I wish I could answer that. Not a whole lot for our team but always somehow seems stressed and overworked. Don’t know if it’s a well played lie or if he really is stretched on other teams.
khoikkhoikkhoik@reddit
Our PMs just sit around doing jack shit. They aren't part of the delivery process for whatever reason. The senior dev on other team has ownership of the product, fights the UX team and comes up with the most garbage ui designs.
kogitatr@reddit
Vibing bruh, they'll throw ideas and everything then forget it. The feautr/product depth usually shallow and quality usually mediocre. I've seen this in my whole career a lot
miianah@reddit (OP)
slack and meetings. they might have rough doc of the product shape in the beginning, then that gets refined into a real product through slack and meetings
sarcasmguy1@reddit
Sounds healthier imo. This is how I’d like us to work - more rapid iteration. We are a small team and haven’t gone to market fully yet, so spending weeks on PRDs sounds completely silly to me.
There should still be a step where all the conversations and decisions get bolted down as a document. It supports processes downstream far better than ad-hoc calls.
ksceriath@reddit
On the contrary, not having a properly written description often leads to vaguely thought and hand-wavy requirements. This slows down the engineering team more. A coherent document forces the author to be rigorous. This doesn't require spending weeks - that's a different part of process, which is also important, but should happen well in advance before the iteration they are getting planned for.
sarcasmguy1@reddit
I completely agree. I appreciate the thorough documents but like you said, they shouldn’t take weeks. Last development cycle we spent 2 months on PRDs and 1 month on engineering 🙃
kk_red@reddit
Yup same here, we just have meetings with verbal discussion (which we record) and then its just jira title.
Now i cant blame my PM because company is really using the AI scare tactic to make him work on 3 parallel products and srums. Dudes lost most of the time
charging_chinchilla@reddit
generally it's to hash out and agree on product direction for a new feature.
that's all changing now though. it's become clear that the old prd -> eng design doc -> implementation process is way too slow in the age of AI. the product and tech infra landscape is changing every week, so there's no real point to trying to get alignment on a doc since it'll be out of date by the time you're done getting sign-offs. decisions now are just made in quick meetings or chats and then go straight to implementation with the understanding that it'll probably be thrown away and redesigned later.
waba99@reddit
Apparently for engineers to write because we don’t have enough work already and this terrible org doesn’t see a problem with the high attrition rate in product, design and engineering.
Gloomy_Cicada1424@reddit
PRD is useful only if it stops confusion later. Otherwise it’s just corporate homework lol. I sometimes throw rough notes into Runable for a cleaner PRD draft, but someone still has to make the real decisions.
HoratioWobble@reddit
I've been around for 20 years and the only time i've experienced a PRD is now, in a 200 year old company that can't let go of waterfall (not because of the PRD but generally)
bart007345@reddit
Waterfall assumes an initial requirement gathering step followed by design, aren't they similar?
HoratioWobble@reddit
Yes, that's what I mean. I see PRD as very much a waterfall process
bart007345@reddit
The PRD is not meant to cover your whole project but feature by feature so not really waterfall.
martinbean@reddit
At the moment? To feed to Claude.
peaceinmind2002@reddit
PRDs at our org exist for one reason: to force the disagreements to happen before eng starts building, not after.
Without one, "we're aligned" usually means "we haven't argued yet." The PRD is just the artifact that makes the arguing efficient.
A few things that helped us stop fighting about them:
If your PM resists writing them, the real question is what they're optimizing for — speed (fair, sometimes) or avoiding the hard conversations (not fair). Worth asking directly
kaundinya94@reddit
I'm a Product Manager I feel they are absolutely necessary to save our asses for what business has aligned.
Gwolf4@reddit
It would be a great idea to describe what a PRD is. In my country that's Partido Revolucionario Democrático. And I am not searching for it just to enter a conversation.
miianah@reddit (OP)
updated
Montags25@reddit
Our projects go through a shaping phase where they turn from initial idea into a PRD. This is then agreed by product, design and engineering so we know what we are building and why. This will then get broken down into a leaner V1, and we are even exploring a V0 implementation now, as our devops guy has just automated deployed dev builds from any feature branch, opening up the possibility of product vibe coding a feature to get feedback from customers and test assumptions before we even start any design or engineering work.
Otherwise we really like using the grill-me skill from Matt Pocock and the write-a-prd skill. It’s templated out so a PRD will always read the same way. Really useful skill for product to think of all the edge cases and scenarios before handover.
allllusernamestaken@reddit
It's a spectrum.
The best PMs I've worked with would write the big picture then have some back-and-forth with engineering to fill in the finer details based on what's possible, what's feasible, and what's fastest to market. The end result is a document with basically every fleshed out, in detail, so there are few - ideally no - surprises for engineers once they start building it.
The worst PMs I've worked with would document things as they thought of them, usually multiple weeks into the project, or only document things that engineers specifically called out as undefined. Sure there was "process" slowing down the project but the project was slowed down because a PM would drop a surprise requirement on us that would change 60% of our implementation after one of our lawyers said it was a requirement.
xlb250@reddit
My last company had rotational PM’s basically. They didn’t know much about the existing product and just focused on new projects.
I liked it a lot TBH. Spent a lot of time querying data to make low level product decisions. PM reviewed and approved. I got to work directly with finance and business side.
Now I’m working in a more regulated industry and the PM’s are more hands on. They are debating quality vs. speed now, especially as the stock is dropping.
Adept-Watercress-378@reddit
my company, no.
for any project i work on, yes