What should you define before building an MVP?
Define the user, the problem, the smallest useful workflow, and how you will evaluate the result. An MVP should test a specific assumption with a usable first release. Agree on integrations, access permissions, and exclusions before choosing the technology or estimating delivery.
A useful product begins with a specific person and a specific problem. “We need an app” describes a format. “Our customers cannot track an order without calling us” describes something a team can investigate and improve.
Start by mapping the current experience. Talk to the people who use it, watch where work slows down, and identify the smallest change that would make a meaningful difference. A focused first release teaches you more than a long feature list.
Agree on what success looks like before development begins. It might be fewer support calls, less time spent on a task, or a clearer checkout. Connect each feature to that outcome, test the assumptions, and use what you learn to shape the next release.
Example: a customer order portal
Suppose customers call your team to ask where an order is. A focused first release could let a customer sign in, see their own orders, and read the latest status. Inventory forecasting and a loyalty program can wait unless they are essential to testing that workflow. This is an illustrative planning example, not a reported client result.
- Identify the system that holds order data and who maintains it.
- Define which orders each customer can access.
- Plan what customers see when an update is delayed or unavailable.
- Compare support requests before and after the pilot using a consistent measurement period.
What belongs in the project brief?
Describe the current process, the people affected, the proposed first release, and what is outside its scope. Record the baseline you can measure today. Agree on acceptance criteria and who will decide whether the pilot is ready to expand.
- One primary user journey and a clear problem statement.
- Required integrations, data permissions, and operational constraints.
- A measurable outcome, an owner, and a review point.
Put this into your project brief
Write down the outcome you want, the people affected, and the constraints you already know. Include examples of the current process and questions you need help answering. These details make a first project discussion more useful.
Discuss your project