Ship Better Products Faster with AI

Write a PRD for this feature: [describe the feature]. Product: [describe the product]. Target user: [describe]. Business goal: [describe]. Include: (1) problem statement — what user pain does this solve, with evidence, (2) proposed solution — high-level description with key user flows, (3) success metrics — how we will know this worked (quantified), (4) scope — what is in v1 and what is explicitly deferred to v2, (5) user stories with acceptance criteria for each, (6) edge cases and error states, (7) technical considerations — API needs, data model changes, performance requirements, (8) dependencies — what needs to happen before or alongside this, (9) open questions to resolve before engineering begins. Write for an engineering team that needs to build from this document.

Generate user stories for [feature or epic]. User types: [list personas]. For each user type, write 5-8 user stories in the format: "As a [user type], I want to [action] so that [benefit]." For each story: (1) add acceptance criteria (Given/When/Then format), (2) estimate complexity as S/M/L, (3) flag dependencies on other stories, (4) note any edge cases. Organize stories into a logical implementation order. Identify which stories are essential for MVP and which can come later. Include one "unhappy path" story per user type (what happens when things go wrong).

Write a detailed feature specification that my engineering team can build from. Feature: [describe]. Product: [describe]. The spec should include: (1) a brief context section — why we are building this (2 sentences), (2) detailed user flow — step-by-step from entry point to completion, (3) UI/UX requirements — describe each screen state (loading, empty, populated, error), (4) business logic — rules, calculations, validations, (5) API requirements — endpoints needed with request/response shapes, (6) data model — new fields, tables, or modifications needed, (7) analytics events to track, (8) QA test scenarios (happy path + edge cases), (9) feature flag strategy if applicable. Be specific enough that two engineers reading this would build the same thing.

Write release notes for our latest product update. Changes shipped: [list features, improvements, and bug fixes]. Target audience: [customers / internal team / both]. Write 3 versions: (1) customer-facing release notes — friendly, benefit-focused language, grouped by theme (New, Improved, Fixed), with brief descriptions that explain why each change matters to them, (2) internal release notes — more technical detail for support and sales teams, including talking points for customer questions, (3) a marketing-style announcement — 2-3 paragraphs highlighting the headline feature for blog or email. Each version should serve its audience without jargon mismatches.

Help me write a business case for investing in technical debt reduction. The technical debt: [describe — what it is, how long it has accumulated]. Impact on the team: [describe — slower development, more bugs, difficulty hiring, etc.]. Impact on users: [describe — performance, reliability, missing features]. Create: (1) a plain-English explanation of this technical debt for non-technical stakeholders, (2) quantified cost of doing nothing — sprint velocity loss, bug rate, engineer attrition risk, (3) the proposed investment — what we would do, timeline, and team needed, (4) expected ROI — velocity improvement, reliability gains, future feature velocity, (5) a phased approach that balances debt reduction with feature delivery, (6) risk of continued inaction. Make this persuasive for a CEO who only wants to talk about features.

Help me plan next quarter's product roadmap. Current product: [describe]. Key metrics: [list and current values]. Company goals for the quarter: [describe]. Feature requests and ideas: [list everything — from customers, sales, engineering, leadership]. For each item: (1) estimate impact on our key metrics (high/medium/low), (2) estimate effort (S/M/L/XL), (3) rate urgency and strategic alignment. Then: (4) apply a RICE or ICE framework to rank everything, (5) recommend what fits in a quarter for a team of [size], (6) identify what to say no to and how to communicate that decision, (7) flag dependencies and sequencing constraints. Present the final roadmap as themes, not just a feature list.

I have these features competing for development resources: [list 8-12 features with brief descriptions]. My team size: [number]. Quarter duration: [weeks]. Key business metric: [describe]. Help me prioritize: (1) score each feature using RICE (Reach, Impact, Confidence, Effort), (2) create a 2x2 matrix of impact vs effort, (3) identify "quick wins" (high impact, low effort), (4) identify "big bets" (high impact, high effort — do we have capacity?), (5) identify "money pits" (low impact, high effort — kill these), (6) recommend the final prioritized list with a cut line showing what fits this quarter and what does not. Include a communication template for stakeholders whose features did not make the cut.

