Imagine receiving a brief for a customer portal: accounts, a dashboard, document uploads, notifications, and an administration panel. You could estimate every item and still have no clear answer to a basic question: what should become easier for the customer?
The list describes parts of a product. It does not explain why those parts belong together. Our view is that a useful brief should make the intended change clear enough that the team can challenge the list.
Start with the moment that needs to improve
Suppose customers currently email documents to an account manager, then call to ask whether anything is missing. The important problem might be uncertainty about the status of an application. A dashboard could help, but so could a clear request for the next document and a reliable confirmation that it arrived.
That distinction changes the first release. Instead of building a general portal, the team can focus on one application journey. The customer submits the right information, knows what remains outstanding, and understands what happens next.
Describe the current process using a real example, with identifying details removed. Include what the customer does, what employees do behind the scenes, and where the process stops. This gives engineering something more useful than a collection of interface nouns.
Write the constraints beside the ambition
A product brief should also explain what cannot casually change. Perhaps an existing system remains the source of application status. Perhaps customers need to resume work across devices. Perhaps an employee must review a submission before it advances.
These details shape the product. Discovering them after the interface is approved creates a second design exercise disguised as an implementation problem.
We would want the initial brief to answer four questions:
- Who needs to complete which task?
- What makes that task difficult today?
- What evidence would show the first release is useful?
- Which systems, people, or decisions does completion depend on?
The answers can be short. Precision matters more than document length.
Keep room to remove features
A clear brief makes subtraction possible. If a notification gives customers the information they need, a sophisticated reporting dashboard may not belong in the first release. If users must compare several applications, it might be essential.
The point is to connect each proposed feature to the task it supports. A feature that cannot survive that conversation needs a better explanation before it needs an estimate.
This also gives a partner a meaningful responsibility. They can help discover the smallest complete journey, explain the tradeoffs, and deliver it against agreed criteria. Otherwise, the engagement risks becoming an exercise in completing the original list, even when the team learns that the list was wrong.
Before your next planning session, try replacing the first page of features with one paragraph describing the customer change. Then ask which features are necessary to make that paragraph true.