The Product Brief
Sneh writes a plan before it writes code, and asks you to approve it. Here is what is in it and why it matters.
Why there is a plan at all
Most of what goes wrong when software is built from a description is a misunderstanding that nobody noticed until the thing was finished. The brief exists to surface those while they are still cheap.
What the brief contains
- A summary — what the product is, in one or two plain sentences.
- The audience it serves.
- The features that make the first version worth using.
- The screens, and what each one is for.
- How data flows: what visitors submit, whether a database is needed, and which API keys you will have to supply.
- Assumptions — specifics Sneh invented, like names, prices or tone, that you should sanity-check.
- Out of scope — honest limits for this version.
The assumptions and out-of-scope lists are the two most valuable parts, and the two most often skimmed. Assumptions are where Sneh guessed. Out of scope is where it is telling you, before you find out yourself, what this version will not do.
Approving or changing it
Approve the brief and the build starts. Ask for changes and Sneh redrafts it. There is no penalty for going back and forth here, and it is much cheaper than rebuilding.
Read next
- Building your first appFrom a single sentence to a checked, deployed app — what happens at each step and what Sneh needs from you.
- How Sneh checks its own workBefore calling a build done, Sneh opens the app, walks through it on desktop and mobile, and reports honestly.
Did this miss what you needed? Email hello@sneh.ai — or browse the rest of the help centre.