A minimum viable product should have a specific purpose in your business. Calling a long feature list an MVP does not make it small. A useful first release lets a defined group complete a meaningful job and gives you evidence about whether the proposed approach deserves further investment of time and effort.
Draw the start and finish
Define the trigger and the observable completion state. A hypothetical Brisbane furniture workshop might start with an approved customer brief and finish when a production slot is confirmed. That is narrower than managing the whole business, but more useful than a screen that merely stores enquiries. Include the handovers necessary to reach the finish. If somebody must still copy information elsewhere, show that manual step explicitly rather than presenting an incomplete workflow as finished.
Separate essential from convenient
Ask what fails if a proposed feature is absent for the first group of users. Workshop staff may need a shared order number, required dimensions and a visible scheduling decision. They might cope initially without a visual capacity forecast or branded customer dashboard. However, a simple amendment route could be essential because dimensions routinely change. Frequency matters, but the consequences of a missing step matter too. An uncommon cancellation may still need a workable path.
Choose a narrow audience
A first release can support one product line or one branch before it supports every variation. This reduces the number of rules you must prove at once. The tradeoff is that some people continue using the old process temporarily, so agree how mixed workflows will be handled. Do not select only the easiest users if they cannot reveal the uncertainty you are trying to resolve. Choose a representative slice with manageable exposure.
Define what the release will teach
Write a learning question alongside the delivery scope: can planners schedule standard orders without chasing missing information? Decide how you will observe that behaviour, who will collect feedback and when to review the results. A completed screen is delivery evidence; a completed business task is stronger evidence of usefulness. Your scoping next step is a one-page release boundary listing included jobs, excluded variations, manual work and the conditions for broadening access.
Planning checklist
- Name the first user group.
- Describe the full job from trigger to finish.
- List deferred features and temporary workarounds.