🔥 Hot Take Alert #1: PRDs are the worst way to drive product progress
Also: Achieving an important milestone, hearing from the community, and why Product Briefs are your best friend.
Welcome to my first 🔥 Hot Take Alert 🔥 post. I plan on doing these a few times a month or maybe weekly if I have enough opinions. I don’t expect you to agree with all of them but please keep an open mind. Or don’t. It’s your subscription.
In today’s newsletter:
Achieving an important milestone.
What I’ve learned about my subscribers in <1 week.
🔥 Hot Take 🔥
Achieving an Important Milestone
So yesterday this happened. My pal Lenny (LennysNewsletter.com) was kind enough to mention my newsletter on Twitter. It only cost me like $20 too which is a hell of a deal.
Then, this happened…
I did four things within this moment:
Had a little bit of a freakout. I now have over
1,0001,200 people to write for/with/to every week. But I also love this accountability and hearing from you all has been amazing. Excited to keep going on this journey together.Thanked Lenny profusely. I was growing pretty well before his plug, but then the line went vertical. Thank you again Lenny. You really are the 🐐.
Decided it was time to get organized with this newsletter. I think that will be a journey as well.
I also wrote my 1,000th subscriber (congrats Yael from Vimeo) and offered her a free prize for helping us hit that milestone!
What I’ve Learned About You in <1 Week
With each subscription to the FishmanAF Newsletter (subscribe please) I ask the subscriber to write back and tell me about themselves, how they found out about the newsletter, and what they’re hoping to learn.
If and when people respond I write them back and ask a few follow-ups. I make sure to ask subscribers if they have a particular challenge they’re wrestling with that they’d like to see me write about. It helps me understand what’s top of mind for people in Product, Growth, company building, and parenthood.
The responses have been diverse and incredible. You all are working through fantastic challenges — from narrative development, getting started in your career, and managing leaders to leading teams, building strategy, and experiencing parenthood while running a startup.
What was most fun was connecting with each of you. Newsletter subscribers run the gamut of experiences: a friend from my childhood who is now a product manager in Detroit to CPOs in Singapore.
What does all this mean? It means that each week when I put something new out into the world it might not be exactly what you want it to be. I think that’s okay and I’ll do my best to cover a wide range of topics that interest me. I expect this newsletter to be around for awhile and hope you will be too.
Now, on to the hot take.
Hot take: PRDs are the worst way to drive product progress
The PRD, or the Product Requirements Document is a way to communicate about the product that you and your team are going to build.
Atlassian (makers of JIRA) sums it up best:
A product requirements document (PRD) defines the requirements of a particular product, including the product’s purpose, features, functionality, and behavior. It serves as a guide for business and technical teams to help build, launch, or market the product.
And I think most people agree that a gigantic, rambling document isn’t an artifact that anyone loves. The problem is that people still use them. Far too many in fact. By taking a kitchen-sink approach to describing features and functionality we lose the art (and the collaboration) of product building. In an attempt to cover all the bases we end up being overly prescriptive and waterfall-y which then hurts the autonomy and motivation of our team.
As Jeff Dwyer (former VPE at EZCater) says:
Every time someone says "requirements" an angel loses its wings.
Seriously, I detract 10 points if I'm interviewing someone and they say the r word.
Now you might think “Ok Adam, I get it. You’re trashing PRDs but offering no alternative…”
The alternative - a Product Brief
The Product Brief is an improvement on the PRD as a communication and context-setting tool. It is a living document that leaves room for inquiry and dialogue thereby improving collaboration and team empowerment.
Here are the elements of a strong Product Brief — and I’ll include a downloadable template at the end.
Keep it short.
You may also have heard this referred to as the “Product 1-Pager.” I think the optimal length is somewhere between 1-2 pages with additional appendix for the lean-in experience. That doesn’t mean it can’t be longer but it does mean you’ll guarantee almost no one reads the entirety of the document. So tread lightly here and continue to refine it down to a few pages.
The “what” and the “why.”
Start here. Your “what” should be a short, 1-2 sentence description of the product that explains it as simply as possible.
Your “why” should articulate both the user problem(s) that you’re solving and the strategic context in which you’re operating.
Overview of the Feature or Product
Here you communicate what the ideal end state looks like. You can follow it up with a visual example and a couple of scenarios in the event that you’re dealing with a more complex product. This helps your designers and engineers identify edge cases and better collaborate on building the product.
Launch Plan & Success Metrics
Provide a high-level overview of your launch plan. This includes some indication of timing and go-to-market. You can fill this in with collaboration (there that word is again) from your marketing, product marketing, customer success, and support teams. This will also help your product team understand the sequencing of work and start to build their understanding of what is high priority to achieve.
Competitive / Alternatives / Risks
This section includes what other competitors are doing within the same feature set as well as non-competitor alternatives that still represent competition for your user’s mindshare. For example, if I’m building a feature at Netflix I would highlight how that feature works at Amazon or Disney and also why a user might browse TikTok instead of using this feature.
You can also highlight potential risks in your approach in this section.
Appendix-level Information
Include as much information as you want in the appendix, but consider it supporting documentation and not primary information. Items to include:
Full set of user and competitive research
Financial modeling
Wonky topics that most people aren’t interested in
Detailed risk assessment
Internal FAQs
Additional mockups and how you arrived at certain decisions
Download a sample Product Brief template here:
Agree! Overly verbose PRDs aren’t much use but what I’m struggling to understand is what comes after the product brief? At some point in the development of a feature you need to get more specific than the high level details contained in a product brief, genuinely curious how and where you document that sort of detail?
Love this.