How Uber’s product teams built a PRD reviewer that catches gaps before they reach leadership
And how to build your own version. Plus: other examples from DoorDash, Atlassian and more. AI augmented product development process explored.
As AI eats its way into every part of the product development process, there’s been plenty of debate about the future of PRDs. Some argue that they’re “dead” while others, including Linear’s CPO, argue that they’re actually more important than ever:
One company that is still firmly on board with PRDs is Uber. And despite their CTO recently admitting that they’ve already spent their Claude Code budget for 2026, AI is transforming how they approach PRDs. This past week, Uber’s product teams revealed a powerful new tool that they use to write PRDs that involves the help of an AI reviewer that analyses its contents, runs contextual checks for similar ideas that failed in the past and assesses what impact, if any, the proposed feature might have.
The PRD review doesn’t offload the critical part of deciding whether or not a feature should ship; instead, it works to gather the necessary contextual information to help product and leadership teams apply their human judgement instead.
In this Deep Dive, we’re going to take a closer look at what exactly Uber’s product teams built, plus, how you can build your own lightweight version of a PRD Evaluator in Claude - with relevant prompts and frameworks.
As well as this, we’ll explore other recent examples from companies including Atlassian and Doordash that show how they’re transforming their own development and design processes with AI, which you can use as inspiration for your company’s product development processes.
Coming up:
A deeper look at what Uber’s product teams built with their PRD reviewer
How to build your own version of this tool with Claude quickly
Other examples of how the product development process is being transformed from Atlassian, Doordash and others
Uber’s PRD Reviewer Explained
Uber’s PRD reviewer was built to solve a very specific problem at the company: PRDs would reach the review stage with unsupported assumptions, blind spots around adjacent systems, unexamined second-order effects, or policy-sensitive changes without proper guardrails.
In a large company like Uber with thousands of employees, it’s difficult for product teams to truly get a 360 understanding of things like prior experiments that were run for similar features, hidden dependencies or adjacent impacts on other products in the organization.
Here’s a snapshot of what they built:
The PRD Evaluator is an AI-powered reviewer that starts with a PRD and assembles a broader knowledge base around it. This includes things like linked documents, related decks and meeting notes, prior experiments, cross-functional artifacts, and preloaded Uber-specific context like core principles, metric definitions, and key jobs to be done.
Crucially, it’s designed to augment - but not replace - senior judgement by ensuring PRDs are given the proper context they need before they reach a wider review.
A PM may not know a similar hypothesis was tested earlier by another team, may not realize a metric is missing an obvious guardrail, or may not see a downstream operational dependency because it sits outside their immediate product surface. Product managers can upload a draft PRD and get all of the necessary context they need to catch any gaps beforehand.
How it works - and how to build your own version with Claude
The PRD reviewer is a custom built internal tool that works across 4 key steps.
Step 1 - Build context beyond the PRD
The evaluator uses the PRD as an entry point, then searches across relevant company artifacts and linked material to assemble context needed to assess the decision well: related documents, prior experiments, cross-functional inputs, and preloaded Uber-specific context.
The point here is that many gaps in a PRD only become visible when you compare it against what already exists - prior experiments the current team may not know about, adjacent efforts that create dependencies, institutional context that never made it into the document itself.
Step 2 - Classify the PRD to calibrate review depth
Not every PRD needs the same level of scrutiny and so the evaluator handles this by classifying each PRD into one of four tiers: