MVP: Test Value Before Expanding the Product

When budgets tighten, teams may remove features from a full product plan and call the remainder an MVP. Fewer features alone do not explain what the team will learn. A useful minimum viable product tests specific value for a specific user. Consider an illustrative internal maintenance request service, not a reported customer project.

01-Name the value you want to test

Lean Startup connects MVP development with a build, measure and learn cycle. Turn that into a practical question: can a structured request help reception staff route an incident to the right person? Increasing platform engagement does not describe the user's benefit. Identify who will participate, what they will complete, why they might choose this over calling and which behavior would indicate usefulness.

02-Choose the assumption that could invalidate the idea

GOV.UK's alpha guidance recommends concentrating on the riskiest assumptions. Perhaps employees cannot describe faults clearly, or operations cannot support another intake channel. Test what determines the solution's viability before refining colors or adding notifications. You may need to observe how incidents are recorded or coordinate a trial with the operations owner. Unanswered questions are not equally important: consider the consequence of being wrong and the difficulty of recovering.

03-Match the experiment to the question

A question about understanding the form may need only an interactive prototype, fictional data and clear tasks. A question about everyday usefulness may require a limited pilot coordinated with responsible staff. Clicking a button is different from delivering an actionable request. Observe task completion and friction, and record any help the moderator provides. That assistance might conceal a difficulty users will encounter when nobody is available to guide them.

04-Keep the essential task complete

Choose a small but complete path: create a clear request, route it and understand what happens next. Include what is necessary to test that path and defer unrelated features. Some steps may be manual during the experiment when this is appropriate and clearly understood, but record the effort involved. When handling real requests, clarify service boundaries, follow-up responsibilities and permissions. Limited scope does not remove these operational needs.

05-Agree on decisions before seeing results

Define the evidence needed and what would lead to continuing, revising or stopping. Compare actual behavior with assumptions and examine unsuccessful cases, not only convenient successes. A limited experiment can reveal an important obstacle without proving suitability for every branch or user. End the round with a specific next question. Keep deferred features separate from the experiment plan so they do not quietly become delivery commitments.

Your next step

Specify one useful outcome, a consequential assumption, an appropriate experiment and a decision the evidence will inform. MVP scope then follows the learning needed, while every additional feature must earn its place.