Next WrldThe meeting starts with a list.
A manager brings ten requests. Admin adds eight more. The most senior technician adds five that “can’t be missing”. In an hour there are already forty ideas for the new system.
Everything seems reasonable. Everything seems urgent.
And there most internal systems stall before existing, from excess scope. Trying to cover every case and satisfy everyone from day one. The project becomes so large it takes too long.
The useful question is where to start to be useful as soon as possible, without overshooting scope.
A useful first version covers the complete central journey even if simple, and leaves out almost everything else. Scope is cut by use, not opinions.
The central journey orders everything
Every internal system sustains a journey. A step sequence today done through loose messages, spreadsheets and people’s memory.
If that journey isn’t clear, every request sounds equally important. A report seems as urgent as recording work. Without a central journey, there is no way to order.
That is why the first work is agreeing on a sentence describing what enters on one side, which steps it crosses and what exits on the other.
With that sentence, cutting is easier. What completes the journey enters. The rest waits.
A first version has to carry a real case from start to finish without getting lost along the way.
The essential is recognized by use
How to distinguish the essential from the desirable without arguing tastes? By use frequency.
For each request ask: will it be used every day or only in specific cases? Does the person doing the work need it or only someone watching occasionally? If missing, does work stop or just become less comfortable?
The essential is used every day and, if missing, stops operations. The desirable is used occasionally and, if missing, can be solved another way for a while.
A report with many filters can look attractive in a meeting. But if the team doesn’t yet record work orderly, that report has nothing to stand on. Very detailed permission can look like order. But if there are doubts about who does what, the problem is missing clear owners, not permission.
Cutting by use forces looking at what daily work needs to avoid stalling.
What a first version must have
A well-posed first version looks modest and is demanding on the essential. It must allow four things.
Record. That the important stays in one place, with minimum data to understand what it is about. Without extra fields nor parallel spreadsheets.
Show state. That anyone answers in a minute: where is this? Pending, in progress, delayed, finished? This avoids repeated questions and blind decisions.
Assign owners. That it is clear who does what and by when. If nobody owns the next step, work stays still.
Keep minimal history. Enough to rebuild what happened: who asked, who took it and how it ended.
If it achieves those four over the central journey, it is already useful. If not, no additional feature saves it.
What is purposely left out
Saying what enters is half the work. The other half is saying what doesn’t, in writing and with reasons. Four groups should stay out.
Advanced reports. Dashboards with crosses and comparisons can wait. Seeing the work list and filtering by state suffices. When records are reliable, reports will make sense. Before they only show disorder with good presentation.
Fine permissions. Except sensitive information, there is no need to define who can see each field in each case. Simple, even rules suffice. Detailed control is justified as use grows, not before.
Premature automations. Notices for each situation or rules auto-deriving cases help when the process is already stable. Automating something changing weekly only generates rework.
Edge cases. That exception happening once in a while that someone wants to cover “just in case”. Designing for exception complicates the usual path. Better solve the frequent well and treat exception outside until it repeats.
Leaving out is saying “not yet”, seeking the least complexity needed to correctly solve the problem. That idea should accompany the whole project.
How to decide what enters
Cutting is done with three or four people knowing operations, reviewing the list with three questions.
Does this happen every week? If not, it exits the first version.
If missing, does work stop or is important information lost? If it can continue with a simple agreement for a while, it waits.
Does it help complete the central journey or just make it more attractive? If only more attractive, it waits.
This exercise usually lowers forty ideas to eight or ten decisions. The team starts thinking in use.
Name someone to guard scope. When a new request appears mid-way, that person asks: is it part of the central journey? Is it daily use? What happens if we leave it for later? Without that function, scope grows one “while we are at it” at a time.
How to know if it works
A first version isn’t measured by feature count. It is measured by order and relief.
Did people stop asking by message where each thing is? Is it known who owns each task without calling? Was less information lost than before?
If they improve in the first weeks, it works even if simple. If the team keeps working outside, something failed in the essential.
Define two or three concrete signals. For example: every request is recorded the same day, every task has visible owner, every close is documented. Little, observable, reviewable in a short meeting.
The first version ends when the central journey is used every day without detours, not when a screen list is delivered.
Complete example: maintenance company
A technical services company receives requests, builds work orders, assigns technicians, executes visits and then closes and bills.
Today it works with messages and a spreadsheet only one person understands. Requests are lost, nobody knows which technician is at each site and billing delays for missing information on what was done.
The central journey is said in one sentence: a request enters, becomes an order, is assigned to an owner, is executed and closes with enough data to bill. That is the whole first-version scope.
It would be like this. The request is recorded with minimum data: who asks, where, which reported problem and contact. Without long forms. Each accepted request generates an order with number, description, address, date and owner.
Each order has visible technician and date. The list shows pending, in progress or delayed. Technicians mark start and end and note what was done.
On closing there is record of what was done, which materials were used and whether something stayed pending. Admin sees what is ready to bill without calling to complete data. And each order keeps history: who created it, who took it and how it closed.
What stays out? Advanced reports by technician or failure type. Seeing weekly open and closed suffices. Fine permissions by client or field. Simple access suffices. Premature automations, like auto-assignment or notices on each change. Notifying on assign and close suffices. And edge cases, like special warranties or multi-visit jobs. They are solved manually while learning.
The daily entered. The occasional waited. Operations gained clear owners and less rework. And billing stopped depending on each technician’s memory.
Mistakes enlarging the first version
Three typical mistakes. Asking for everything together: each team adds theirs and nobody wants to stay out. It is avoided returning to the central journey and asking what blocks it today. What doesn’t block it, waits.
Designing for exceptions: much time on the rare case and little on the usual path. Invert the proportion and be excellent on the frequent.
Confusing the first version with the finished product: judging it as if it already had to solve everything. But an internal system evolves with use. It is a firm starting point, not an end point.
Asking for more doesn’t accelerate, it delays. Never assume more features mean better product, nor that building is always better than buying.
The criterion closing the discussion
Every scope discussion ends with the same question: does this have to be in the first version?
The answer is yes only if three conditions hold. It is part of the central journey. It will be used every week. If missing, work stalls or unrecoverable information is lost.
If any fails, it goes to a visible “later” list. It is reviewed when the first version is in use. What proves frequent use, enters. The rest waits.
Starting with the important cares for resources and respects team time. A useful system clearly sustains everyday work.
When the central journey works, the rest arrives in order and with sense.