Spec Feature

Give a development team a feature specification they can build without relying on hidden assumptions.

Outcome

The development team receives a specification that states the customer problem, intended user, valuable outcome, scope, acceptance criteria, unknowns, and proof of success.

What Good Looks Like

The specification is clear enough to build without constant clarification. It explains what the feature does, who it serves, why it matters, and how the team will know it worked. Unknowns and exclusions are visible before estimation.

How To Do It

#	Step	Who
1	Identify the unmet customer need and its evidence.	Product lead
2	Define the observable change that would prove value.	Product lead
3	Write the users, scope, behaviour, constraints, and acceptance criteria.	Product lead
4	Review buildability and unknowns with development.	Product and development
5	Estimate and prioritise against other work.	Product lead
6	Hand off the accepted specification to development.	Product lead

Stop if: the customer need is assumed, success is not observable, material security or data constraints are unresolved, or developers cannot explain the acceptance criteria back in their own words.

The Prompt

Put this to work

Draft a buildable feature specification

Feature specification assistant

Copy this prompt. Paste into Claude, ChatGPT, or any AI assistant. The page context is already loaded — send it and get analysis tailored to your role.

You are a feature specification assistant. Help me turn evidence about one customer problem into a review-ready specification. Do not invent evidence, choose priority, or make unresolved product and engineering decisions for the team.

Ask for:

1. The intended user and the unmet need.
2. Evidence that the need is real.
3. The observable user or business change that would prove value.
4. Current behaviour and desired behaviour.
5. Constraints involving data, privacy, security, accessibility, compatibility, and performance.
6. Explicit non-goals.
7. Known dependencies and unknowns.

Then return:

- problem and beneficiary;
- proposed behaviour and user flow;
- scope and non-goals;
- acceptance criteria in observable terms;
- edge cases and failure behaviour;
- dependencies, assumptions, and open questions;
- a measurement plan tied to the valuable outcome;
- a product-and-development review checklist.

Mark every unsupported detail as UNKNOWN. End by asking the product lead and developer to confirm what is buildable, valuable, and still undecided.

Evidence It Worked

Measure	Target
Clarification questions from development during the build	≤ 3 per specification
Specified features shipped within the estimate	≥ 70%

These gauges test specification clarity and estimation quality. Beneficiary improvement still requires the feature's own outcome measure.

Dependencies

Customer-need evidence, a named product owner, development review, and known delivery constraints must be available.

Next

The source names build-feature as the next capability. It is not yet published.