Building a System in Phases: Choosing What Goes Into the First Version

The question "what goes into the first version" almost always gets the same wrong answer: a bit of everything. A piece of the records, a piece of orders, a piece of inventory. It looks like the most cautious choice, and it's the one that can't actually be used: no process makes it all the way through, and the system ends up as one more thing to fill in on top of what people already do.

The right criterion is the opposite: the first version covers one complete process, start to finish, even if narrow. Better a little and complete than a lot and unfinished.

One Complete Process, With a Visible Result

"Complete" has a precise meaning: whoever uses it must be able to stop using the old method for that piece of work. If, after entering data into the system, people keep filling in the same old spreadsheet too, the first version isn't finished: it's double work, and it will be abandoned the moment the company has a hard week.

The result needs to be visible to someone: a document that goes out, a list that didn't exist before, a phone call that's no longer needed. It serves two purposes at once: it gives a concrete reason to use the system, and it proves the project is actually going somewhere.

Separating the Essential From the Nice-to-Have

Requests all arrive at once, and all urgent. You need questions that sort them out, and they're always the same four.

• Without this feature, does the process stop? If someone can do the same thing another way for now, it isn't essential.
• Who uses it, and how often? Features needed twice a year can stay manual for a long time, and often stay manual forever without anyone complaining.
• If it's missing, what actually happens? "We lose time" and "we can't invoice" aren't the same answer.
• Is it a feature or a habit? Sometimes a step gets requested only because the old tool couldn't do anything else.

Watch out for short requests that drag a whole world behind them: one extra status on a document can require permissions, alerts, history, and a rule on who can change it. The cost isn't measured by the length of the sentence describing it.

Dependencies That Can't Be Put Off

Releasing in phases only works if a few decisions are made right away, even when they concern parts that will arrive much later. There are only a few of them, and changing them later costs as much as starting over.

• Shared data: how a customer, an item, a job order is identified. If the first version invents its own numbering, the second will have to reconcile two archives.
• Who sees what: permissions are designed at the start even if, at the start, only three people use the system. Adding them later means reworking every screen.
• Where data that doesn't originate here comes from: if stock levels live elsewhere, decide now which system governs a quantity, even if the connection comes later.
• How history gets recorded: if you need to know who changed what, it has to be planned for right away, because it can't be reconstructed after the fact.

Example: A First Version for Job Orders

A company that installs systems wants a job-order management system. The wish list contains about twenty features. The first version picks four, but it goes all the way through.

The features left out aren't canceled: they stay listed, with the reason next to them and the condition that will bring them back in. That's the difference between postponing and forgetting, and it's also what lets you respond to whoever asked for them.

Acceptance Criteria: How to Say It's Done

"It works" isn't a criterion. A criterion is a sentence anyone can verify, written before development starts.

1. Describe the real case, not the feature: "the site foreman opens the job order from an accepted quote, assigns the crew, and fills in the job report from his phone, on site."
2. State who verifies it: whoever does that work every day, not whoever commissioned the project.
3. Include the messy cases: the canceled job order, the job report filled in without a network connection, the job whose date gets moved.
4. Establish which data is used for testing: real, recent data, because made-up data is always tidier than reality.

Requests That Come In Along the Way

They will come in, and that's a good sign: it means someone is using the system. The problem isn't receiving them, it's classifying them quickly.

• Bug: what exists doesn't do what was agreed. Fix it right away.
• Oversight: the process needs it and no one mentioned it. It gets evaluated for inclusion, and the delivery date moves accordingly.
• Improvement: makes the work more convenient. It goes on the list, not into the current version.
• Change of direction: the company has changed how it works. It needs to be discussed separately, because it isn't a request — it's a different project.

Without this distinction, every request becomes urgent and the first version never ships. It's the most common way these projects stall: not from a technical obstacle, but from accumulation.

What This Guide Doesn't Cover

This guide covers scope and sequence: what goes into the first version, what gets postponed, and in what order. The tests to run before relying on a system every day are a chapter of their own. And if the feature being evaluated involves an automated assistant, the criteria for judging it are different, because the result isn't predictable in the same way.