Why Most Briefs Fail
Most product briefs fail not because founders don't try, but because they describe what they want the product to do rather than why, for whom, and to what standard. Engineers can build to a specification. They cannot build to a mood.
A good brief is not a design document. It is a decisions document. It locks the answers to the questions that would otherwise derail the project mid-sprint.
The 7-Part Brief Structure
1. Problem Statement (2–3 sentences)
Describe the problem the product solves and for whom. Be specific. "Founders waste time" is not a problem statement. "Early-stage founders spend 4+ hours per week manually reconciling Stripe payments with their accounting spreadsheet because no tool connects the two without an accountant" is a problem statement.
2. Target User
One primary persona. Name them. Describe their context, their technical sophistication, and the device they're most likely using. Resist the urge to list six personas. It dilutes every downstream decision.
3. Core User Action
The one thing a user must be able to do for this product to succeed at version one. Everything else is secondary. Write it as a user story: "As a [user], I can [action] so that [outcome]."
4. Success Criteria
How will you know the sprint was successful? Not "the app is built," which is a delivery criterion, not a success criterion. Success criteria are measurable: "A new user can complete the core action within 3 minutes without instructions" or "50% of waitlist users activate within 7 days of launch."
5. Scope (In / Out)
List what is explicitly in scope and what is explicitly out of scope. The out-of-scope list is as important as the in-scope list. Common out-of-scope items for MVPs: admin panel, analytics dashboard, multi-language support, custom email templates.
6. Technical Constraints
Tech stack preferences or requirements, existing systems the product must integrate with, deployment target (Vercel, AWS, etc.), any performance requirements (e.g., mobile-first, sub-3-second load).
7. Timeline and Handoffs
When does the sprint start? What is the definition of done? Who reviews and approves deliverables? What does the handoff process look like?
Brief Anti-Patterns
"We want it to look like Airbnb but simpler." Visual references are fine. "Like Airbnb" as a brief is not. Reference specific interactions or patterns, not whole products.
"We'll figure out the details in the sprint." Details are what get figured out in the sprint when the brief is too vague, which is expensive. Figure out what you can before the sprint starts.
"The brief is in this 40-slide deck." A brief buried in a pitch deck is not a brief. Extract the relevant decisions into a 1–2 page document. If a developer can't read it on a phone in 5 minutes, it's too long.
What a Good Brief Produces
A tight brief produces:
- A realistic estimate (not a range you can't plan around)
- A shared understanding of scope before a single line of code is written
- An audit trail for scope disputes
- A faster start on day one because no one is asking foundational questions
Kastling's Brief Process
When founders book a call at kastling.co, we walk the brief through 9 questions that map directly to the framework above. The call takes about 30 minutes. It produces everything our team needs to scope the build and start on day one, with code in your repo and IP transfer at the end.
FAQ
Q: How long should a product brief be?
1–3 pages. If it's longer, it contains too much context and not enough decision-making. If it's shorter, it's missing essential information.
Q: Should the brief include wireframes?
If you have them, include them as reference, not as specification. The brief defines what and why; wireframes show one possible how.
Q: Who should write the brief?
The founder or product lead who has decision authority. Not a team committee. Briefs written by committee are briefs that describe everyone's preferences rather than the product's requirements.
Q: What happens if requirements change after the brief?
Change requests should go through a formal scope change process. A good agency will handle this as a mini brief, documenting the change, its impact on timeline and cost, and getting explicit approval before proceeding.