Experience Report

Lessons Learned in Becoming a Product-Centric Organization

About this Publication

How do you shift from a component, technology aligned organization to a product-centric organization? Many organizations find this to be a challenge as they aspire to go beyond agile. To be successful, an entire organization must align their teams for product-centric discovery and delivery.

1.     INTRODUCTION

A large, global financial service firm (we’ll call it BigFin) was three years into its journey to adopt agile ways of working. To accelerate customer experience improvements that had already been achieved, the technology infrastructure division decided to align its structure and delivery to become product-centric. The focus was primarily on products used internally by its employees.

Toby Sinclair, an internal coach in the strategy and transformation team, brought in Ellen Gottesdiener to fill gaps in the team’s product management knowledge and experience. With Ellen’s product coaching expertise, both Toby and Ellen touched almost all parts of the organization. It changed how the company viewed what was valuable to its customers (employees) and how to organize to deliver this value.

Along the way, the following impediments were uncovered, amplified by the scale of the organization, including:

  • How shifting from technology-centric to product-centric is counter-intuitive for many technologists;
  • How shifting to being product-centered challenges people’s mental model of what a product is;
  • How difficult it is to shift metrics from activities and due dates to customer outcomes; and
  • How organizational structures can become complex and challenging as leaders learn the implications of product thinking for existing roles.

This experience report focuses on the first year (the transformation is still ongoing) and the initial efforts around defining products, organizational structure, and ways of working.

2.     Background

In 2017, the executive of an 8,000-person infrastructure organization at a large financial institution decided to accelerate and amplify its current agile transformation. They sought to improve customer value and accelerate delivery. Based on a recommendation by a consultancy, the organization saw product centricity as necessary. This recommendation was validated after field visits to well-regarded product-centric companies (e.g., Facebook, Apple, Netflix, and Google).

The transformation team began by defining the infrastructure organizations products and understanding how its extensive list of existing services, applications, platforms, and components supported those products.

Transitioning to a product-centric organization was further complicated due to the following:

  • Scale—The number of people (8,000) potentially impacted was quite large.
  • Product type—The products are infrastructure which in turn support BigFin’s customer-facing products.
  • Culture—The organization was hierarchical and project (not product) focused with deep, narrow reporting structures.
  • WIP—There was a high amount of work in progress within the organization, including a number of change initiatives driving organizational restructuring.

3.     Our Story

3.1        Shared mental model of product

What is a product? This question was the most asked question throughout the journey to become a product-centric organization. Terminologies like product owner, product backlog, minimum viable product (MVP), product team, and product are often used within agile frameworks. When you ask the staff within your organization, “What is a product?” and you will get many different responses. This difference lies in differing mental models:

“Mental models are conceptual frameworks consisting of generalizations and assumptions from which we understand the world and take action in it.”—Peter Senge

To become a product-centric organization, BigFin needed to develop a shared mental model about products that everyone understood. It was to be central to how BigFin organized, discovered, and delivered solutions to customer needs. This was the most important challenge Ellen and Toby needed to tackle early on.

3.2        Defining broader products

Improved customer value and accelerated delivery were identified as the two primary goals for BigFin. To achieve these goals, Ellen encouraged BigFin to think about defining their products in a way that optimized their ability to achieve these goals. Ellen suggested that a broader product definition would help with this optimization. Broader products lead to many benefits, including few backlogs and product roles, more customer-centric prioritization, reduced dependencies, less duplication in functionality, and organization structures that align development teams with the end-to-end customer value.

Ellen shared this definition for discussion: “A product is something that provides value to customers and business partners. A product is an integrated set of technical and non-technical elements. It may be in the form of software application, system, device, service, and process, or a combination. A product may itself be a service or include services.”

After examining existing products at BigFin, many products were already aligned to this definition. However, when reviewed in the context of the optimization goals, product definitions were suboptimal. Instead, it would take several products pieced together to deliver customer value. There were many dependencies between the products, which added to delivery time. With internal competition between product teams, there was excessive duplication of effort. Each product was locally optimized—not globally optimized—to deliver value and accelerate delivery.

3.3        Thinking inside-out—technology centric

It was typical for many leaders at BigFin to make key product decisions from a technology perspective. When asked, most would refer to an application (e.g., a vendor product such as Skype, Oracle, or Office) or component (a hardware element such as a midrange server or display panel) as the product. This is no surprise given the system of record was application-centric and component-centric. (The system of record consists of documents, tools, and mechanisms used to monitor and manage the organization.) For BigFin, the system of record was a master catalog of over 600 applications and components that comprise the entire firm’s infrastructure for all external and internal customers.

