The Product and Design Review (PRDR) is, without question, the high point of my week.
Once a week, the product organization undergoes a subtle but profound shift. For ninety minutes, the traditional org chart evaporates. We stop talking about velocity, we stop looking at burn-down charts, and we stop worrying about the minutiae of the current sprint. Instead, we explore the conceptual, meaty topics that provide tangible glimpses of our future.
It is a rallying point. It's a designer and PM showcase. It provides the organizational glue that combats siloed-thinking that happens when teams expand. And most importantly, it ensures we are building the right things, and building in the right way.
Once a Week, the Tables are Turned
There is something magical about the mechanics of a great PRDR. In this room (or on this Zoom), even the most junior PM or designer becomes the center of gravity for the entire product organization. Directors, VPs, and seasoned leads are there for one purpose: to support their thinking, challenge their assumptions, strengthen their craft, and help their ideas grow teeth.
In that moment, seniority doesn't matter. The presenter isn't the "junior" anything; they are the one running the show, temporarily borrowing two hundred years of collective experience from everyone else in the session.
This is where the transition from exploration to execution happens. We spend so much time in product development doing generative research and creative ideation. Those methods help us see what's possible. But the PRDR is where those ideas evolve into something real and buildable. This transition is where most teams stumble. Where great ideas get diluted, misaligned, or lost in translation once they move from a sticky note to a Jira ticket. The PRDR exists to prevent that drift.
Possibility Over Output
Most companies are great at "Sprint Demos." You know the drill: the engineering team shows what was built over the last two weeks. This is incredibly important, but it's essentially an autopsy. It's a look at the past.
The PRDR, however, shows what could be built. If a Sprint Demo is about output, the PRDR is about possibility.
Why is this distinction so critical? It comes down to the cost of being wrong.
- If an engineer makes a mistake and we catch it in a sprint review, that's an easy fix. We lost a few hours of coding.
- If a designer takes a concept in the wrong direction and engineering builds it, we've lost weeks.
- But if a PM develops requirements that solve the wrong problem, that impact spans the entire organization and can result in a total do-over.
The PRDR is our primary mechanism for catching "wrong problem" and "wrong direction" issues early in the converge phase, long before a single line of code is written.
The Two Pillars of the PRDR
To keep the meeting hyper-focused, we limit the agenda to two critical milestones. We don't talk about roadmaps, detailed release plans, or bug reports. We focus on:
- The Opportunity Definition (OD): A deep dive into the problem framing. Are we solving a real pain point? Do we have alignment on the target user and the Jobs-to-be-Done (JTBD)?
- The Concept Design: Reviews the experience design for an OD that was likely presented a couple weeks prior. We aren't just looking at "which button looks better," but rather asking: Does the low fidelity design solve the problem outlined in the OD? Which of the three concepts resonate? Are there implications for other products in our portfolio? Are there unintended consequences?
By the time a PRDR happens, the PM or designer has usually spent dozens of hours in the "deep-dive zone." They are close to the work; perhaps too close. Bringing in forty-five minutes of "fresh eyes" from the broader team always yields surprising observations that the primary owner was simply too submerged to see.
The Social Contract: Rules of Engagement
A meeting this high-stakes requires more than just an agenda; it requires a contract. If the PRDR comes across as an interrogation, people will hide their best (and riskiest) ideas. If it feels like a social club, nothing gets improved.
I follow a strict set of ground rules to keep the energy productive.
For the Presenter:
- Frame the Stage: Be explicit about where you are. Is this a half-baked idea? A second-pass design?
- Be Specific on Feedback: Don't just say "What do you think?" Say, "I want feedback on whether the experience flows intuitively; I don't care about the copy on these screens yet."
- Feedback is a Gift: Acknowledge it, don't defend against it. Your job is to value new thoughts, not to protect your initial draft.
For the Audience:
- Listen First: Silently review the design or OD before speaking. Take notes.
- The "Why" Matters: Avoid "I like" or "I don't like." Those are subjective and unhelpful. Instead, offer observations on what is or isn't working against the stated objectives.
- Be Helpful, Not "Smart": We've all been in meetings where someone tries to prove they are the smartest person in the room. In a PRDR, a great question is 100x more valuable than a "Yoda-level" comment. Your goal is to help the presenter dig deeper, not to solve the problem for them on the fly.
Best Practices for Facilitation
After running these sessions for the last fifteen years, I've learned that the "Head of Product" (or whoever is facilitating) acts as the thermostat for the room. You set the temperature.
1. It is NOT a Stage Gate
This is the most important mindset shift. The PRDR is not a "box to be checked" or a waterfall gate where you need permission from the "higher-ups" to proceed. It is a support system. If a concept needs three rounds of PRDR to get strong enough to build, that's a win, not a failure.
2. Think in Flows, Present in Flows
One of the most common ways designs fail is when they exist in a vacuum. A designer might show an amazing new feature, but neglect to show how the user actually arrives there or where they go afterward. We insist on seeing entry and exit points. When you think in end-to-end customer flows, you suddenly realize you have dependencies on three other teams you hadn't even talked to yet.
3. Participation is Mandatory
The voices are in the room; they often just need an invitation. If the senior execs are doing all the talking, the facilitator must nudge the quieter participants. "Sarah, you've been working on the checkout flow—how does this new concept impact what you're seeing?"
4. Create a "Safe" Performance Space
The presenter should never feel like their job performance is being graded based on a single PRDR. They need to feel they can humbly share their "work in progress." If there is fear in the room, creativity dies.
5. Sweat the Logistics
Use a central "source of truth" for the PRDR. I use a simple Google Sheet that acts as a running calendar. It links to the upcoming topics and archives all previous assets. It creates a library of our product's evolution. If someone wants to know why we made a decision six months ago, they don't have to hunt through Figma or Slack—they just go to the spreadsheet.
The Ultimate Toll Booth
The PRDR is the ultimate toll booth for your product strategy. It ensures that as you scale, you don't drift away from your shared vision.
In our modern world of hybrid and distributed work, it's all too easy for teams to fall into silos. A designer in Product Area A might have no idea what's happening in Product Area B. The PRDR bridges those gaps, forcing us to look at the product suite holistically—which, incidentally, is exactly how our customers experience it.
If you aren't doing this yet, start next week. Set the ground rules, empower your team's talent, and start focusing on possibility. It's the highest-leverage ninety minutes you'll spend all week.
Want to learn more about the Opportunity Definition? Start here.