PRD Review
Prompt detail
You are a senior software engineer / tech lead.
Please do a concise but sharp PRD review from an engineering perspective.
##Focus on:
- Ambiguous or unclear requirements
- Underestimated complexity or hidden risks
- Issues likely to cause rework, delays, or quality problems
##PRD:
{{@PRD content}}
##Output structure:
1. One-sentence verdict
(Is this PRD ready for development? Why or why not?)
2. Key issues (Top 3–5)
- What the issue is
- Why it matters
3. Hidden risks / implementation traps
- Engineering, data, edge cases, AI (if applicable)
4. Minimal improvement suggestions
- The most important changes needed to make this PRD buildable
What the prompt does
Product Requirements Documents often reach engineering with vague specs, underestimated complexity, and edge cases nobody considered. This prompt acts as a senior tech lead reviewing your PRD — catching the issues that typically surface mid-sprint when they're expensive to fix.
Feed any PRD into remio and get a structured engineering critique: a readiness verdict, the top issues ranked by impact, hidden implementation traps around data, AI, or edge cases, and the minimal changes needed to make the document actually buildable. remio locates the PRD from your workspace — no copy-pasting walls of text.
When to use
• A product manager just shared a PRD in Slack and you need to provide engineering feedback before the next planning meeting.
• You're a tech lead preparing for a design review and want to identify the riskiest sections of a spec before committing to estimates.
• Your team keeps hitting mid-sprint surprises — scope creep, unclear acceptance criteria, or integration gaps — and you want to catch these patterns earlier.
• You're reviewing a PRD for a feature involving AI, complex data pipelines, or third-party integrations where hidden complexity is common.
Prompt examples
Input: Review the PRD titled "Real-Time Notification Preferences v2" shared in the #product-specs Slack channel last Thursday.
remio responds:
Verdict: This PRD is not ready for development — the notification delivery guarantees and user preference migration path are undefined, which will cause rework once edge cases hit production.
Key Issues:
1. "Real-time" is undefined — No SLA for delivery latency. Does real-time mean <1s, <5s, or best-effort? This drives fundamentally different architecture choices.
2. Migration from v1 preferences is unspecified — 340K existing users have saved preferences. No mention of backward compatibility or data migration strategy.
3. Channel priority logic is ambiguous — "Smart routing" across email, push, and SMS lacks clear fallback rules when a channel fails.
Hidden Risks: Rate limiting on third-party SMS providers could silently drop notifications during peak events. The PRD assumes 100% deliverability.
Minimal Improvements: Define latency SLA, add a v1→v2 migration section, and specify fallback behavior per channel.
Tip 1: Reference the PRD by its document name or Slack message so remio retrieves the exact version — avoid ambiguity about which draft you're reviewing.
Tip 2: Mention the tech stack or key constraints (e.g., "we use Kafka for events" or "this must work offline") to get risk analysis tailored to your actual architecture.
Tip 3: Run this prompt again after the PRD is revised to verify whether flagged issues were adequately addressed before sprint planning.
More tips
レミオは知識に関するあらゆるニーズを満たします
詳しい機能はこちら
ウェブサイト、ローカル フォルダー、ファイルからリソースをキャプチャします。
ナレッジベース全体から、信頼できる回答を即座に取得できます。
デスクトップ、ブラウザ、モバイルで使えるアシスタント。
無制限の無料録音と文字起こし、ボットなし。