Most PRDs fail in leadership reviews not because the thinking is bad — but because the PM didn't anticipate the CTO's technical concern, the UX lead's usability question, or the exec's "how does this move the number" challenge. The fix is simulating the review before it happens.
I've sat in a lot of leadership reviews. On both sides of the table — as the PM presenting and as the Head of Product watching someone squirm when the CEO asks a question they clearly hadn't prepared for.
The presentation is rarely the problem. The preparation is.
PMs do thorough research. They write tight PRDs. They add the diagrams and success metrics and edge cases. And then they walk into a room with four people who have completely different lenses — technical, UX, business, adversarial — and get blindsided by a question that was obvious in retrospect.
There's a pattern to the questions that kill PRDs in review:
- The CTO asks: "How does this interact with the existing auth system?"
- The UX lead asks: "What happens when a first-time user hits this screen without any data?"
- The exec asks: "What's the 90-day impact on retention, specifically?"
- Someone asks: "What's the strongest argument against building this at all?"
None of these are unfair questions. They're exactly the questions a good leadership team should ask. The problem is that PMs often haven't answered them — because nobody in their prep loop represented that perspective.
AI can fix this. Not by replacing your leadership team's judgment, but by simulating their lenses before you step into the room.
The AI Leadership Review Panel
The structure is simple: four agents, four distinct reviewing perspectives, one PRD.
| Agent | Lens | What They Challenge |
|---|---|---|
| CTO | Technical feasibility | Architecture, dependencies, engineering cost, scalability risks |
| UX Lead | User experience | Edge cases, empty states, mental models, accessibility |
| Executive | Business impact | Metrics, ROI, strategic alignment, opportunity cost |
| Devil's Advocate | Adversarial | The strongest case against building this at all |
Each agent reviews your PRD independently and returns a set of questions — not edits, not rewrites, questions. The kind your real leadership team would ask if they were doing their jobs well.
The output is a challenge brief: a structured list of unresolved questions you need to answer before the actual review.
How It Works in Claude
Set up a system prompt for each agent persona. Here's the CTO agent:
You are the CTO reviewing this PRD. Your job is not to approve it — your job is to surface every technical assumption, dependency risk, and engineering concern embedded in this document. You ask precise, specific questions. You don't compliment the work. You find what's missing.
Specifically look for:
- Assumptions about existing systems that may not be accurate
- Missing technical constraints or non-functional requirements
- Scope creep hidden inside vague feature descriptions
- Integration points that weren't thought through
- Engineering estimates that feel optimistic
Return 5-8 precise questions the PM should answer before this goes to engineering.
Then paste your PRD and run all four agents in parallel.
With Claude's Projects feature or multi-window setup, you can run all four simultaneously. What you get back is a synthesis of the hardest questions your PRD will face — before anyone with decision-making authority sees it.
What the Output Looks Like
Here's an excerpt from a real challenge brief for a notification center feature:
CTO Questions:
- Our current notification pipeline uses event-driven architecture with SQS. Will this feature require changes to the event schema, or is it consuming existing events?
- You mention "real-time" notifications — what's the acceptable latency threshold? Real-time means different things to different engineers.
- What's the failure mode if the notification service goes down? Silent failure or degraded state?
UX Lead Questions:
- What does the notification center look like for a new user who has zero notifications? You haven't specified the empty state.
- How do users discover the notification center exists? First-time user flow isn't addressed.
- What happens if a user has 500+ unread notifications? Is there pagination, archiving, or a cap?
Executive Questions:
- You show a 15% engagement uplift projection — what's the methodology? Is that from A/B tests elsewhere or benchmarks from competitors?
- This feature doesn't directly touch our core activation metric (first workflow completion). Why is this higher priority than features that do?
- What's the opportunity cost? What are we not building in the next sprint?
Devil's Advocate:
- The strongest case against: notifications are a feature users request but don't use. Instagram, Slack, and Figma all have notification fatigue problems. Why are we confident this will drive engagement rather than another badge users ignore?
Why This Changes Your Prep Process
The traditional prep loop for a leadership review looks like this:
- Write PRD
- Get peer feedback from other PMs
- Review with your manager
- Present to leadership
The problem: everyone in that loop has the same blind spots you do. They're close to the problem. They don't have the CTO's architectural awareness or the exec's portfolio-level scrutiny.
The AI review panel gives you access to adversarial perspectives you don't have in your direct network. It's not replacing any of those human conversations — it's adding a review layer that catches the questions your inner circle missed.
The shift in how you prepare is significant:
Before: Present the PRD, answer questions in the room, schedule a follow-up to address blockers
After: Arrive with the hard questions already answered, embedded in the PRD itself, with the supporting rationale documented
Leadership reviews stop being interrogations. They become conversations about prioritization.
Running This for Real
This works best when:
The PRD is at 70-80% draft state. Too early and there's nothing to challenge. Too polished and you're defensive about changes.
You give each agent your full context. The better the agents know your product, users, and business model, the more specific their questions will be. Generic PRD inputs return generic questions. Load your company context file before running the review.
You treat the output as a to-do list. Every question that doesn't have a clear answer in your current draft is a gap. Fill the gaps before the real review. Don't ignore the uncomfortable ones — those are the questions your CTO is definitely going to ask.
You don't filter based on defensiveness. The questions that make you want to explain yourself are the ones that need to be in the document, not defended verbally.
The Meta-Lesson
The teams I see getting the most leverage from AI aren't using it to write better first drafts. They're using it to challenge their own thinking before anyone else gets to.
That's a different mental model. Instead of AI as a writing assistant, AI as a rigorous reviewer that has no stake in your success and no social relationship to protect.
The PRD that survives a full AI leadership review panel is genuinely tighter. The meeting where you present it goes faster. The questions you get are the ones you already answered.
That's what prepared looks like.
The AI leadership review panel is part of the multi-agent workflows available in the mySecond PM Operating System. If you want to build this setup for your own team — with your context, your leadership structure, and your review criteria already loaded — the /prd-generator and /decision-maker skills include review panel configurations.