Last week we ran live product demos at the Tech in Asia conference in Jakarta. Live, not recorded, on real software. A few people asked afterwards how we ship enterprise systems without the six-month silence followed by a launch that everyone dreads. The answer is not a methodology. It is a unit of work.
We ship in slices, and every slice has to be observable.
What a slice is
A slice is the smallest piece of software that produces one outcome for one beneficiary, end to end. Not a component, not a screen, not "the backend for phase two." One person, one thing they can now do, from trigger to done.
For a telecom-expense tool, a slice might be: a finance analyst uploads one carrier contract and sees its plan details extracted into a searchable record with a source reference. Nothing else. No dashboard, no chatbot, no recommendations yet. But the analyst can do something on Friday that they could not do on Monday, and they can see it.
The loop
Every slice runs through the same five steps. I have written them up in more detail on the process page, but the shape is simple.
- Promise. Before any code, a short card: the outcome, the scope, what evidence will show it works, who will verify it, by when, what it depends on, and what would make us stop.
- Back-brief. The engineer explains, in their own words, the user's problem, the approach, what will be tested, and what will not change. If the explanation does not match the promise, we have caught the misunderstanding before it cost a week.
- Build. Small enough to inspect and reverse. Linked to the promise. AI-generated code treated as untrusted until reviewed, like any other contribution.
- Verify. The primary workflow, the likely failure, the permission case, and the "what if the integration is down" case. Recorded with the exact environment and data used, and with what was not checked.
- Demo. To the person who will use it, in a real scenario, including a failure. Then a disposition: accept, accept with conditions, or go again.
Why observable matters more than small
Small is easy to fake. A team can ship tiny pieces of nothing for months. Observable is the discipline: at the end of the slice, a specific person can watch a specific outcome happen. If they cannot, the slice is not done, however much code was written.
This is also what makes the demos possible. When every slice has already been shown to a user in a real scenario, demonstrating in front of a conference audience is just doing it again in a bigger room.
What it changes for the client
You see progress every week or two, on your data, with your people. You can stop, redirect, or expand at any slice boundary without losing work. And you never arrive at a launch day, because there is no launch day. There is a slice, then another, and at some point the team notices the work has moved into the tool.
If you are commissioning software
Ask the builder what the first slice is, who benefits, and how you will observe it. If the answer is "the data model and authentication," ask again. Those are ingredients. You are buying outcomes, one at a time.
When a slice is not ready
A slice does not start until it has a beneficiary, a confirmed requirement, a starting state, its acceptance and failure scenarios, a named verifier with a date, and the access and data it needs. If any of those is missing in a way that would change the design, the slice waits and the gap becomes this week's work. That rule is what stops the loop from becoming a treadmill of half-started pieces.
One beneficiary, one outcome, observed by a real person: that is the unit of shipping.