Help me set OKRs (Objectives and Key Results) for my product team. Product: [describe]. Company-level objectives: [list]. My team: [size and roles]. Current product metrics: [list]. Create: (1) 3 product objectives for the quarter — ambitious but achievable, (2) 3-4 key results per objective — specific, measurable, time-bound, (3) for each key result, the leading indicators we should track weekly, (4) the initiatives (projects/features) that drive each key result, (5) a scoring rubric (0.0-1.0) with what each score range means, (6) common OKR pitfalls to avoid for product teams. Objectives should inspire. Key results should be uncomfortable but not impossible. A 70% achievement rate is healthy.

Analyze the competitive feature landscape for my product. My product: [describe key features]. Competitors: [list 3-5 with brief descriptions]. Create: (1) a feature comparison matrix across all competitors for [list key feature categories], (2) identify our feature advantages — what we do that no one else does, (3) identify our feature gaps — what competitors offer that we do not, (4) for each gap, assess: is this a real customer need or just a competitor's bet?, (5) recommend which gaps to close (must-have), which to ignore (not our market), and which to leapfrog with a better solution, (6) identify a feature differentiator we could build that no competitor has.

Write a product strategy one-pager for [product or product area]. Current state: [describe]. Market context: [describe]. Vision: [where we want to be in 2 years]. Create a single-page strategy document with: (1) the problem we are solving and for whom (2 sentences), (2) our strategic bet — the one big thesis driving our direction, (3) what we will do (3-5 strategic pillars), (4) what we will NOT do (equally important), (5) how we win — our sustainable competitive advantage, (6) success metrics — how we know the strategy is working, (7) key risks and assumptions. One page maximum. Every word must earn its place.

Help me prepare for sprint planning. Sprint duration: [weeks]. Team: [number of engineers, designers]. Backlog items ready: [list with brief descriptions and story points if estimated]. Sprint goal: [describe]. Create: (1) a recommended sprint goal statement that is specific and measurable, (2) a recommended set of stories to pull in (considering velocity of [points/sprint]), (3) a dependency check — are there blockers or external dependencies to resolve before committing?, (4) a capacity adjustment for known absences or meetings, (5) a risk assessment — what could go wrong and contingency plans, (6) discussion prompts for the sprint planning meeting.

Design a sprint retrospective for my team. Sprint: [describe what happened — what shipped, what didn't, any incidents]. Team mood: [describe — frustrated, energized, burned out, neutral]. Duration: [60/90] minutes. Create: (1) an icebreaker or warm-up that matches the team mood (not a generic one), (2) a structured format for this specific retro (choose from: Start/Stop/Continue, 4Ls, Sailboat, Timeline — pick the most appropriate for our situation and explain why), (3) specific prompts for each section tailored to what happened this sprint, (4) a way to prioritize action items (not just list them), (5) accountability — how to assign and track retro actions so they actually happen. Include facilitation tips for if the conversation gets stuck or heated.

Our daily standups are not working well. Current problems: [describe — too long, not useful, people zone out, status reporting instead of collaboration, etc.]. Team size: [number]. Current format: [describe]. Redesign our standup: (1) a new format that addresses our specific problems, (2) a strict time limit with enforcement mechanism, (3) questions to ask that surface blockers quickly (not "what did you do yesterday"), (4) how to handle topics that need longer discussion (parking lot strategy), (5) an async alternative for days when a meeting is not needed, (6) metrics to track whether the new format is working. Include what to do if the new format stops working in a month.

Create a bug triage framework for my product team. Current bug volume: [approximate]. Current process: [describe or say "no formal process"]. Product: [describe]. Create: (1) a severity classification system (P0-P4) with clear definitions and examples for our product, (2) response time SLAs for each severity level, (3) a triage meeting format — frequency, attendees, agenda (15 minutes max), (4) escalation criteria — when to wake someone up, when to notify leadership, (5) a template for bug reports that contains everything needed to diagnose, (6) a weekly bug metrics dashboard — what to track and what signals a systemic problem.

Create a product launch checklist for [feature/product]. Launch type: [GA / beta / phased rollout / internal only]. Impact: [describe who is affected]. Create a comprehensive checklist organized by team: (1) Engineering — feature flags, monitoring, rollback plan, load testing, (2) Design — final assets, documentation, onboarding flows, (3) Product — release notes, feature documentation, success metrics dashboards, (4) Marketing — announcement, blog post, email, social, (5) Sales — talk track, demo environment, FAQ, (6) Support — knowledge base articles, escalation path, known issues, (7) Legal/Compliance — if applicable. Include a launch day runbook — who does what, in what order, and how to communicate go/no-go.