Start with the problem
Write down what is difficult today, who experiences it, and what happens because of it. “Customers have to call to check an order” is more useful than “we need a dashboard.” It creates space to explore the right solution.
Name the first audience
A product may eventually serve several groups, but a first release benefits from a clear primary user. Describe what that person is trying to do, what information they need, and the tools they already use.
Separate essential from later
List the actions that must work for the first release to be useful. Put experiments and nice-to-have features in a separate list. This gives the team a practical basis for discussing scope instead of treating every idea as equally urgent.
Make constraints visible
Share the deadline, available budget, existing systems, and approval process early. Include access requirements and the person who can make decisions. These details shape the plan as much as the feature list does.
Agree on what done means
Define the review criteria before the build begins. A short checklist of user journeys, required integrations, and handover materials makes acceptance easier for everyone.
Have a project taking shape?
Build your project brief