Unit of Flow as a Design Process

The initial problem

One of the early challenges in working on a strategy execution platform was that the original thinking around the product was heavily influenced by legacy operational models.

Strategy execution was being viewed through the lens of traditional project management:

• large initiatives,
• layered reporting structures,
• complex hierarchies,
• and disconnected operational abstractions.

The result was a system that quickly became bloated.

The further strategy moved away from execution, the harder it became for teams to understand:

• why work mattered,
• how decisions connected to outcomes,
• and whether execution was actually creating progress.

Rather than creating clarity, the system risked creating more organisational noise.

This became less of a product problem and more of a design process problem.

Stripping away complexity

To move forward, product and design began approaching the problem differently.

Instead of thinking in terms of initiatives, epics, and disconnected tasks, the team started thinking in terms of “units of flow”.

A unit of flow became the smallest meaningful piece of work that contributed toward a measurable strategic outcome.

This changed how decisions were evaluated internally.

Rather than asking:

“How should this project be structured?”

the question became:

“What is the smallest measurable unit that moves strategy forward?”

That shift forced a radical simplification.

Complex planning structures started collapsing into smaller connected operational decisions.

Cross-functional work could then be linked together through nodes, allowing teams to understand how local decisions contributed toward larger strategic outcomes.

The focus moved away from managing work and toward understanding flow.

Dogfooding the process

As the process was dogfooded internally, something important emerged.

It became clear that execution should not be viewed as a traditional project-management system.

Execution behaved more like a series of strategic bets.

Every feature, interaction, workflow, or operational change represented a hypothesis:

• that a decision would reduce friction,
• improve alignment,
• increase clarity,
• or create measurable progress toward an outcome.

This fundamentally changed how design decisions were evaluated.

Design was no longer focused purely on interface construction or workflow management.

Instead, design became a process for creating measurable operational behaviour.

Strategic bets and KPI alignment

The introduction of measurable KPIs became critical.

If a team pursued a strategic bet, the KPI acted as an early signal:

• whether the bet was working,
• whether friction was being reduced,
• or whether the team needed to change direction.

This created an important side effect.

Alignment stopped depending on organisational hierarchy or reporting structures.

Teams aligned naturally because they were aligned around measurable strategic outcomes.

The KPI matrix created visibility between:

• decisions,
• execution,
• and outcomes.

Smaller cross-functional initiatives could remain autonomous while still contributing toward broader strategic direction.

Instead of enforcing alignment structurally, alignment emerged through shared visibility and measurable flow.

Design process over product thinking

The most important insight from this process was that the design methodology itself became more valuable than the original product assumptions.

By stripping away operational complexity and treating execution as measurable strategic flow, the team moved away from thinking about strategy execution as a traditional management system.

Instead, it was treated as an adaptive operational process:

• built around measurable bets,
• connected units of work,
• and continuous strategic feedback.

In many ways, the process became the product insight.

“Unit of flow” stopped being a framework for organising work and became a framework for reducing the distance between strategy, execution, and learning.