A practical starting point
A product brief connects the business problem with the work a designer or developer needs to estimate. It should make priorities and uncertainties visible.
Describe the user, main task, required inputs and expected result. Include examples of success, failure and unusual cases. Mark integrations and data sources that still need to be confirmed.
Ask for an estimate that separates discovery from implementation. Agree how changes will be handled and who accepts the finished work. A clear brief reduces avoidable rework.
The practical guide below works through a hypothetical example, the decisions to check and a way to review the result. Use it to prepare questions for your own situation; adapt the exercise to the information and tools you are authorised to use.
Writing a Startup Product Brief includes naming the person who accepts the work and describing the checks they will use. Record supported devices, essential user flows and expected error handling. Use Customer Discovery to justify the priorities and MVP Planning to keep the first release focused. Changes can still happen, but they should lead to an explicit scope and timing discussion rather than an invisible expansion.
Read the practical guide
Writing a Startup Product Brief: a practical planning guide →Related topics
Start with a better brief.
Use the free planning tool, then tell us what you want to achieve.