1. Explain the problem before proposing features
Describe what happens today and why it is difficult. “Our team copies order details between three systems” is more useful than “we need a dashboard.” Include who performs the work, how often it happens, and which mistakes or delays matter most.
If the product is new, explain what people use instead and what assumption you want to test. Separate what you already know from what you hope to learn. You can bring uncertainty to the conversation; it is better to name it than to hide it inside a confident specification.
2. Name the audience and the essential journey
List the people who use or operate the product. Customers, administrators, managers, and partners may need different permissions and workflows. For the first release, describe one journey from start to finish, including the outcome the user should receive.
For example: an employee submits a purchase request, a manager approves or declines it, and the employee sees the decision. Then identify exceptions: the manager is away, a request is incomplete, or the employee needs to correct it.
3. Identify the systems and information involved
List existing applications, data sources, accounts, and integrations. Note whether technical documentation or test access is available. Describe any records that need to be migrated and whether you have a representative sample.
Keep passwords, private customer records, and other sensitive information out of the initial brief. Describe the category of data and its handling requirements first; access arrangements can be agreed later.
4. Separate priorities from preferences
Divide requirements into essential for launch, useful later, and still undecided. A requirement is essential when removing it prevents the main workflow from working or creates an unacceptable operational problem. A preferred chart layout or secondary export format may be a later decision.
For a startup, the MVP development approach helps keep the first release focused. For an existing business, begin with the workflow that creates the most repeated friction.
5. State constraints and success criteria
Share a budget range if you have one, the reason for a deadline, who can make decisions, and any platform or procurement constraints. A launch date tied to an event is different from a general preference for a quick release.
Define success in observable terms: a user can complete a booking, an administrator can resolve a failed update, or a team can produce a report without manual reconciliation. Avoid making a business outcome depend on software alone when adoption, staffing, or sales work also matters.
A project brief outline you can copy
Project name: Who it is for: Problem or opportunity: How the work happens today: Essential first-release journey: User roles and permissions: Existing tools and integrations: Data to create, use, or migrate: Must have for launch: Can wait until later: Budget context: Target timing and reason: Decision maker and available team: How we will judge success: Launch, support, and handover needs: Open questions:
What happens after the brief?
The brief starts discovery; it is not a complete scope or a fixed-price contract. The next step is to review assumptions, identify dependencies, define acceptance criteria, and agree on milestones. Design and technical investigation may reveal decisions that the initial brief could not settle.
Read what drives a software estimate to understand how those choices affect effort. Then use our project brief planner to create a starting draft. The planner runs in your browser; nothing is sent automatically. You choose when to copy, download, and share it with Xak.