The 4 value streams in product development

How do we know how a product development activity contributes to stakeholder value? And if we have a choice between two activities, what should we do next? The reality is that the team thinks they know what needs to be done. However, if no one keeps track of the different value streams, it is easy to end up working on the „wrong“ activities. Or on the „right“ activities at the wrong time.

This is the second and final part on the subject of stakeholder value.

The product creates stakeholder value

Part 1 was about how an organization can develop a clear understanding of the Stakeholder values creates and maintains. This is the task of the product, which provides the necessary capabilities identified for this purpose. Ensuring this is the task of product development.

Today, it is more important than ever that the product not only provides the necessary capabilities, but also adapts them quickly to respond to the changing needs of stakeholders.

Furthermore, the organization should provide user-validated metrics. These can become part of the acceptance tests.

What is flow?

The term flow originates from the lean movement and describes the continuous flow of work, typically through production. In product development, flow means that tasks progress without unnecessary waiting times, handovers or priority changes and that bottlenecks are identified at an early stage. The aim is to make the value stream visible and to optimize it.

This way of thinking has now also spread to other areas, for example in start-ups (Eric Ries) and even appears at Flow Engineering in the name of the company. Flow characterizes approaches that focus on measurable value streams and fast feedback cycles. One representative of this development is Mik Kersten, who has created a method for product development with the (trademarked) Flow Framework.

The flow framework

Mik Kersten describes the Flow Framework by Mik Kersten in the book Project to Product. It arose from the observation that many companies try to get to grips with digital transformation using cost and activity metrics. But this doesn't work in practice.

Instead, Kersten suggests understanding product development not as a sequence of projects, but as a value stream network: Each activity contributes to value creation in a measurable way. Instead of optimizing for capacity utilization and costs, we optimize for flow.

The flow framework is just one of many concepts. But it is a good way to introduce the concepts that we also use in Lean Product Development, SAFe Value streams or Team Topologies find.

The four metrics that count

The flow framework defines four metrics that together describe the status of the value stream:

• Flow Velocity - how many value objects (features, defects, risks, debts) are concluded per time unit.
• Flow Efficiency - what percentage of the throughput time is actually used productively.
• Flow Time - how long a value object takes from start to finish.
• Flow Load - how many value objects are in progress at the same time.

These metrics make it possible to identify bottlenecks and measure progress across teams, products and programs.

The four elements that enable the realization of values

In the last article we have seen, that the value streams in product development are organized along four elements: Features, Defects, Risks and Technical Debt. These categories concretize the abstract term „value“ and make it possible to understand and control the work throughout the entire product life cycle. Now it is a question of how these elements interact and how a robust control model can be derived from them.

Features: Generate value

Features stand for the visible contribution to the company. They drive growth, differentiation and customer benefit. In practice, however, the focus on features must not become an end in itself: Only if organizations balance the flow across all four flow elements will feature development remain sustainable. Too many features with too little maintenance inevitably lead to a loss of quality and an increasing technical debt burden.

Defects: Preserve value

Defects are indicators of lost value. They show where existing capabilities are weakened or where quality and trust are eroding. Instead of viewing defects merely as annoying errors, they can be used to derive trends and causes that affect the entire value stream.

Risks: Hedging value

Risks are investments in stability. They prevent future value from being lost in the first place, for example due to security gaps, regulatory violations or a lack of resilience. In regulated industries in particular, real competitive advantage is gained when risks are identified early, made visible and integrated into the same flow as features and defects.

Technical debt: Enabling value

Technical debt forms the infrastructural basis of all other flow elements. Managing it means maintaining the foundation for future value. Those who only „clean up technical debt when there is time“ are postponing the problem into the future. Dealing with it in a structured way, which becomes visible with corresponding flow metrics, creates the basis for lasting product quality.

The Flow Framework's primary focus is on connecting technology and architecture to the business with the minimal number of concepts that executives and technologists can agree on and understand. As such, each of the units or work items being done by all specialists in the value stream needs to map into one of the four flow items.

Mik Kersten in Project to Product

Only by consciously controlling all four elements can a holistic value stream picture be created. They not only enable progress to be measured, but are also an important tool for communication between development, marketing and sales.

Tracking value flows in development

As soon as value streams are identified and measured, they can be made visible, for example in dashboards. This creates operational management tools that show where value is being lost: in overloaded teams, in queues, in unclear handovers.

Joachim Pfeffer, for example, said in an interview with SE-Trends that although some companies have very efficient specialist departments, there are sometimes extremely long idle times between departments. A flow framework makes this visible, shifting optimization from local efficiency (e.g. utilization of individual teams) to systemic flow.

Closing the circle

Finally, we need to link the flow metrics to business results. Only when improvements in the value stream are reflected in business metrics such as sales growth, customer satisfaction or time-to-market will there be real benefits. And just as importantly, decision-makers will only be prepared to finance measures to measure value streams in product development if they make a concrete contribution to business success.

Conclusion

The basic idea of value streams is simple, but implementing them requires consistency and persuasion. Lightweight tools such as Kanban boards or Cumulative Flow Diagrams help to make the first bottlenecks visible. However, what counts in the long term is the ability to manage value streams across product and organizational boundaries.

Technology, processes and metrics are necessary, but ultimately the culture has to be right: Only when teams understand why they are measuring and improving value can the real benefits of the flow framework be realized.