Within a large organization like BigFin, the system of record plays a dominant role in defining what matters. The system of record guides how funding is allocated and approved, what gets reported on and challenged, and how the organization values title and roles. As we began this journey, BigFin’s infrastructure organization considered just about every single catalog element as a unique product.

To reinforce application-centric thinking, the system of record imposed constraints on product teams. For example, tools to track work were associated with applications. As a result, this meant that most backlogs were about components, rather than product backlogs.

Ultimately, the system of record was regarded as the “tacit arbiter of truth.” Inside-out thinking contributed to the suboptimal definition of the products. In fact, there were numerous similar so-called “products” (or product variations) in the product line. Many of them had little to no interoperability. Most importantly, a single product did not provide end-to-end customer value, thus detracting from a satisfying customer experience.

3.4        Thinking outside-in—becoming product centric

Ellen and Toby believed that in order for BigFin to achieve its goal to be more customer-driven, a focus on the customer was required. As the current thinking was inside-out (technology to customer), a more outside-in approach (customer to technology) was imperative.

BigFin infrastructure customers could be categorized into two groups:

  • B2C (business to consumer)—BigFin employees needed products and services to be productive within the workplace. Employee Collaboration was a good example of a broadly-defined B2C product. Consider Employee Collaboration to be an example of a broadly-defined B2C product at BigFin. Applications like Zoom, Skype, and Teams provided the building blocks that enabled collaboration.
  • B2B (business-to-business)—The infrastructure organization provided shared infrastructure products and services to enable consumer-facing products, such as mortgages. Contrary to B2C products, the infrastructure organization’s customers were not the end consumer. Instead, application developers and database administrators in BigFin’s business areas were directly involved with a complex B2B value chain.

Our intention was to help BigFin take a step back to explore the underlying customer need.

For example, looking at BigFin’s database administrator as the customer, it was important that the right database technology matched their needs. Our message was consistent and simple. The needs of the customer had to be identified instead of offering technology solutions to find customers.

3.5        Shifting the mental model through product definitions

To generate these breakthroughs and shift to outside-in thinking, we facilitated multi-day, collaborative product definition workshops. These workshops encouraged leaders to collectively discover the answer to the question, “What are our products?” It was essential to do this collaboratively with representatives across the value stream to gain a shared mental model.

Workshop participants prepared by reviewing a glossary of terms and the criteria for defining a product. In the workshop, the leadership team engaged in fun and provocative exercises to test their understanding with an interactive quiz using Kahoot, an online game-based learning platform. This workshop activity raised the awareness that was a more optimal way to define products. Three activities stood out:

  1. Product Canvas—A two-page canvas that explores different aspects of a product, including vision, product partners, value, cost factors, and the seven product dimensions. The product canvas became a tool to shift everyone’s perspective to outside-in thinking [Gottesdiener].
  2. Product checklist—A checklist of criteria for a healthy product definition including the following:
  • A product is described from the customer perspective;
  • A product is long-lived and evolves as needs and technologies change; and
  • A product spans the full customer journey.
  1. Is/Is not—A simple, fun card sort exercise. We asked everyone to write down what they believed the product was. In multiple rounds, participants would use the product checklist to determine which ones were products. (This exercise eliminated those that were determined to not be a product).

3.6        Defining a broader product

Once leaders carefully examined customer needs, they began to understand how interconnected everything was. It became clear that holistic products provide a better customer experience. At the same time, optimizing solutions for customers would challenge the structure of the existing organization.

One leader determined that the workplace was the product. By defining a broader product, physical assets (desks) and real estate (meeting rooms) were key components of the workplace product. He explored how to integrate technology and physical components to provide a great workplace experience. Because technology and real estate were separate departments, they needed to be more closely aligned as part of a single product.

A broader, outside-in perspective requires thinking outside of technology capabilities. When a product is broadly defined, structure follows product, not the reverse. For example, when Ellen coached the database leadership team, they determined that database advisory services would be valuable to their internal customers.

BigFin learned that their product definitions would evolve over time as the benefits of broader products are understood. The following figure (see Figure 1) illustrates the journey:

Figure 1. Narrow, inside-out versus broad, outside-in product definition

3.7        Getting the product definition to stick

Changing mental models for a single person can be quite a challenge, especially for an 8,000-person organization. For technologists who traditionally think inside-out, defining products more broadly from the customer point of view can feel counterintuitive.

We made better progress with departments of between 100 to 200 people. The size of an organization has an impact, too. Working with smaller organizations allowed us to go deeper by creating time, space, and safety to explore various mental models.

4.     The importance of roles

