When an organization starts a new system project, requests pile up quickly: every department adds what it needs, and every manager adds the report they want. The first release turns into a long list that takes months before anyone uses it.
The problem is that a system can only be judged by real use. The later that use comes, the later you discover what is truly missing and what was only needed on paper. In this article, we show how we define the scope of the first release, what waits, and how to say “later” without losing the people who asked.
One painful process, from start to finish
A good first release doesn’t cover a little of every department; it covers one process completely. We choose the process that causes the most delays, errors, or duplicated work today, and we build it from the first step to the last, so the team running it no longer needs side spreadsheets and messages.
Suppose a distribution company struggles with orders that get lost between its sales reps, the warehouse, and accounting. The first release here covers the order cycle: entry, approval, picking in the warehouse, shipping, and invoicing. It doesn’t cover payroll, assets, or purchasing, but it makes the whole order cycle run inside the system.
A release that covers half a process leaves the other half in Excel, so the team has to work in two places and enter data twice. That is one of the quickest ways to lose the team’s trust in the new system.
Choosing the process is itself a decision shared by the people who do the work, not by management alone. Management sees the problem’s effect in reports, while employees know where the hours really go.
How we decide what goes in
Once the process is chosen, we put every proposed item through four questions:
- Impact: does the process stop, or fall back to manual work, if this item is missing?
- Dependency: do other essential items depend on it? User permissions, for example, come before any approval screen.
- Risk: does it involve an unclear business rule or a sensitive calculation that must be tested early rather than discovered in the final days?
- Data readiness: does the data it needs exist, and is it clean? An item that depends on a messy customer list will stumble no matter how well it is coded.
An item that gets a yes to the impact question usually goes in. For an item that needs data that isn’t ready, deferring it may be the better choice, with data migration and cleanup starting in parallel until the data is ready.
Suppose the sales manager asks for sales rep commissions to be calculated in the first release. The order cycle doesn’t stop without commissions, but commissions depend on the sales data the first release will start collecting. The sensible decision is for them to wait, and to be calculated by hand from the sales report until the calculation is built.
What waits
Deferring is not refusing. It is a decision to build the item once real use provides more precise information about it. Three kinds of items usually wait.
Reports no one reads yet
Managers ask for many reports at the start, but the useful reports become clear after weeks of use, when people see real data. For the first release, a short list of the reports used to make decisions today is enough, along with a simple dashboard for the process itself.
For every report requested, ask: what decision will be made with it, and who will make it? A report without an answer can wait without anyone losing anything.
Rare exceptions handled manually for now
Suppose an order in a foreign currency comes through once or twice a month. Building full handling for it may cost more than it saves, so it can be handled manually with a written procedure until its volume is clear. What matters is that the exception is known and written down, not left to chance.
The same goes for special cases in discounts or in shipping to remote areas. Each one is logged in the backlog with a note on how often it occurs, and if it occurs more often than you expected, it becomes a candidate for the next release.
Integrations that can start manually
Connecting to the accounting system or an external shipping platform is useful, but it adds another party with its own schedule and constraints. At first, a file can be exported periodically and entered into the other system, with the automated integration built once the data and its format have settled. This deferral reveals what the integration actually needs: which fields move, how often, and who reviews the discrepancies.
How to say “later” without losing anyone
Someone who asks for an item and then hears “not now” worries that the request will be forgotten. So the decision alone isn’t enough; the person who asked needs to see where the request went and when it will be reconsidered.
A deferral that is stated openly is easier to accept than a vague promise. “It will be built once we see the volume of use, and we’ll review it at the monthly meeting” reassures the person who asked more than “we’ll look into it.”
- Tie every deferral to a written reason: missing data, the need to know the volume of use, or a dependency on an item that hasn’t been built yet.
- Keep a single backlog, ordered by priority and visible to everyone, with every deferred item listed under the name of the person who requested it.
- Set a date to review the backlog after launch, and make it a regular review that doesn’t get canceled.
- Explain to the person who asked what happens in the meantime: the temporary manual procedure, and who carries it out.
When the requirements for deferred items are clearly written, starting on them later is easier and doesn’t mean reopening the discussion from scratch. We covered how to write them in the article “How to write system requirements that cannot be misread.”
Acceptance and the first weeks of use
The first release is accepted when the whole process runs inside the system with real data, and when the acceptance criteria agreed for each user story are met. We prefer the testing to be done by the people who will use the system, on cases from their actual work, not on tidy test data.
After launch come the first weeks, when you see what was really missing, what was requested but not used, and what needs adjusting in the screens or the rules. Log every piece of feedback in the same backlog, prioritize it alongside the deferred items, and don’t build each one the moment it arrives. Before launch, agree on who collects the feedback and who prioritizes it, so it doesn’t reach the developers directly from every direction.
Suppose that in the second week the team notices warehouse staff writing out the picking list by hand every morning. That observation never came up in any meeting, and it may become the next release’s priority ahead of a report a manager requested before launch.
One sign that the first release has succeeded is that the team stops going back to the old spreadsheets on its own, and that improvement requests come from the users themselves, not from management alone.
A quick decision guide
Before you add an item to the first release, run it through these rules:
- It goes in if the chosen process can’t be completed without it.
- It goes in if leaving it out forces the team to work in two places for the same process.
- It goes in if essential items depend on it, such as permissions, customer data, and product data.
- It goes in early if it involves a sensitive calculation or an unclear business rule that needs testing.
- It waits if its data isn’t ready, and preparing that data starts in parallel.
- It waits if it’s a report and the decision it will inform hasn’t been defined yet.
- It waits if it’s a rare exception that can be handled manually with a written procedure.
- It waits if it’s an integration that can start with a periodic file export.
A good first release solves one problem completely, and the team actually uses it.
A small first release isn’t a compromise; it’s a way for everyone to learn from real use before the rest is built. Defining its scope is part of business analysis, not development. You can discuss your situation with the ITS team, and together, in a discovery session, we can identify the process your first release starts with.
Related serviceBusiness analysis and product consulting