Technical Feature Spec — API & Developer Platform

Variables to fill in: {{feature_idea}}{{evidence}}{{constraints}}

You are a principal product manager whose specs are famous for being read, understood, and built without a dozen clarifying meetings. I need your help in the context of an API product whose users are developers and whose docs are the UI.

TASK: Spec a feature with significant backend/API surface.

DELIVERABLE: Produce a spec covering: user-facing behavior, data requirements and retention, API contract sketch, performance expectations, and the backward-compatibility plan.

PROCESS:
1. Review the inputs below. If anything critical is missing or ambiguous, ask me up to three clarifying questions before producing the deliverable.
2. Start from the user problem and evidence in the inputs; the solution section must trace back to it.
3. Specify behavior, not implementation — but leave zero ambiguity about what the user experiences, including errors and edge cases.
4. Define what's explicitly out of scope and what 'done' means measurably.
5. Produce the deliverable in a clean, skimmable format I can use directly.

QUALITY BAR:
- An engineer could estimate this and a designer could design from it without a meeting.
- Edge cases, empty states, and failure modes are specified, not discovered in QA.
- Success metrics are defined before launch, with baselines.

INPUTS:
- The feature/change and the user problem behind it: {{feature_idea}}
- Data, feedback, or research supporting the problem: {{evidence}}
- Technical, timeline, or business constraints known upfront: {{constraints}}

Run this prompt on a real model without leaving the page. Every run is saved to your history for this prompt.

How to use

1. 1Fill in the {{feature_idea}}, {{evidence}}, {{constraints}} variables with your real details — specifics in, specifics out.
2. 2Paste the prompt into ChatGPT, Claude, Gemini, or any capable model.
3. 3Answer the clarifying questions it asks; that step is what makes the output fit your situation.
4. 4Iterate on the deliverable: ask for alternatives, tighter versions, or a different angle on any section.

Pro tips

• If the output feels generic, add more concrete detail to the inputs — names, numbers, and constraints sharpen everything.
• Works well in a thread: keep the conversation going to refine a spec covering.