The Lost Art of Slicing or Why Teams Forgot How to Deliver Incrementally

What happened to delivering value early and learning fast?

Somewhere between “strategic alignment” and “modular design”, both product and platform teams quietly reintroduced the worst parts of waterfall. Here is why that matters, and how systems thinking can help.

There was a time when teams prided themselves on delivering usable value in their first iterations. Not a polished product, but a meaningful slice, a thin, vertical cut that flowed across boundaries and proved the system could work. That discipline, once vital to agile, lean, and customer-centric teams, has faded.

Today, many platform teams, and increasingly their product-facing peers, have reverted to a multi-quarter, component-level delivery model. Projects stretch for months. Outcomes are designed up front. Interfaces are frozen too early. And most dangerously of all, value remains locked until “everything comes together.”

It never really does.

The Quiet Return of Waterfall

This shift is not always visible. On the surface, everything still sounds agile: teams run sprints, draw burn-down charts, and speak of MVPs. But dig deeper, and the planning reveals a familiar, dangerous pattern. Delivery is split into horizontal components: one team builds the backend, another focuses on front-end scaffolding, a third prepares internal tooling or APIs. The integration comes late, often only in the final weeks. Testing the system as a whole comes later still, usually at the cost of unplanned crunch time or delayed releases.

This is waterfall in disguise. Worse, it is waterfall with less clarity, because many teams no longer realise what they are doing. The rituals have changed, but the logic, “let us build everything first, then assemble it”, has returned.

Too often, this delivery style is paired with a growing scepticism, or even disdain, for agile principles. Teams proclaim that agility does not work, that velocity metrics are meaningless, and that alignment or feedback loops are a waste of time. Behind the rhetoric lies a more uncomfortable truth: laziness disguised as pragmatism. By rejecting measurement, collaboration, and early feedback, teams insulate themselves from accountability. They confuse convenience with efficiency, and mistake solo productivity for systemic progress.

The result is a vicious cycle. Component-led, feedback-starved delivery builds invisible pressure. Because nothing is shipped, leaders and teams grow impatient. To compensate, they take shortcuts, skipping testing and monitoring, ignoring integration, or postponing documentation. Still, nothing reaches production. The pressure intensifies. Teams work harder, not smarter. The loop continues.

Without system-wide visibility and early delivery, every shortcut amplifies fragility. Technical debt compounds. Confidence drops. And yet, the original issue remains: the team never shipped anything real soon enough to learn, adjust, or stop.

Systems Thinking: Flow, Feedback, and Friction

A systems thinker would frame this differently. Delivery is not about assembling parts, but about enabling flows, of data, of actions, of feedback.

A system is not a collection of components. It is a coherent interaction between inflows and outflows that sustains a purpose.

When teams fail to ship usable slices early, they break the feedback loop. They cannot observe the system in motion. They cannot ask the customer: Does this already solve your problem? Instead, they bet quarters of work on an imagined finish line, hoping it all comes together.

Worse still, they often discover too late that they did too much of the wrong thing. The great tragedy of deferred integration is not that it takes longer. It is that it blinds you to how little you actually needed to build.

The 20% That Delivers 80% of Value

In most systems, a small fraction of effort drives the bulk of user-perceived value. The art lies in finding that 20% early, by slicing vertically, not horizontally. That means delivering a basic but working version of the end-to-end experience, even if it is ugly, fragile, or manually glued together. From there, you gain two advantages:

1. Clarity: You can observe how the system behaves and identify where the friction lies.
2. Feedback: You can show users something real. Not a Figma mock-up. Not a Swagger schema. A working, albeit imperfect, flow.

With feedback, everything changes. Customers often say: “This is already good. Just fix these three parts.” Suddenly, the team realises they do not need 40% of the planned features. They only needed to solve a clear problem, in context.

This is the essence of agility. Not velocity. Not ceremonies. But the talent of stopping once enough value is unlocked.

Why Platform Teams Struggle Most

Platform teams, especially, fall into the trap of component-first thinking. Perhaps because their work feels abstract. Perhaps because they serve internal stakeholders rather than end-users. But too often, they imagine their work as a set of “capabilities” to be delivered before any integration takes place.

The result: months of internal complexity, orchestration logic, and infrastructure abstraction, before a single downstream team sees any benefit. When they finally do, the platform rarely fits. The interface was misaligned. The assumptions were off. The team must refactor or patch their way back to usefulness.

A better approach: identify the smallest, end-to-end path where the platform could deliver observable leverage to a real team. Build just enough to power that case. Get feedback. Let that feedback shape what next to build, not the roadmap assumptions written three quarters ago.

Resisting the Fear of the Incomplete

Why do teams avoid incremental delivery? Because it feels incomplete. It exposes rough edges. It reveals unknowns. Leaders fear it will make the organisation look slow or unfinished.

In reality, the opposite holds true. Showing early value builds confidence. It turns speculative roadmaps into adaptive paths. And it creates a rhythm where teams learn to think in terms of impact per slice, not effort per epic.

This is not about releasing junk. It is about orchestrating coherent, end-to-end increments. Each one small enough to ship, but complete enough to matter. Systems thinkers call this leverage. Designers call it value. Agile teams once called it common sense.

Starting the Shift

The path back to incremental delivery does not need to be complex. A practical beginning is to lean on small, demonstrable, and usable objectives. Each objective should be framed not as an internal milestone but as a visible change in customer behaviour. If a slice of work does not alter how users experience the product, then it is likely still too abstract or incomplete. The discipline lies in setting these behavioural objectives clearly, aligning teams to deliver them, and treating every increment as both a delivery and a learning opportunity. Results follow naturally once objectives are anchored in customer impact.

For example, when I worked on an automotive platform we mastered the lean approach to the point where user stories were reduced to very small chunks of business‑meaningful value. Each story title was written as a clear objective, much like in an OKR, and the acceptance criteria expressed the key results expected. This discipline ensured that every increment was not only technically complete but also demonstrably tied to a business outcome and user behaviour.

Rediscovering the Slice

We must teach teams again how to slice vertically, how to identify inflows and outflows, how to isolate the smallest end-to-end flow worth testing, how to listen to real users before finishing the work.

This is not a loss of ambition. It is its purest form: to build systems that work, matter, and evolve.

The first slice should do more than test a feature. It should teach the team how the system wants to behave.

And if it works well enough, you may never need to build the rest.

The automotive example stands in sharp contrast to the component-first anti-pattern described earlier. Instead of building abstract capabilities in isolation, every slice was grounded in a real business outcome. This difference highlights why vertical slicing is not a mere technique but a cultural choice: it forces the system into motion and aligns delivery with purpose.

The Role of Leadership

Leaders play a decisive role in making this shift possible. Teams cannot sustain vertical slicing if leadership rewards volume of output rather than impact of outcomes. Leaders must create the conditions for experimentation, allow incomplete but usable increments to surface, and hold the line on customer-oriented objectives. When leadership frames progress in terms of behavioural change and system value, slicing becomes a natural way of working rather than a fragile team-level habit.

In the end, the real art is not in building faster or bigger but in delivering that very first slice, small enough to ship, complete enough to matter, and powerful enough to show the system at work.