It’s time to Rethink the PRD
A Product Requirements Document (PRD) is a detailed guide used in product development to outline the what, why, and how of a product or feature a team plans to build.
The PRD process has the potential to be a powerful bridge between business, design, and engineering teams—ensuring alignment and clarity across functions. However, in traditional enterprise environments, I've often seen it fall short of that potential.
Some are collaborative and thoughtful, evolving alongside research and design. But in many enterprise and healthcare organizations, PRDs are still written the old-school way—locked and loaded before design or research even begins. I’ve seen massive documents packed with feature-level requirements that rarely connect to a meaningful problem.
Things like “add ability to sort table A–Z,” “include export to Excel,” or “toggle between card and list view.” These features aren’t inherently wrong—but when they show up without context or user need, they become symptoms of a deeper issue: a process focused on shipping preconceived solutions instead of solving real problems or taking the time to fully understand them.
And it’s not just anecdotal. According to Pendo, over 93% of product features go largely unused. That stat should stop us in our tracks. It’s not just a matter of wasted effort—it’s a sign that the way we scope and define products is fundamentally flawed.
If we’re investing time, resources, and team energy into building things no one ends up using, something is clearly off. So why are we still starting with a document that assumes we already know what to build—when in some cases we don’t?
When the PRD comes first, innovation comes last
From the perspective of the potential to create world-class user experiences, the traditional PRD comes at the wrong point in the process. It shows up first, when it should actually come last. It assumes the solution before anyone truly understands the problem.
Teams get locked into building what was outlined months ago instead of stepping back to ask, “Is this even the right thing to build?” We’ve been conditioned to chase polished specs and feature completeness before we fully understand the user.
I’ve heard it countless times: “Just throw devs at it and start coding.” The how gets prioritized over the why. But if we want to build better products—useful, human, adaptable—we have to fall in love with the problem first.
We need to get inside the user’s world, understand what they’re trying to do, what’s getting in their way, and how they feel while doing it. That kind of discovery can’t be reverse-engineered from a static doc.
Discovery should come first, not the PRD
And that’s the key shift—the PRD should not be the starting point. It should come after we’ve spent time with the problem—after we’ve had real conversations with users, explored the nuances of their workflows, and uncovered what actually matters.
Before we document what to build, teams need the space to explore what’s possible. This is where design thinking becomes essential—especially the divergent and convergent approach championed by IDEO. First, we diverge: casting a wide net to understand users, uncover insights, and explore potential opportunities. Then we converge: narrowing in on the real problem and the most meaningful solutions.
Design, research, and product need time to challenge assumptions and think creatively before anything gets locked into a document. The PRD isn’t a tool for guiding innovation—it’s a tool for delivering on it. It should serve as a downstream artifact, not the spark of the creative process.
AI has changed the game and our process needs to catch up
This matters more now than ever.
In the age of AI, user experiences are no longer linear or predictable. They’re fluid, dynamic, and deeply contextual. One user might need guidance, while another wants autonomy. AI acts as a collaborator along the user’s journey, adapting in real time to support their unique needs and intentions.
But for AI to truly partner with users, we first need to map out the full range of situations and behaviors that drive how people interact. When experiences personalize and evolve based on a user’s moment-to-moment needs, the old way of working—feature-first, spec-driven—just doesn’t hold up.
We need new methods that embrace complexity and design for it, not against it.
Dive into the problem framework, not the feature list
That’s where a problem-first approach really makes a difference. Instead of jumping straight into a list of features, we start by digging into the real challenge. What I call a “problem framework” helps us get there.
Take a logistics team tracking shipments across multiple carriers. The obvious feature request might be “add a tracking number search.” But when you look deeper, you find the real job is to reduce the frustration and wasted time caused by juggling multiple systems. The pain points are inconsistent updates, missed alerts, and unclear next steps. And beneath it all? The stress of meeting tight delivery deadlines.
That’s the problem worth solving. When we truly understand that, we discover new possibilities—like AI stepping in to monitor all those systems and offering recommended options with clear trade-offs: one faster but pricier, another cheaper but slower.
This kind of insight only comes from focusing on the problem first, not just ticking off features—and it’s what leads to solutions that genuinely help users.
Design for situations, not static flows
This kind of framing creates clarity. It gives the entire team—designers, engineers, product managers—a shared understanding of the problem space, and the flexibility to explore multiple directions.
And when we let those patterns emerge naturally through user narratives, interviews, and contextual inquiry, we stop jumping to solutions. We start designing experiences that respond to real moments. Especially in AI-powered products, where the system itself can adapt, this kind of grounding is essential.
You can start to define the “rules of engagement”—how the product responds in different emotional or situational states, where AI steps in to help, and when it should step back. It’s thoughtful, it’s flexible, and it puts the user first.
Let the PRD come last
Then—and only then—does the PRD make sense.
At that point, it becomes a summary of everything we’ve learned, not a guess at what might work. It documents the core problems we’re solving, the behaviors we’re designing for, and the adaptable rules the product needs to follow.
It shifts from being a rigid blueprint to a dynamic guide for development—one that honors the work of research and design, rather than skipping past it.
Maybe it's time to call it something else
Perhaps the biggest shift isn’t just when the PRD shows up—it’s what it represents. If we want this document to reflect everything we’ve discovered, designed, and defined for delivery, maybe it’s time we gave it a new name.
How about we call it the Experience Delivery Blueprint?
By calling it that, we’re saying this isn’t just a document listing requirements. It’s a comprehensive, strategic plan—a guide for how a specific experience will be delivered to users or customers across all cross-functional touchpoints. It combines intentional design with operational execution.
Experience refers to the user’s or customer’s journey—the emotional, cognitive, and functional interactions they have with the product.
Delivery focuses on execution—the mechanisms, processes, and teams responsible for making that experience real and consistent across channels.
Blueprint implies a detailed, visual, and structured plan—possibly with diagrams, interaction workflows, and designs—used to align stakeholders around how the experience comes to life.
This isn’t just semantics—it’s a signal. It acknowledges that what we’re building isn’t a checklist of features. It’s an experience we’re delivering to real people, in real contexts, with real stakes.
The Experience Delivery Blueprint is the output of deep user understanding, creative exploration, and problem-first thinking. It’s not just what the team needs to build—it’s what the market needs in order to succeed.
Why this matters
This shift—from rushing into solutions to living in the problem space—matters. It unlocks creativity. It keeps us honest. And it helps teams build products that are not only more usable, but more meaningful.
If we want to build for the future—where experiences adapt in real-time, predict user needs, and feel deeply personal—we have to rethink how we start.
It’s time to bring design in early, fall in love with the problem, design for moments—and finally, let the PRD come last. Or better yet, reframe the PRD altogether.