A project can have a convincing roadmap and still be built around a misunderstanding. The customer may use a different word for the thing you are modelling. An approval may depend on someone who was never invited to the workshop. The data you need may exist only in a spreadsheet on a shared drive.

We prefer to discover those problems while the work is easy to change. That is why the first release should feel smaller than the ambition behind it. It needs to put a real piece of work in someone’s hands and give the team something concrete to learn from.

There is a useful question for an early planning meeting: what could someone complete with the first version, without a developer standing beside them? If the answer is that they can look at several unfinished screens, the scope needs another pass.

Start with a job someone already does

Consider a transport operator replacing an email-based booking process. The full plan might include customer accounts, dispatch, route planning, invoicing and tracking. Each item sounds necessary. Together, they could postpone useful feedback for months.

A first release could let one existing customer submit a booking for one route, let a dispatcher accept it and return a confirmation with a reference number. That is a complete journey with a deliberately narrow audience.

The team can then watch what happens. Does the customer know the collection address at the point of booking? Does dispatch need a purchase-order reference? Can someone correct a mistake without creating a duplicate job? These questions are much easier to answer with a real booking in front of you.

Choose a workflow that happens often enough to observe. A rare annual process may be commercially important, but waiting a year for feedback makes it a poor first learning opportunity unless you can rehearse it with representative records and the people who perform it.

Make the uncertainty visible

Write down the assumption the release is meant to test before adding features to it. In the booking example, it might be: customers can supply enough information for dispatch to accept a job without a follow-up email.

That statement gives the team a way to judge the work. A beautiful form that still needs three clarification calls has exposed a problem. It has also produced useful evidence: perhaps the product needs to support a conversation, or perhaps the required fields are wrong.

DORA’s guidance on small batches describes shorter feedback cycles as a way to test assumptions and adjust direction. Our practical interpretation is to make each early release answer a business question that can change what the team does next.

Avoid choosing the easiest feature simply because it can be finished quickly. Changing a logo or adding a static dashboard may produce a satisfying demonstration without teaching you much about the difficult part of the product. Pick a small job that crosses at least one uncertain boundary: between teams, between systems or between the software and its users.

Reduce the audience before reducing care

There are several ways to make a release smaller. Support one branch before every location. Start with one type of order. Invite a small group of people who can give specific feedback. Keep a complicated exception on the existing process until the new path is understood.

These choices need to be visible. Tell users which work the release supports and where to send everything else. If the software silently accepts a job it cannot handle, the apparent simplicity has moved the complexity into someone’s working day.

Basic care still belongs in the first release. People should be able to access only their own information. Failed submissions should be recognisable. Records need to survive a restart. If something goes wrong, the team needs a way to find the affected job and help the user.

The same applies to a manual step behind the scenes. It can be sensible for a dispatcher to approve requests manually before automating the rules. Give that step an owner, a realistic workload and a visible queue. Otherwise, the pilot may look successful because an engineer is quietly doing unpaid operations work every evening.

Agree what counts as evidence

Before releasing, make a short agreement with the people involved:

  • Name the user and the job they should be able to complete.
  • State which cases are included and which remain on the existing process.
  • Choose an observable result, such as a booking accepted without clarification.
  • Decide how failures will be recorded and who will respond.
  • Book a review with someone who can change the next release’s scope.

Measure the whole task. A form submitted successfully is only the beginning if someone must then re-enter its contents into another system. Follow the record far enough to see whether the work became easier or merely moved to a different desk.

For a pilot, a modest sample can uncover mistakes without proving that the product works for every customer. Keep that distinction explicit. A route used by familiar customers may hide issues that appear when new customers arrive. The next release can deliberately broaden the conditions rather than treating a quiet pilot as universal validation.

Let the result change the plan

A team gains little from early feedback if every subsequent milestone is already treated as a fixed promise. Leave room for what the first release teaches you.

Suppose dispatch accepts most bookings but repeatedly corrects collection windows. The next useful change might be a clearer way to specify times. A more ambitious tracking screen can wait. The decision should follow the observed problem, even if it is less impressive in a slide deck.

Record the reason for that choice. A short note linking the change to the affected bookings helps colleagues understand why priorities moved. It also prevents the same debate from restarting when someone revisits the original roadmap.

Sometimes the first release reveals that the idea needs a larger change. You may discover that the data cannot support the promised experience, or that the proposed workflow solves the wrong person’s problem. Stop expanding that version until the team has addressed the finding. Early evidence is valuable partly because it gives you permission to avoid a much larger investment.

A useful brief for the first release

Bring one recent example of the work to the planning session. Walk through who touched it, what information they needed and where it waited. Mark the point where software could remove a delay or prevent a mistake.

Then describe the release in a short paragraph: who will use it, what they will complete, what remains manual and what the team expects to learn. Put the review date beside it. That gives everyone a concrete piece of work to discuss, build and challenge together.

For what happens after that first release reaches users, read Go-live is where ownership starts.