4.1        Aligning organizational structure to product definitions

BigFin wanted a simple organizational structure aligned to their products. One Product Owner would be assigned to one product and to a single product backlog. Feature teams would be aligned to this backlog and they would work closely with the Product Owner to deliver customer value.

It proved to be quite a challenge to move to this simplified organizational structure, as there was much confusion about product roles. Toby spent several days educating executives to get a deeper understanding of the importance to have a good product management organizational structure. Toby and Ellen cleared up common role misconceptions of the role of Product Owner in agile. The Scrum Guide is silent on the importance of good product management and the role of product ownership [Schwaber and Sutherland].

To overcome this, Ellen used an exercise called “Agile Product Management: Do the Right Things, Not Everything” [Gottesdiener-2]. This exercise highlighted activities and decisions that are important in product management, the role of product ownership, and the work of product development. At BigFin, it became clear that product management was a mixture of strategic and tactical work. Leaders were already familiar with tactical aspects (backlog management) in Scrum. Through coaching, a new appreciation of the strategic aspects (financials, market research, and competitor analysis) became apparent. For example, internal competition led to product duplication when Product Owners conducted competitive analysis of their product.

4.2        Product ownership

As leaders began to understand that a Product Owner had product management responsibilities, the role was perceived to be similar to that of a CEO. This new perspective amplified the importance of the role. For many organizations, the Product Owner was a junior role with little to no ability to make decisions beyond user story details.

However, the desire for a simple organizational structure led leaders (and HR) to shift their thinking in the opposite direction. They overloaded the Product Owner role with accountability, strategy, financials, product development, and technical design. In some parts of the organization, people management duties were added. With several hundred staffers reporting to them, the focus on product management became diluted.

To ease the pressure and misunderstanding about the Product Owner role, we emphasized the need for healthy separation between product management and product development. Product Owners should not have engineering teams reporting to them.

Leadership attempted to relieve the overloaded Product Owners by adding a Business Analyst (or a Proxy Product Owner) role. These “Product Managers” would create stories and represent the Product Owner at agile ceremonies. The Product Owner would subdivide the product backlog among several Product Managers. Unfortunately, this increased coordination effort and added more stress to the Product Owner.

To free up Product Owners, leadership proposed removing people management responsibility and to have developers perform product requirements analysis with customers. As you might imagine, developers only wanted to code. More importantly, role confusion highlighted the systemic misunderstanding of product management.

4.3        Product owners who are technical

Many of BigFin’s Product Owners were previously technology managers. Instead of learning more about the customer, Product Owners couldn’t help but dive into the technical details of a solution. It was common for Product Owners to downplay their lack of product management skills. Finding the right balance remained a challenge.

A Product Owner must not assume developers and technical customers have the same needs and expectations. Instead, Ellen stressed the importance of exploring customer needs with fresh eyes and an open mind.

The technical trap also locked Product Owners into domain specialization. A Product Owner working on a database product would rarely work on a product outside of that domain. This specialization often led to blind spots. As a result, Product Owners struggled to lead customer discovery sessions, perform user research, or build marketing plans. Ellen trained Product Owners on these new skills and several radically changed the way they worked. Others, however, found it harder to adopt these new skills. Toby observed that it was often the most technical Product Owners who found it the most difficult to develop product management skills.

4.4        Narrow product definition = large product staff

High technology bias was a strong force at BigFin. After initially defining broader products, infrastructure products became narrowly defined, expanding the number of products. As the number of products increased, so too did the number of Product Owners. Each product had its own Product Owner

As the number of Product Owners increased, the organizational structure became very complex. Consequently, Product Owners were responsible for one part of the puzzle and could not make independent product decisions. Customers and stakeholders were often confused which Product Owner they should engage with.

The systemic fix would have been to address the narrow product definition. Instead, a new Product “Portfolio Owner” role was created. This role was to manage a portfolio of narrowly defined products and help manage the dependencies between them. Unfortunately, this added complexity and didn’t address the root cause at all.

This deep hierarchy of Product Owners, Product Portfolio owners, and Product Managers resulted in disconnected backlogs and organizational mismanagement.

5.     What we learned

5.1        Most technologists will define the product suboptimally

BigFin had two distinct goals: reduce time to deliver and increase customer value. To align with the goals of the organization, products had to be optimally defined. We found quite the opposite. There were two “thinking traps” that lead to a suboptimal product definition: reductionism and technology bias.

There was a natural tendency to break the product down into narrowly defined products. There was a perception that smaller parts made the organization more manageable and efficient. Instead, this led to sub-optimal products that resulted in longer delivery times and lower customer value. That was the opposite of the goals that BigFin’s goals. Reductionism leads to local optimization at the expense of global optimization.

Technologists naturally jumped into solutions that were often technology-related. As Maslow stated, “If all you have is a hammer, everything looks like a nail.” At BigFin, all products were defined in terms of technology. Few leaders would define (or describe) products in the eyes of the customer.

We found it a continuous challenge to help leaders define broader products. There were several key practices that helped influence success. To understand customer day-to-day challenges, Product Owners spent considerable time engaged with customers. It was beneficial to involve the customer in defining their problems and assisting in the design of effective solutions. The more a Product Owner increased their product knowledge, the more they wouldn’t blindly jump into a technology solution. Finally, leaders with high psychological safety and self-confidence were able to look beyond organizational boundaries.

5.2        Use Systems Thinking to influence your products and organization

BigFin started with the intention of a simple organization structure. However, scaling quickly became a challenge. More products were defined as definitions became narrower and easier to manage from a technology perspective. As more roles were added to handle the complexity, all that did was compound the problem. In hindsight, we could have spent more time educating senior managers on these organizational dynamics.

One technique that started to help leaders see the impact of their decisions was systems thinking. The use of causal loop diagramming was a technique Toby found led to breakthroughs. When leaders used this technique to visualize the system, they could see the impact of their decisions against their goals. Toby helped leaders gain knowledge of this technique through large-scale Scrum training incorporating causal loop diagrams as a learning tool. Leaders witnessed the benefits after participating in these workshops that included a flatter organization, fewer backlogs, emergence of the product role, and aligning the organization to product. System modeling offered major benefits in helping leaders understand their organization as a system, how variables impacted behavior, and how they unknowingly caused the opposite effect of their stated intent.

To prepare this report, we created a causal loop diagram to highlight in retrospect the dynamics that influenced the transformation (see Figure 2).

These dynamics are likely to be present in many other organizational systems. Before jumping into redesigning the organization, educate leaders on how to view their organizational system. This approach avoids quick fixes and unintended side effects.

Figure 2. The dynamics of transitioning to being product-led in BigFin’s infrastructure organization

5.3        Deep, not broad and shallow

Rather than work with an entire product portfolio, it would have been a better strategy to have defined a small set of broad infrastructure products. Then, deep dive into only one of those products to do the following:

  • Rework the system of record for that product
  • Align the teams to product feature areas
  • Establish metrics based on customer outcomes
  • Tackle role definitions
  • Engage HR and finance leaders
  • Train and coach product staff

5.4        Model good product management

Before writing this report, we conducted a retrospective on our transformation work. We produced an events timeline with an emotional seismograph and mined the timeline for themes. We then created a set of proto personas for the roles in the organization, a force field analysis, and multiple versions of causal loop diagrams. This helped us identify what happened during the transition to become truly product-centric. We recognized that our work fell into using activity versus customer metrics and didn’t delve enough into customer discovery. We continually reminded each other how slow and painful change is, especially for large organizations like BigFin.

We recognized it is always best to model the behavior being sought. To conduct a transformation to be product-led, you must always act as a good product manager. Be aware that the organization is the product and always start with the customer.

We made important progress changing mental models. We could have spent less effort on activities such as education and training. Instead, we would have conducted customer research, identified customer-outcome metrics, and worked toward small changes that moved the needle toward better customer outcomes.

Acknowledgements

Special thanks to our Agile Alliance shepherd, Cherifa Mansoura and to these reviewers: Nanette Brown, Charlotte Chang, Ahmad Fahmy, Kate Leto, Jerry Lopez, Jeff Patton, Cesario Ramos, Andy Repton, Dan Sokoloff, and Diana Williams. Thank you!

REFERENCES

[Gottesdiener] Ellen Gottesdiener, 2019. “Using the Product Canvas: “Getting Started”| “Define Your Product’s Core Requirements” [ONLINE] Available at: https://www.ebgconsulting.com/blog/using-product-canvas-define-product-getting-started/ and 
https://www.ebgconsulting.com/blog/using-the-product-canvas-to-define-your-products-core-requirements/

[Schwaber and Sutherland] Ken Schwaber and Jeff Sutherland, 2017. The Scrum Guide™. [ONLINE] Available at: https://www.scrumguides.org/scrum-guide.html

[Gottesdiener-2] Ellen Gottesdiener, 2018. “Do the Right Things, Not Everything”. [ONLINE] Available at: https://www.ebgconsulting.com/blog/right-things-not-everything-product-management-ownership/

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
2020 Reports

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related Agile Experience Reports

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now