In recent years, there has been a significant shift from project-based to product-based organizational structures. This movement has gained momentum due to Mik Kersten’s book, “Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework.” However, the book may be misunderstood, or the readers did not read more than the title. This article discusses how this approach may not always be the most effective for several reasons. Keep reading to discover why!

Many organizations follow the approach to move from projects to long-lived products. Shifting from projects to products, as the title of Kersten’s book reads. I have seen this in strategic documents and big letters written on a slide in a town hall meeting. However, there are several problems I have met in a multitude of organizations shifting towards product-centricity. Let’s dive into them.

Creating a non-dynamic, inflexible organization

Adopting a product-centric approach implies that we already have the solution, and the products we currently possess or may require in the future are the answers. The solutions to our customer’s problems, now and in the future, are delivered through a product. If the product is fixed, the solution will be less flexible and maybe not optimal. The choice of product for a particular solution may not be optimal. Products are the bearers of solutions and part of the solution. As a result, the solution becomes static, rigid, and far from agile. For example, we may not decommission a product, which might not be the best solution to the problem, since we have a team and a product owner who will sell the need for that product since that is the very existence of the team and the product owner.

Additionally, we need to start a new team with a new product owner to develop a new product that might be a better fit for our solutions. Creating that solution will become a budget question rather than a technical question. Consequently, the organization’s agility is low. Organizing around products is Conway’s law in practice in a way that is not beneficial for the organization, cementing the product and solution structure.

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

Melvin E. Conway, 1968

Creating Silos

Organizing around products creates silos in which each team works independently, resulting in a selfish organizational unit. Cooperation between product silos may be minimal or non-existent. It becomes challenging for the product organization to stop developing a specific product or begin working on a new one. It is tough to create solutions covering more than one product, define the inter-dependencies as requirements in the teams’ different backlogs, and try to align them in time.

Product owners become owners of a product

The product owner is one of the most misunderstood roles. Scrum was originally designed for a single-team, single-product configuration, where the product owner role was defined as the owner of the product and the product backlog, responsible for developing the product backlog items (PBI:s). This simple one-to-one scheme is seldom true in today’s more complex setups. We might need more than one team to work with one product, and a single team can work with multiple products.

By having a product owner per team or several teams, we are cementing those teams’ objectives around that product. The product owners’ responsibility is to add new features to that product. The product owner is, by definition, selfish and will not create a solution outside the scope of the product, even if that solution would be more beneficial for the end user or customer. As a result, we continue working with the same team and product. We do not move our effort to another product even if tasks for that are considered more prioritized.

Teams are becoming feature factories

In a product-oriented setup, teams may quickly become feature factories. Product management and product owners load backlogs with features they believe customers require. The team’s responsibilities are reduced to swiftly implementing features with already-defined solutions. The product team measures success by the frequency and volume of new feature shipments. The organization believes that adding a new feature always adds value to the product. The organization fails to test feature ideas before building them and fails to assess their success by measuring user value after delivering the feature. The organization does not take advantage of the team’s complete competence in its domain of expertise. As a result, the work for the team members becomes less fun.

Lack of definition of “product”

Another challenge with organizing around products is the absence of a clear and consistent definition of what constitutes a “product.” Unfortunately, many organizations fail to establish such a definition, leading to confusion and misalignment among different teams and stakeholders. For example, I have seen instances where products are defined as steps in a waterfall-ish development approach, where “architecture” is considered one product, and “maintenance” is another. This lack of clarity in the definition of “product” can significantly undermine the effectiveness of a product-centric approach and impede an organization’s ability to deliver value to customers.

Benefits of a product-centric organization

For sure, there are some benefits to a product-centric organization, else it would not be that popular:

• Greater Ownership and Accountability: Organizing around products enables teams to take greater ownership of the products they work on, making it easier to hold them accountable for the outcomes they deliver and support the product throughout its lifetime. This way of organizing can increase the focus on customer needs and quality.
• Increased competence: The team gets a very high competence for the product they are evolving.
• Better collaboration: By aligning teams around specific products, it’s easier to facilitate collaboration and cross-functional work within that product.
• Greater agility: By focusing on products, teams can be more responsive to changes in customer needs and market conditions, which can help to drive greater agility and responsiveness.
• Improved innovation: By becoming experts in their domain, teams can drive more significant innovation and differentiation, which can help the product to stand out from competitors and drive growth.

So, how can we avoid the drawback of organizing around products and keeping the benefits?

The solution — organize around the value

