Welcome to No BS Product Management, your weekly guide to mastering the product management journey—from breaking into the role to crushing it as a PM. Every week, I share straightforward advice, actionable tips, and proven strategies to navigate tough situations, win over stakeholders, and elevate your PM skills.
If you’re ready to stop guessing and start thriving in the world of product management, hit that subscribe button now! 🚀
Writing a PRD can sometimes feel mechanical. Many PMs start with a template and fill it out as if it’s a checklist: "Onboarding? Okay, we need a progress bar, some user flows, and something about reducing friction." Then there’s a vague section about "why this is important," but it often feels disconnected from what’s being built.
The result is a PRD that’s full of features but fails to inspire. It doesn’t convince stakeholders of the urgency, it doesn’t rally the team, and—most importantly—it doesn’t make the reader feel the connection between the problem, the solution, and the value it delivers.
If you’ve felt this way before, you’re not alone. Writing a PRD that truly resonates isn’t easy, but it’s a skill you can build. And the key lies in telling a story.
Why PRDs Need to Tell a Story
A great PRD doesn’t just describe features; it explains why those features matter. It walks the reader through a journey:
What’s happening? What problem are we solving?
Why does it matter? Why is this worth solving, and why now?
What will we do about it? What’s the solution, and how does it address the problem?
How will we measure success? How will we know we’ve solved the problem?
What happens next? What are the contingencies if the problem persists?
This narrative doesn’t just help others understand your product vision—it helps you refine your thinking. By connecting every decision to the underlying "why," you ensure that your PRD is focused, actionable, and aligned with your goals.
Why PRDs Are Hard
Writing a good PRD is tough. If you’re new to product management, it can feel overwhelming to articulate problems, tie them to solutions, and anticipate every question your team might have. Even seasoned PMs sometimes fall into the trap of overloading a PRD with information or skipping the "why" in favor of jumping straight to the "what."
A PRD is not just about documentation. It’s about alignment. A well-written PRD ensures that everyone—designers, developers, QA, stakeholders—understands the problem and believes in the solution. If people aren’t aligned, execution suffers. And when execution suffers, so does the product.
So, if you’re struggling with PRDs, don’t be hard on yourself. Let’s walk through a practical, step-by-step process to make them better.
No BS Guide to Writing a Great PRD
Start With the Problem (The "What’s Happening?")
Be specific and grounded. Use data and anecdotes to paint a clear picture of the problem.
Example: “Cart abandonment rates have increased by 20% in the past quarter, resulting in a loss of $X in revenue.”
Tip for beginners: If you’re unsure what the problem is, spend more time talking to users, reviewing analytics, and collaborating with your team before starting the PRD. The clarity of your problem statement will make or break your PRD.
Explain the Why (The "Why Does It Matter?")
Connect the problem to its broader impact. Why should the company care? Why should your team prioritize this now?
Example: “This trend poses a significant risk to our revenue targets for the quarter and negatively impacts customer trust when they encounter friction at checkout.”
Propose a Solution (The "What Will We Do About It?")
Outline the solution in clear, actionable steps. Avoid feature dumping—each feature should directly address part of the problem.
Example: “To reduce drop-offs, we will:
a) Consolidate redundant form fields,
b) Add progress indicators to reduce anxiety, and
c) Implement autofill suggestions to speed up data entry.”Be transparent about trade-offs and scope. If a feature won’t solve the problem fully, acknowledge it and explain why you’re starting here.
Define Success Metrics (The "How Will We Measure Success?")
This step is often overlooked, but it’s critical. Success metrics ensure your PRD is outcome-driven, not output-driven.
Example: “We will consider this successful if cart completion rates increase from 60% to 75% within 90 days of release.”
Address Contingencies (The "What Happens Next?")
Show that you’ve thought about what happens if the solution doesn’t work as expected. This builds confidence in your plan.
Example: “If completion rates don’t improve by at least 15%, we will run additional A/B tests on alternative form designs and explore adding a guest checkout option.”
Common Pitfalls to Avoid
Overloading With Detail: Avoid the temptation to document everything. Focus on what’s essential to align your team. If it doesn’t help someone make a decision or understand the problem, leave it out.
Skipping the "Why": This is the most common mistake. If the PRD doesn’t explain why a feature matters, it’s just a checklist.
Unclear Metrics: If you don’t define success, you’ll have no way to know if your solution worked—or how to iterate if it didn’t.
It’s Okay to Iterate
If this feels like a lot to take in, remember that writing great PRDs is a skill that improves with practice. Your first draft might not be perfect, and that’s okay. Share it with your team early, get feedback, and refine it. The process of writing and revising is just as important as the final document.
As you gain experience, you’ll notice that writing PRDs becomes less about following a rigid structure and more about shaping the narrative that your product needs. You’ll develop your own style, but the principles will remain the same: start with the problem, explain why it matters, and connect every decision to that context.
Write With Purpose, Build With Confidence
A PRD isn’t just a document—it’s your product’s blueprint for success. Done well, it inspires trust, aligns teams, and ensures everyone is working toward the same goal.
So, the next time you sit down to write a PRD, take a deep breath and remember: your job isn’t to list features. It’s to tell a story. A story about a problem that matters, a solution that makes sense, and a plan that will deliver value.
And trust me—when your PRD tells that story clearly and thoughtfully, people will not only read it, but they’ll act on it.