Most organizations get it wrong when it comes to improving the flow of value through an organization. They observe something that correlates with high-performing organizations and then try to copy it — assuming it is the cause of success.
This confusion between correlation and causation is not unique to business. It appears everywhere around us.
It’s easy to find this phenomenon wherever you look. Commercial ads often make bold promises – as if buying a motorized toothbrush from company X would somehow help you win the Olympic games in curling (even without long fingers!).
We all know this; you won’t break any records by buying the same shoes as the world’s no. 1 sprinter. Still, our brains tend to jump to conclusions in search for more energy-efficient ways to succeed. It infers causation when there might be correlation at most.
Our brains are wired this way. In Thinking, Fast and Slow, Daniel Kahneman describes the mind as
“A machine for jumping to conclusions”
Why is that something evolution has rewarded?
If your life depends on making fast fight, flight or freeze decisions, then it makes sense. Jumping to a conclusion about the intent of a big tiger eyeing you on its breakfast menu can literally save your life. In many life-death situations doing something is better than doing nothing, even if causation evidence is lacking.
In product development we see a similar pattern. It is well known that smaller initiatives tend to move faster and contain less uncertainty.
But speed itself is not the real objective.
Product development is fundamentally a learning process. The goal is not to deliver what we already know the customer wants. The goal is to discover which problems are worth solving and which solutions actually address those.
Therefore, the real benefit of faster development is relevance. When you have an idea of a solution to a customer problem, the best way to validate the idea is to test with real users in their actual environment.
If it takes years to produce a testable version, the world has already changed:
- the customer needs have changed
- new technology has become available
- competitors have introduced better alternatives
You end up testing an old solution to an old problem. Then, what have you learned?
Enterprise feeling of Slowness
In my work with large product organizations across telecom, automotive, finance and others, there is a constant feeling of slowness. Ideas take years to materialize, initiatives are huge, there are many dependencies between them, and there are dozens upon dozens of them running in parallel.
At the same time, the governance model assumes that
- decisions are taken per initiative, as if it was the only one in motion
- initiatives are assumed to be largely independent in terms of technology, solution, people, test and validation resources
- execution is governed in separate forums, focusing on one initiative or a set of them
At some point someone inevitably suggests the obvious solution:
“We should make initiatives smaller.”
And this is where the correlation–causation trap appears.
Large initiatives are not the root cause.
They are a symptom of the system which causes initiatives to become large.
Instead, look for these causes leading to large initiatives:
- Resource-based funding
- Annual planning
- Dependency-rich architecture
- Fragmented ownership
- Functional-oriented organizational structures
Large initiatives are often a consequence of how organizations fund work, structure teams, and make decisions. To make initiatives smaller, you have to change the conditions leading to them being large.
Enabling relevance by changing roadblocks to speed
If large initiatives are a symptom of the system, the real question becomes:
Which conditions need to change to improve flow and relevance?
In my experience, some of the most important ones are:
Capacity funding
Funding capacity enables the organization to change priority with more ease. When funding is allocated on a per-project basis, capacity becomes locked into a specific solution. If priorities change — which they inevitably do — organizations must first wind down one project before starting another. This introduces waste in the form of unnecessary delays and administrative overhead.
At the same time, the real assets of a product organization are not the budget numbers attached to projects. They are the people, processes, tools, and partnerships that enable value creation.
Instead, funding should be decoupled from specific initiatives. Fund a product development organization and enable continuous prioritization of available resources based on clear objectives and measurable outcomes. Utilize a long-term perspective when judging what capabilities are needed in the future.
Shorter feedback loops
Faster feedback loops allow teams to validate assumptions earlier and significantly reduce uncertainty.
Start by understanding what the main bottlenecks to faster feedback are — and then invest in removing them.
Earlier in my career I was responsible for Integration & Verification of a mobile network solution. At the time we ran about 600 tests every six months.
The process was highly manual and many of the test cases failed on the initial run. Finding and fixing faults was a massive undertaking because thousands of changes had accumulated in the solution between each test cycle. In fact, we rarely managed to pass all test cases before it was time to start all over again with the next increment.
A couple of years later, the same testing was done every week instead of every six months.
With much smaller batches of change, faults were significantly easier to identify and fix. Problems were discovered earlier, the scope of each investigation was smaller, and actual progress became much more certain. Getting to that point required a significant investment in test automation and way of working, but in the end it was worth it.
The key difference wasn’t working harder — it was enabling shorter feedback loops, which made it possible to detect and fix problems before they have grown too large.
Fewer parallel initiatives
In many large organizations, a significant amount of effort goes into starting new initiatives — far less is spent making sure ongoing initiatives are completed.
As a result, new work is continuously added on top of work already in progress. Over time, this creates a growing imbalance that often surfaces as last-minute crisis management toward the end of development.
Too many parallel initiatives create a state of permanent overload.
Work starts to queue, priorities become unclear, and teams are forced to split their focus across multiple initiatives. This leads to corner-cutting, delayed learning, and an increased probability of crises close to intended release.
I often argue that an organization could increase delivery speed by 20% simply by reducing the number of significant initiatives by 10%.
This is not just an intuition — it is grounded in systems thinking. In queuing theory, Kingman’s formula describes how lead time increases rapidly as system utilization approaches its limits, especially in the presence of variability. High variability systems such as product development experience this effect at lower levels of utilization than you might think.
In practical terms, this means that when organizations operate close to full capacity while handling many parallel initiatives, even small increases in load can cause disproportionate increases in lead time.
Reducing the number of parallel initiatives is often the fastest way to improve flow — not by working harder, not by removing variability, but by reducing the amount of work in process.
A critical side effect of reduction in workload is that it enables smaller initiatives.
In overloaded systems, smaller initiatives are often down-prioritized in favor of larger ones perceived as more “important”. Over time, this drives a behavior where independent work is bundled together into larger initiatives — further increasing complexity, dependencies, and lead time.
Reducing the number of parallel initiatives helps break this pattern. It creates space necessary to prioritize smaller, more focused initiatives — which in turn improve flow, feedback, and outcomes.
Dependency reduction
In large-scale product development multiple types of dependencies exist simultaneously — including technical dependencies between different parts of the solution, organizational dependencies between functions, and dependencies on shared resources such as specialized test equipment.
While each of these seems manageable in isolation, their combined effect on making initiatives large is significant.
In the previous section I introduced Kingman’s formula. Dependencies increase variability in the system. As dependencies increase variability, lead times grow rapidly even at lower levels of utilization compared to a system with fewer dependencies.
Every dependency introduces hand-offs, coordination, and waiting time — all of which add overhead. To compensate for this overhead, organizations tend to bundle work into larger initiatives, further increasing complexity and lead time.
In large-scale product development, dependencies cannot be eliminated entirely. But they can — and should — be actively reduced.
One of the most effective ways to reduce dependencies is to organize around cross-functional, empowered teams — which is the next topic.
High-performing organizations don’t manage dependencies better — they design systems with fewer of them.
Cross-functional empowered teams
One of the most undervalued changes to make initiatives smaller is to increase the degree of cross-functionality within teams.
Many organizations are optimized for resource utilization and therefore structured into narrow functional units. However, product development requires cross-functional collaboration — spanning multiple domains, skills, and parts of the organization.
Projects are often used as a way to temporarily organize this collaboration. But projects are, by design, temporary and focused on delivering a specific solution. Once the project is completed, the structure is dissolved.
As a result, learning is fragmented, ownership is unclear, and improvement of the overall system is not part of the goal.
Each new initiative requires coordination to be re-established across functions — increasing dependencies, overhead, and lead time. I have even experienced organizational “solutions” to this problem such as extending a project by adding subsequent releases to its scope.
Cross-functional teams break this pattern.
By bringing the necessary skills and ownership into stable teams, many dependencies can be removed entirely rather than managed. This reduces coordination overhead, shortens feedback loops, and creates the conditions needed for smaller, more independent initiatives.
Cross-functional teams can take greater responsibility for understanding which problems to solve — and how to solve them. Empowered teams take initiative, simplify their way of working and want to stay engaged with their customers.
They are able to work with smaller initiatives without heavy governance and coordination overhead — focusing on faster learning and better outcomes, rather than implementing predefined solutions. Smaller initiatives are not the result of better decomposition — they are the result of teams designed to operate independently.
Improving flow rarely starts with making initiatives smaller — it starts with understanding the system that makes them large.
Change the system, and smaller initiatives will follow.
If you want to understand what is really slowing your organization down — and where to start — feel free to reach out.