The solution to the challenges of organizing around products is to shift focus from products to the value that they provide. To focus on the value means starting with a clear definition of the problem or opportunity, defining the solution that meets the customer’s needs, and finally determining how to deliver that solution. Only at the end, in the final step, is the choice of the product, the bearer of the solution, made. The value is the solution to a specific problem. The products are possible bearers of that solution.

The value is the solution to a specific problem. The products are possible bearers of that solution.

Organizing around value can help organizations adopt a more customer-centric perspective, leading to better alignment with customer needs and improved responsiveness to customer feedback. In addition, by focusing on value, organizations can increase customer satisfaction and loyalty and gain a competitive advantage in the marketplace.

The value is the solution to a specific problem or opportunity, and the product is simply a means of delivering that solution. By organizing around value, teams are responsible for finding a solution to a defined problem or opportunity within the problem domain, rather than within a specific product.

Organizing around value involves ideally all the steps required to define, implement, build, test, deploy, and operate the solution that solves the customer’s problem. It means taking complete responsibility for the entire lifecycle of the products used to solve customer needs, from ideation to decommissioning.

Organizing around the stream of value allows organizations to follow standard agile practices, with a single team often sufficient to work on a particular solution. Even so, there may be times when more than one team is needed to work together as a team of teams to provide the complete solution from start to finish.

Organizing around the stream of value helps to avoid handovers, which can cause delays and information loss. Instead, the entire organization works together towards the same goal of providing a solution to the problem.

Rename the Product Owners

Renaming the Product Owners’ title to “Value Maximizer” could shift their focus toward maximizing customer value. While this is, for me, an untested experiment, it is likely to positively impact the Product Owner’s work by providing clarity on their primary objective. Even in a single-team, single-product setup, how rare this can be; what is in Scrum referred to as Product Backlog Items should not be only items for the product. Instead, they can be improvements to the teams’ way of working, items refining the infrastructure, or even training for the team. So, the Product Owner is the owner of the complete Team Backlog, not just the product part. Hence, even in this setup, it could be an excellent thought to rename the Product Owner.

What did Mik Kersten really say?

In his book, Mik Kersten says, “By organizing around value streams, we can enable teams to take ownership of end-to-end delivery of the product and business capabilities that support their value streams. Teams can then focus on achieving a shared mission, and the value of their work is measured by the impact it has on their value stream.” Case closed.

By organizing around value streams, we can enable teams to take ownership of end-to-end delivery of the product and business capabilities that support their value streams. Teams can then focus on achieving a shared mission, and the value of their work is measured by the impact it has on their value stream.

Mik Kersten

SEB’s Value Stream-Centric Approach

SEB, a Swedish financial institution, implemented a value stream-centric approach to unify its digital development efforts and focus on delivering value to its customers. SEB’s value streams span multiple departments and are composed of cross-functional, empowered, agile teams working together to deliver value continuously. By organizing around value streams, SEB was able to reduce time to market, increase collaboration, and improve the quality of its products and services.

Origin of value stream

While some readers may draw similarities between this approach and SAFe principle #10, which advocates organizing around value, it’s important to note that this approach is distinct from the vast SAFe framework. The concept of value streams was first introduced in the book “Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA” by Mike Rother and John Shook, published in 1999. While the book focuses on value stream mapping in a manufacturing context, the concept of value streams has been adapted to other domains, including software development and business operations.

The book identifies handovers as a common waste, or “muda,” that hinders efficiency and productivity. Handovers can be avoided by keeping all parties in the same organization, and the benefits of organizing around value can be fully realized.

The concept of organizing around value is beneficial and applicable to any agile organization, regardless of its industry or domain. The approach is not linked to any specific framework, and its benefits can be realized beyond the digital realm.

Conclusion

Organizing around value is a powerful approach that can help organizations be more responsive to customer needs, more agile in their practice, and more innovative in their product development. While there may be some challenges to implementing this approach effectively, the potential benefits are significant and can help organizations meet customer needs, stay agile, and drive growth. Renaming the product owner’s title to something like “value maximizer” would indicate what outcome we are after in our teams and would probably positively influence their work in a very positive way.

References and further reading

Rother, M., & Shook, J. (1999). Learning to See: Value Stream Mapping to Add Value and Eliminate Muda.

Scaled Agile Inc. (n.d.). SAFE principle #10, Organize around value. Retrieved from Scaled Agile Framework: https://www.scaledagileframework.com/organize-around-value/

Kersten, M. (2018). Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework.

Conway, M. E. (1968). How Do Committees Invent?

This article was originally published on Medium in february 2023

Last updated Dec 17, 2024