Feature Spec Template (Problem → Solution → Success)

This prompt creates clear feature specifications that connect user problems to proposed solutions. It includes success metrics, edge cases, and dependencies without unnecessary detail. The output helps teams align on what to build and why before committing to implementation.

GPT / Claude / Gemini3 variables

Prompt

Write a feature spec for {FEATURE}.

Input:
- Feature: {FEATURE}
- Problem it solves: {PROBLEM}
- Target users: {USERS}

Rules:
- Start with problem and user impact
- Include user stories with acceptance criteria
- Note technical constraints and dependencies
- Define success metrics
- List open questions

Output format:
OVERVIEW
- Problem statement
- Impact (why now, why us)

SOLUTION
- High-level approach
- Key user stories (As a [user], I want to [action] so that [outcome])
- Acceptance criteria per story

TECHNICAL CONSIDERATIONS
- Constraints
- Dependencies
- Edge cases

SUCCESS METRICS
- How we measure success
- Target outcomes

OPEN QUESTIONS
- Decisions still needed

Feature: {FEATURE}
Problem: {PROBLEM}
Users: {USERS}

Quick brief

Purpose

Write feature specs that engineers and designers can actually build from.

Expected output

A structured spec containing: problem statement with user impact, proposed solution at high level, detailed user stories with acceptance criteria, technical considerations and constraints, success metrics, dependencies, and open questions for discussion.

Customize before copying

Replace these placeholders with your own context before you run the prompt.

{FEATURE}{PROBLEM}{USERS}

Works well with

GPT

Claude

Gemini

Variations

Add mockups or wireframe descriptions.

Include technical design details for engineering.

Make it lean (one-pager for simple features).

Add competitive analysis section.

What this prompt helps you do

When to use it

Use before starting significant features, when proposing new functionality, or whenever cross-functional alignment is needed. Essential for product managers, technical leads, or anyone translating user needs into technical requirements.

How it works

The prompt structures specs around: problem definition, proposed solution, user stories, acceptance criteria, technical considerations, success metrics, and open questions. This ensures teams understand context, scope, and constraints before building.

Best practices

Write specs before designing or coding. Include designers and engineers in early review. Start with problem and impact, not solution. Define success metrics upfront. Document decisions and tradeoffs made during scoping.

Common mistakes

Writing implementation details without explaining the problem. Not defining success metrics. Leaving edge cases undocumented. Forgetting dependencies on other teams. Making specs too long or too vague.

What you should expect back

Limitations

Can't replace collaborative refinement with teams. Specs will evolve during implementation. Works best for features with clear scope. May need iteration based on technical feasibility discovery.

Model notes

Compatible with all major models. GPT creates well-organized structures. Claude often includes better edge case coverage. Gemini sometimes surfaces creative solution angles. Works for any product type.

Real-world applications

Product managers use this for feature planning. Tech leads use it for technical design docs. Designers use it for understanding requirements. Startups use it for MVP definition. Enterprise teams use it for stakeholder alignment.

How to tell if it worked

Successful specs mean teams can start work without major questions, scope creep is minimal during implementation, and delivered features meet defined success criteria. If teams constantly ask clarifying questions, the spec was too vague.

Where to go next

Use Technical Explainer for complex technical sections. Pair with Compare and Pick when evaluating solution approaches. Follow with Postmortem Template if launch reveals issues.

Appears in collections

Startup MVP Builder (Ship Fast, Learn Faster)

Build and launch your first version in weeks, not months. Validate before perfecting.

Turn product ideas into clear specifications that engineering can build without constant clarification meetings.

7-Day Study Plan (Realistic, Not Delusional)

Build a study plan that assumes you're human and get tired.

Landing Page Copy Audit (Fix Confusing Text)

Improve website copy so users understand it in 5 seconds instead of leaving.

Meeting Agenda (Clear Outcomes, Not Generic Lists)

Create agendas that make meetings actually productive.

Content Strategy Planner (Audience-First, Goal-Driven)

Design content strategies that attract, engage, and convert target audiences.