By Tech Entrepreneur · 14 September 2026 · 2 minute read
Before you begin
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.
Describe one complete scenario
Write an example from the user’s point of view: a customer opens a booking page, chooses a service, requests a date and receives confirmation. Specify the input, output and person responsible for approval. Include the case where the date is unavailable or the customer leaves a required field blank. These details help a designer or developer estimate real behaviour instead of interpreting a list of feature names.
Make dependencies visible
List the product data, images, payment provider, email service and other systems the work would rely on. Mark each as available, proposed or unconfirmed. Do not treat an integration as complete because the provider has a logo on a diagram. Identify who can grant legitimate access and who maintains the source information. Ask the builder to separate discovery work from implementation when important dependencies remain uncertain.
Agree how completion is checked
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.
Put the notes to work
Prepare a brief with the free planning tool →