SousMeow
Software & Product Intermediate Available now Free

Write a Feature Spec

Capture a feature in a one-page spec before anyone builds.

A fuzzy feature can turn into weeks of guessing once code starts. This Cookbook helps you lock the problem, the user, must-haves, non-goals, acceptance checks, and a ship-ready checklist before implementation. Enter only facts your team already knows; every prompt is told not to invent engineering hours, legal requirements, or product history.

Made for
Solo makers and small product teams writing down a feature before building
You leave with
problem brief, users, must-haves, non-goals, acceptance checks, and a ship-ready checklist
Time
about 50 minutes
Steps
6 guided steps
Requires
any AI you already use (a free chat account is usually enough); sample answers included where available
Completed runs
214 (demo metric)
Average rating
4.7 / 5 (demo metric)

Also in Start Here Selected by SousMeow Recently Added Deep Workflows

Start free to begin

Have an account? Sign in.

Stages

3 stages in sequence
  1. 1

    Scope

    Name the problem and who benefits.

    2 steps
  2. 2

    Spec

    Lock must-haves and non-goals.

    2 steps
  3. 3

    Ready

    Acceptance checks and ship checklist.

    2 steps

Workflow steps

6 steps · completed in order

Stage 1: Scope

  1. 1

    Name the problem

    Turn the feature idea into a plain problem brief with constraints and unknowns.

    Teams often start by describing the solution and skip the pain. This step anchors the feature in a real problem before anyone debates screens. Common mistakes: inventing usage metrics, adding legal or engineering estimates, or turning a small feature into a platform. Need help if the answer guesses? Retry and say "mark missing facts as unknown." You are ready when the problem can be repeated without extra context.

    • Problem is clear The pain is understandable without reading the solution list.
    • No fake certainty Missing facts are marked as unknown instead of guessed.
    • Feature stays one sentence The feature name and job are visible in a single sentence.
  2. 2

    Name who benefits

    Identify the primary user, situation, benefit, and evidence limits.

    A feature for everyone is hard to build and harder to judge. This step picks the first user so scope has a center. Common mistakes: naming every possible customer, inventing personas, or claiming research you have not done. Need help if the AI writes a fictional profile? Retry with "use role-level facts only." You are ready when the spec says who gets relief first.

    • Primary user is specific The first beneficiary is a concrete role or segment, not "all users."
    • Benefit follows the problem The benefit answers the pain named in the problem brief.
    • Research is not invented The answer does not claim interviews, metrics, or market proof you did not provide.

Stage 2: Spec

  1. 3

    Write must-haves

    Convert the idea into required behaviors, control rules, and edge cases.

    Must-haves are the line between a useful first version and a wishlist. This step turns requirements into buildable behavior without pretending to know the implementation. Common mistakes: mixing maybes with requirements, adding analytics or admin tools, or forgetting edge cases like empty states. Need help if the list balloons? Retry with "only first-version must-haves." You are ready when every item is needed for the stated problem.

    • Requirements are first-version The list contains only needed behavior, not stretch ideas.
    • User control is explicit The spec says what the user can choose or change.
    • Boundaries stop guessing The answer blocks invented implementation, pricing, or legal details.
  2. 4

    Write non-goals

    Draw the scope boundary and park tempting ideas for later.

    Non-goals protect the build from hidden expansion. This step names what the feature will not do so the team can say no without reopening the whole idea. Common mistakes: writing vague non-goals, cutting something users actually need, or adding future features as promises. Need help if the AI sounds too harsh? Retry and ask for "firm but neutral scope language." You are ready when the boundary helps decisions.

    • Non-goals are concrete Each non-goal names a real excluded behavior or area.
    • Parked ideas are not promises Later ideas are framed as optional, not committed roadmap.
    • Boundary supports decisions The scope line would help reject a new request during build.

Stage 3: Ready

  1. 5

    Write acceptance checks

    Define observable checks, paths, edge cases, and evidence gaps.

    A spec is not build-ready until the team can tell whether the feature works. This step turns requirements into observable checks without prescribing code. Common mistakes: writing checks that test implementation details, ignoring empty states, or inventing analytics events. Need help if checks are vague? Retry with "use given/when/then-style observable behavior." You are ready when a teammate could test the feature manually.

    • Checks are observable A tester could verify each check without reading code.
    • Edge cases are covered The spec includes likely unusual states from the must-haves.
    • Missing facts stay visible The answer names what cannot be known yet instead of guessing.
  2. 6

    Pack the ship checklist

    Assemble the one-page spec, build checklist, review questions, risks, and ship decision.

    The last step should make the feature easier to hand off, not longer to argue about. This step compresses approved work into one page and calls out remaining decisions. Common mistakes: adding new requirements at the end, hiding unknowns, or turning a checklist into a launch plan with dates nobody supplied. Need help if the summary drifts? Retry and require every line to trace to an approved artifact. You are ready when the team can decide what to build next.

    • Spec fits one page The summary is compact enough to hand to a teammate.
    • Checklist is actionable Every checkbox can be verified from the approved spec.
    • Decision names blockers The final line says what must be confirmed without hiding unknowns.

Your information

8 details, answered once
  • Feature name Use the working name your team already uses. No clever renaming needed.
  • Product context What the product is and where this feature fits. Known facts only.
  • Who is this for? Name the first user who benefits. A role or segment is enough.
  • What problem happens today? Describe the current pain in plain language. Do not add metrics unless you have them.
  • Must-haves One required behavior per line. Keep wishes and maybes out for now.
  • Known constraints Technical, product, timing, or policy facts you already know. Write unknown if you do not know.
  • What signal means it worked? A user behavior, support signal, or simple product outcome. Avoid fake metrics.
  • Launch window Target release moment if known. If not known, say unknown.

Finished files

What you export when every step is approved

One Markdown file per approved step, plus kit.html (opens in any browser, offline) and a README of what you approved.

  • kit.html Offline HTML reader for every approved step
  • 01-name-the-problem.md Name the problem
  • 02-name-who-benefits.md Name who benefits
  • 03-write-must-haves.md Write must-haves
  • 04-write-non-goals.md Write non-goals
  • 05-write-acceptance-checks.md Write acceptance checks
  • 06-pack-ship-checklist.md Pack the ship checklist
  • README.md Manifest of what you approved
Nearby guided projects you can start next
Software & Product Available Pack a Release Checklist Turn a ship date into owners, work, and go/no-go checks. 4 steps · 40 min · Intermediate · 4.7 ★ · Free