Business outcome
What should become faster, safer, simpler or commercially possible after this software exists?
Free planning resource
Clarify the problem, people, first release and constraints before asking for estimates. A useful brief does not need technical language—it needs specific business context.
Download the plain-text templateUse it for
The eight sections
What should become faster, safer, simpler or commercially possible after this software exists?
Who uses it, what are they trying to do, and what access or permission differences matter?
How does the work happen today? Include spreadsheets, messages, approvals, hand-offs and known pain points.
What is the smallest complete journey that would deliver useful evidence or operational value?
What existing systems, APIs, files, payments, identity providers or reporting tools must connect?
Note privacy, security, compliance, migration, offline use, deadlines and critical dependencies.
How will you know the product is useful—time saved, errors reduced, adoption, completion or revenue?
Who gives feedback, who approves scope and budget, and how quickly can the team answer questions?
Before requesting a quote
Describe what needs to change and why it matters before prescribing every screen or technology. A product team should be able to question the approach while protecting the commercial outcome.
Separate the first useful release from future ideas. This makes estimates more meaningful and gives the team a clear way to test whether the product is solving the right problem.
Include examples of the current process. Screenshots, forms, spreadsheets and anonymised sample data often explain more than a long feature list.
Have a draft already?