Define the First Useful Version of a Business Application
· Daniel Șotropa
The first version most teams define is a feature list. The first version people actually adopt is a task they can finish without opening their email.
That difference decides whether a business application replaces the old way of working or becomes a second inbox next to it. This article is about how to find that task, what to include around it, and what to leave out on purpose.
Why “MVP” is the wrong word
A minimum viable product tests whether anyone wants a product. That is the right test for a startup with an idea and no customers.
A business application has neither problem. The users already exist. The workflow already runs, in a shared mailbox, a spreadsheet, a form that gets printed and re-typed, or an older system that nobody wants to touch. Demand is not in question. Replacement is.
So the success test is different. Not “did people show interest” but “on the first working day, did the people who do this job do it here instead of there”. Alistair Cockburn drew a similar line years ago between a walking skeleton, the thinnest version of a system that runs end to end through the real path, and an MVP that exists to test demand. The first useful version of a business application is closer to the skeleton, with one difference: the path it walks is a user’s task, not an architecture diagram.
Pick the one task
Take a services firm that wants a client portal. The wish list arrives quickly: submissions, document upload, status tracking, messaging, invoices, reports, a knowledge base, notifications, a mobile app.
Lay the client’s journey out left to right instead, the way Jeff Patton’s story mapping does it: submit a request, add the supporting documents, see where it stands, get the answer. That is the whole task. Everything on the wish list either sits on that line or hangs below it.
The first useful version covers the whole line, thinly. A client can submit, attach, follow and receive. Nothing more, and nothing less, because a version that stops at “submit” has not replaced anything. The client still has to email to ask where things are, which is the exact behaviour the portal was meant to end.
The task chosen this way tends to be smaller than the feature list and larger than the demo. That is usually the right size.
Include the exceptions and the staff side
This is the part that separates an adopted application from an abandoned one.
Ask the people who handle these requests today what they deal with by hand. For our portal the answer is nearly always the same three things: a submission with a document missing, a request filed under the wrong category, and an urgent case that has to jump the queue. Today each of those is an email thread and a judgement call.
If version one cannot absorb them, staff will handle them the old way, clients will learn that email is faster, and the portal will quietly become the place where the easy cases live. So the first version needs the staff screen as much as the client screen: a way to ask for the missing document without leaving the record, a way to re-categorise and keep the history, and a flag that moves a case to the front with a reason attached.
None of that is glamorous. All of it is what makes the task finishable inside the application. The exceptions are not scope creep; they are the scope.
Thin, but complete
Thin does not mean fake. A first useful version runs on real accounts, real data, a real notification when the status changes and a real place where the answer ends up, whether that is a document in the portal or a record pushed into the system the firm already uses.
This is where the walking-skeleton idea earns its place. Stubbing the login, the email or the integration to “get something in front of people” produces a demo that teaches you nothing about the two things that break first: identity and the handoff into existing systems. Build the real path once, narrowly. Widening it later is ordinary work. Replacing a stub later is a second project.
It also means the first version has an owner on the client’s side who can look at it and say “yes, this replaces the mailbox” or “no, and here is why”. Acceptance is a decision, not a feeling, and it needs a named person.
Set the appetite before the scope
Basecamp’s Shape Up makes the point bluntly: decide how much time the work is worth, then cut scope to fit, rather than estimate a fixed scope and hope. For a first useful version the appetite is set by two things the owner already knows. How long the organisation can run two ways of working in parallel, and how much support it can take on when the application goes live.
Write the exclusions down as carefully as the inclusions. “No invoicing, no reporting, no mobile app, no client messaging beyond status notes” is not a list of failures. It is the agreement that lets the first version ship, and it becomes the candidate list for the second.
The objection worth taking seriously
Thin first versions have a known failure mode: they never get widened. The budget ends, the skeleton stays, and a year later the portal handles submissions while everything else still lives in email.
That happens, and pretending otherwise would be dishonest. Two things reduce the risk. The first version has to be useful on its own terms, a complete task and not a slice of one, so that even if nothing follows it has still replaced something. And the second release’s candidates are agreed at the same meeting where the first release is accepted, while the people who used it for a week still remember what they reached for and did not find.
There is also the case where the honest answer is not to build. If a service the firm already pays for covers the task, a custom application adds maintenance without improving anyone’s day. That is worth saying before the scope is agreed, not after.
How this looks in practice
At Haiori an engagement starts with exactly this conversation: who will use the software, what task they need to complete, which systems it has to talk to and what the first release should include. The output is a defined first version with its users, workflow, priorities, acceptance criteria and exclusions written down, and then the build.
If you have a workflow in mind, a request that arrives by email, an approval that lives in a spreadsheet, a portal your clients keep asking for, tell us about it. The first useful version is usually clearer than the feature list suggests.