Use this when you need to write or refine a PRD for a new feature or product initiative. Walks through an interactive process to produce a structured PRD with problem statement, goals, user stories, scope, and open questions — then stress-tests it.
For AI-powered features: This skill covers traditional PRD structure. If the feature uses LLMs or AI models, use
/ai-product-specinstead -- it extends this skill with model requirements, prompt architecture, eval criteria, and cost projections that AI features need.Related resources:
product-vision-template.md-- fill-in-the-blank product vision statement template with checklist and worked examples.
Process
Step 1: Gather context
Ask the user: 0. Mode -- full PRD (default) or problem statement only? Use problem-only when you need to validate the problem before committing to a full spec.
- What are you building? (Feature name and one-line description in plain language)
- What user problem does this solve? (Include evidence — user quotes, support tickets, metrics, research findings)
- Why build this now? (Business rationale, strategic context)
- Known constraints — technical limitations, timeline, budget, dependencies, regulatory requirements
- Accessibility and compliance requirements — WCAG conformance level (AA is the default), Section 508, EAA, ADA, or industry-specific mandates? Known users of assistive technology? Existing accessibility audits or VPATs?
- Target markets and languages — single market/language, or multi-market? Which locales are in scope for launch? Any region-specific regulatory requirements (GDPR, data residency, in-country hosting)?
- Prior art — how competitors or existing solutions handle this
- Who are the stakeholders? (What different people expect from this project)
If the user provides a brief description, extract what you can and ask follow-up questions for gaps. You need enough context to write a useful PRD, not just a comprehensive one.
Step 2: Identify which personas this serves
Before drafting, prompt the user:
Persona check: Which user persona(s) does this feature serve? If you have defined personas (e.g., from
/persona-createor/persona-draft), name them. If not, describe the key user types briefly — their role, goals, and what their primary job-to-be-done is.This grounds the PRD in real user context — the problem statement, user stories, and success metrics should all reference specific personas rather than generic "users."
Step 3: Draft the PRD
If problem statement only mode: Output only the Overview and Problem Statement sections from the template below. Then jump to Step 4 to stress-test the problem statement. Skip Goals, User Stories, Scope, Design, Technical, and Timeline sections.
# PRD: (Feature name)
## Overview
(What we're building and why, in 3-4 sentences. No jargon.)
## Problem Statement
(The user problem, supported by evidence. Cite specific quotes, data points, or support ticket patterns. "Users want X" needs evidence. "We think users want X" is honest but weaker.)
## Goals & Success Metrics
| Goal | Metric | How we measure it |
|------|--------|-------------------|
| (Goal 1) | (Specific metric) | (Tool or method) |
| (Goal 2) | (Specific metric) | (Tool or method) |
## User Stories
(Key user stories that define scope, with Gherkin acceptance criteria for the most important ones.)
### Story 1: (Title)
As a (persona), I want to (action), so that (value).
**Acceptance Criteria:**
- Scenario 1: (Given/When/Then summary)
- Scenario 2: (Given/When/Then summary)
### Story 2: (Title)
(Same format)
## Scope
**In scope:**
- (Capability 1)
- (Capability 2)
**Out of scope:**
- (Explicitly excluded item 1 — and why)
- (Explicitly excluded item 2)
## Design Considerations
- (Key UX questions, interaction patterns, or constraints)
- (Edge states: empty, error, loading)
## Accessibility Requirements
- **Target conformance level:** WCAG 2.2 (A / AA / AAA) — default AA if not specified
- **Known AT users:** (Screen reader, keyboard-only, voice control, magnification — or "unknown")
- **Legal or compliance drivers:** (ADA, Section 508, EAA, client contract, or "none specified")
- **Accessibility testing approach:** (Automated checks in CI, manual screen reader testing, third-party audit, or "to be defined")
- **Key accessibility considerations for this feature:**
- (Specific a11y concern 1 — e.g., "Complex data table needs keyboard navigation and screen reader column/row headers")
- (Specific a11y concern 2 — e.g., "Real-time updates need aria-live announcements")
## Internationalization Requirements (if multi-market)
- **Target locales:** (languages and regions in scope for this feature/product)
- **i18n engineering requirements:** (string externalization, locale-aware date/number formatting, text expansion buffers, RTL support if applicable)
- **Localization workflow:** (how translations will be managed -- TMS, vendor, timeline)
- **Region-specific compliance:** (GDPR, data residency, in-country hosting, local payment methods)
- **Locale-specific acceptance criteria:** (any user stories that behave differently per locale)
## Technical Considerations
- (Architecture implications)
- (Dependencies on other teams or services)
- (Performance requirements)
- (Security considerations)
## Open Questions
- (Thing we need to resolve before or during development)
- (Decision that hasn't been made yet)
## Timeline & Milestones (if applicable)
- (Phase 1: scope and target)
- (Phase 2: scope and target)
In the User Stories section, use the persona names from Step 2 in the "As a..." role — not generic "user."
Step 4: Stress-test the draft
After generating the PRD (or problem statement), play devil's advocate:
- What are the weakest assumptions in this PRD?
- What could go wrong that we haven't addressed?
- Is the scope too broad for a first release? Suggest an MVP cut.
- Are the success metrics actually measurable with current tooling?
- What questions would a skeptical engineer ask?
- What questions would a skeptical designer ask?
If problem statement only mode: Focus on questions #1 (assumptions) and #4 (measurability of the problem evidence). Skip #3 (scope), #5, and #6 -- those apply to the full PRD.
Present these challenges to the user and revise the PRD based on their responses.
Step 5: Review and finalize
Ask the user:
- Is the problem statement supported by real evidence, or are we asserting an unvalidated need?
- Could the out-of-scope section be bigger? (First versions should be aggressively scoped down.)
- Are the open questions honest about what we don't know?
- Is this clear enough for someone who wasn't in the room to understand what we're building and why?
Make final edits.
Uncertainty Policy
| Topic | Tolerance | Action |
|---|---|---|
| User problem statement | Low | STOP and ask — PRD is useless without a real problem |
| Success metrics | Low | STOP and ask — vague metrics lead to vague features |
| Scope boundaries | Low | STOP and ask — scope creep starts with assumptions |
| Competitor details | Medium | Assume + flag [ASSUMED] — user can verify |
| Technical constraints | Medium | Assume + flag [ASSUMED] — engineering will correct |
| Timeline estimates | Medium | Assume + flag [ASSUMED] — user adjusts to reality |
| Stakeholder names/roles | High | Best guess from context |
Default: STOP and ask when a topic is not listed above.
Output location
Present the PRD as formatted text in the conversation for the user to copy into their docs tool (Notion, Google Docs, Confluence, etc.).
Example Output
Input
- Feature name: Saved Searches & Smart Alerts — allow users to save complex search queries and receive email/in-app notifications when new listings match their criteria
- Company & product: Crexi, a commercial real estate marketplace (cre.tech); feature targets the existing property search experience used by brokers and buyers
- User problem evidence: Support team logged 340+ tickets in Q3 requesting "email me when new listings match my filters"; top broker NPS detractor theme in last survey was "I have to manually re-run searches every day"; power users averaging 8+ search sessions/week
- Business rationale: Reducing search friction increases listing-to-offer pipeline velocity; alerts are a key feature gap vs. CoStar and LoopNet; Sales flagged it as a blocker in 6 enterprise deals in Q4
- Known constraints: Email infrastructure is SendGrid; real-time indexing pipeline runs on 15-minute batch cycles; mobile app (iOS/Android) is a separate codebase — push notifications out of scope for v1; GDPR compliance required for EU broker accounts
Output (abbreviated)
PRD: Saved Searches & Smart Alerts
Overview
Crexi brokers and buyers currently must manually re-run complex property searches every session with no way to persist criteria or receive proactive updates. This feature lets authenticated users save up to 20 named search queries and opt into email or in-app notifications when new listings match their saved criteria. It closes a documented feature gap versus CoStar and LoopNet and directly addresses the top NPS detractor theme from Q3.
Problem Statement
Power users on Crexi run the same complex searches repeatedly — filtering by asset class, geography, cap rate range, and deal size — with no way to save that work or be alerted to new matches. Evidence:
- 340+ support tickets in Q3 explicitly requesting "email me when new listings match my filters"
- Top broker NPS detractor in Q3 survey: "I have to manually re-run the same search every single morning. It costs me 20 minutes a day." (verbatim, NPS open-text)
- Power users (8+ sessions/week) represent 18% of MAU but 61% of offer submissions — search friction disproportionately affects the highest-value segment
- Sales team flagged as a blocker in 6 enterprise deals in Q4 where prospects cited CoStar alert functionality as the reason for not switching
Goals & Success Metrics
| Goal | Metric | How we measure it |
|---|---|---|
| Reduce daily re-search burden for power users | Avg. weekly search sessions per power user decreases ≥15% within 60 days of launch | Mixpanel session events |
| Drive new listing discovery via alerts | ≥30% of alert recipients click through to a listing within 7 days of first alert email | SendGrid click tracking + Mixpanel funnel |
| Improve broker NPS on search experience | NPS detractor mentions of "manual search" drop ≥50% in next quarterly survey | Medallia NPS open-text analysis |
| Unblock enterprise sales pipeline | 4 of 6 flagged deals re-engaged within 90 days post-launch | Salesforce opportunity stage tracking |
User Stories
Story 1: Save a search query
As a Power Broker (Maya), I want to save my current search filters under a custom name, so that I can return to exactly that criteria without rebuilding it.
Acceptance Criteria:
- Given I have applied ≥1 filter on the search results page, When I click "Save Search," Then a modal prompts me to name the search and confirm
- Given I have 20 saved searches already, When I attempt to save a 21st, Then I see an inline error explaining the limit with a link to manage existing saved searches
- Given I save a search, When I navigate to My Account > Saved Searches, Then the new search appears with its name, filter summary, and creation date
Story 2: Configure alert frequency
As a Power Broker (Maya), I want to choose how often I receive email alerts for a saved search, so that I control notification volume without missing time-sensitive listings.
Acceptance Criteria:
- Given I am creating or editing a saved search, When I toggle on "Alert me," Then I can select Daily Digest, Instant (next batch cycle, ≤15 min), or Weekly
- Given I select Instant alerts, When a new listing is indexed that matches my criteria, Then I receive an email via SendGrid within 15 minutes of the batch cycle completing
Story 3: Manage and delete saved searches
As a Buyer-Side Analyst (Jordan), I want to view, rename, and delete my saved searches from a single dashboard, so that I can keep my search library organized as deal criteria evolve.
Scope
In scope:
- Save, name, and manage up to 20 searches per authenticated user
- Email alerts via SendGrid at three cadences: Instant (≤15 min post-batch), Daily Digest, Weekly
- In-app notification badge + notification center entries for matched listings
- Saved search management UI: list view, rename, delete, toggle alerts on/off
- GDPR-compliant alert opt-out flow for EU accounts (one-click unsubscribe, preference center)
Out of scope:
- Push notifications on iOS/Android — separate mobile codebase; defer to v2
- Shared/team saved searches — requires org-level permissions model not yet built
- Instant real-time alerts (sub-15-min) — current indexing pipeline is batch; real-time pipeline is a separate infrastructure project
- SMS alerts — SendGrid SMS not yet provisioned; low signal in support tickets
- Saved searches for unauthenticated/guest users — authentication required for data persistence
Accessibility Requirements
- Target conformance level: WCAG 2.2 AA
- Known AT users: Unknown at user-specific level; enterprise accounts include institutional buyers likely to have keyboard-only and screen reader users
- Legal or compliance drivers: ADA (US); EAA compliance required for EU broker accounts by June 2025
- Accessibility testing approach: Automated axe-core checks in CI pipeline; manual screen reader testing (NVDA + Chrome, VoiceOver + Safari) before launch
- Key accessibility considerations:
- Save Search modal must be a proper ARIA dialog with focus trap and focus return on close
- Alert frequency radio group needs explicit
fieldset/legendgrouping - Notification badge count must be exposed via
aria-label(e.g., "5 new listing alerts") - In-app notification center must support full keyboard navigation (arrow keys, Enter to open, Escape to dismiss)
Internationalization Requirements
- Target locales: en-US (launch); en-GB, de-DE, fr-FR for EU GDPR compliance scope
- i18n engineering requirements: All UI strings externalized to i18n JSON; date formats locale-aware (MM/DD/YYYY vs. DD/MM/YYYY); email templates translated via localization vendor
- Localization workflow: Strings to Phrase TMS 2 weeks before code freeze; translated email templates QA'd by in-market reviewers
- Region-specific compliance: EU accounts require GDPR-compliant unsubscribe in every alert email; preference center must log consent timestamp and withdrawal; data for EU users stored in Frankfurt region (existing data residency setup)
- Locale-specific acceptance criteria: EU users who unsubscribe from alerts must be suppressed from all future alert sends until they explicitly re-opt-in via preference center
Technical Considerations
- Alert matching logic runs against the existing Elasticsearch index on 15-minute batch cycles — [ASSUMED] query fan-out for users with 20 saved searches each needs load testing at scale before launch
- SendGrid dynamic templates needed for Instant, Daily Digest, and Weekly formats — Daily Digest must aggregate ≥1 listing without sending empty digests
- Saved search data persisted in user profile service (PostgreSQL); schema additions needed for search criteria JSON blob, alert cadence, last-alerted timestamp
- [ASSUMED] Notification center uses existing in-app notification service; confirm with Platform team whether it supports per-notification-type read/unread state
- GDPR suppression list sync between SendGrid and user profile service must be bidirectional — unsubscribe in email must reflect immediately in UI preference center
Open Questions
- What is the expected p95 latency for the alert matching job at 50K active saved searches? Needs load test before committing to the 15-min SLA in marketing copy.