Business Agility is similar to the agility we observe at the team level—it helps a work unit deliver faster, learn faster, and adapt more quickly to change, but as the name suggests, it extends across the business.
Most companies aim to outperform their competitors and remain relevant to their customers and stakeholders for as long as possible. The promise of Business Agility is like an elixir of life, essential for preventing stagnation and fostering rejuvenation.
When obtained, Business Agility allows organizations to fluently and effortlessly absorb changing market trends, quickly jump on selected opportunities at no additional cost -- be agile in the broadest sense of this word.
This blog describes how Business Agility can be achieved in relation to the work of Product Managers and Product Owners. The Org Topologies™ map helps us understand this concept and guides us on the path.
If you are unfamiliar with Org Topologies™, the tool for strategic organizational development, you can get started here.
The Difference between “Product” and “products”?
Large, complex Products are ... large and complex. We want to split them into smaller parts because managing smaller products appears to be easier. So, usually, what large organizations identify as products are steps in the funnel, parts of a customer journey, features, applications, or components... They are parts of a larger Product.
Those smaller products are typically poorly understood by the customer and business stakeholders. The sub-products are parts of a bigger whole. Only when that whole is put together can we address customer needs, enable a business model, make a true impact, and get a return on investments.
"Dividing an elephant in half does not produce two small elephants." -- Peter Senge, "The Laws of Systems Thinking"
Note the distinction between “Product” with a capital “P” and lowercase “products” in the paragraph above. We will apply this capitalization throughout this article. The difference between Product and product is essential. Org Topologies™ defines that difference as the “Product Gap”:
It usually comes as a surprise, but the size of the Product Gap in an organization profoundly affects the whole organization, its design, and its operating model. In other words:
A Product Gap is an essential characteristic of an org design.
The idea that every piece of the whole (each sub-product) needs an “owner” is common in the industry. This is probably due to the popularity of Scrum terminology. Let us paraphrase that slightly differently:
Most organizations have far too many product owners!
Now, what do those product owners (in lowercase) exactly “own”?
What is Ownership?
When ownership means owning the whole Product, the impact a Product Owner can make can be measured by the improvements to that Product over time. As discussed above, a Product is developed to solve customer needs and enable a business model. As a consequence, the impact of a Product Owner must be measured in those terms as well. The results of their work are visible to the business stakeholders and customers and can be measured and optimized.
But what happens when the whole Product is broken down into parts, and it is the parts that are owned but not the whole? Then, the impact of the work of the product owners (lowercase) becomes less connected to what business stakeholders and customers understand and care for. Results become harder to observe, the impact becomes harder to measure, and efforts and investments become harder to justify.
Working on the parts does not guarantee a meaningful positive impact on the whole. Therefore, predicting and measuring returns and profits is difficult or even impossible when owning only a part.
What is easier to observe and measure when individual parts are owned separately are the efforts and costs. And this is more dangerous than it sounds.
Large organizations distinguish between “profit centers” and “cost centers”. Sadly, business stakeholders and accounting see many product owners and their teams as mere “cost centers”.
If you are the costs, you will be minimized.
Sad but true.
In the absence of working towards something outer-focused (e.g., the impact of the Product on customer needs, a business model), owning a product part (lowercase) usually boils down to a sequence of inner-focused activities: preparing work, slicing work, detailing work, assigning work, tracking work, coordinating work... Work, work, work. Output, output, output.
This is an obvious downfall of product management. The noble goal of Product Management is to maximize outcomes and minimize outputs, and that is challenging when the parts are owned separately.
To make matters worse, teams quickly get used to their “helpful” and “available” product owners. Teams start to expect and rely on them to do all this preparation and coordination work. This inevitably only makes the downward spiral more vicious. In such environments, the true ownership of impact is replaced by managing work and output.
Product owners (lowercase) become synonyms for project managers, requirement engineers, and team coordinators.
They are team output owners, really.
Levels of Ownership
In the Scrum-dot-Org Professional Product Owner class, there is an exercise where a picture (displayed below) is shown, and the students are asked to plot themselves according to the different ownership levels.
Most product owners who attend such classes plot themselves on the left side of this image as 'scribes' and 'proxies'.
Ownership of the parts is rooted deep into how we do things these days (at least in the software industry). Typically, such product owners have either task- or feature-focus and are given a single development team to work with.
With Org Topologies, we map this level of Product Ownership in the lower part of the map (Y—and A-levels). They are output-driven.
Business Agility Cannot Be Attained ...
... When There is No Business Involvement
The “Product Owner” role was invented some 30 years ago as a response to a common problem - business in most organizations has been separated from Product Development (IT, R&D). Business people were neither involved nor controlled investments in software product development at the right level of granularity.
That created a huge swamp for organizational dysfunctions such as internal fixed-scope projects, annual budgeting for IT, and countless orphaned products that someone once requested but no one really wanted.
By giving a Product Owner's role to a business stakeholder, we bring Business and IT closer together and teach them to collaborate in a win-win game. In this setup, Business and IT work together daily to maximize value (more outcome) and minimize the amount of work not done (less output).
And here lies the first impediment to Business Agility: the role of product owners (lowercase) is unlikely to look sexy to someone from the Business. Remember: a product owner owns a part of the Product: a step in the funnel, a part of a customer journey, a feature, an application, a component. And business people are not interested in tactical management of the parts but in strategic management of the whole. Hence, in many organizations, the role of product owners will be fulfilled by IT folks, not business representatives.
Essentially, product owners in most orgs are team-level business analysts who take care of details so the teams don't get distracted from coding.
Now we have just returned to square one: Business stays outside, not taking an active part in creating products, is uninvolved, and is not controlling investments.
Eventually, in such an environment, the only way to control anything for Business is to fall back to the old-and-tested management practices of threats and bribes (deadlines and bonuses).
Goodbye, Business Agility!
... When There is No Whole Product Focus
Meet Billy, a product owner of the Billing Engine, and she works with a Billing Engine Team.
Billy can optimize her team’s output when there is work regarding the Billing Engine. It is her focus. She scans the organization for useful work in the Billing Engine and brings it to her team. And when there is no work coming from the outside? She has a list of things that need to be improved in the Billing Engine.
(Isn't she sometimes making up the work to keep her team busy? She would never agree to this statement. So, let's assume this never happens...)
The trio: Billy, the Billing Engine and the Billing Engine Team are a tight knot. Billy owns the Billing Engine. The Billing Engine Team specializes in the Billing Engine. They all need each other. Their world is small but comfy. They can focus and specialize. They can be super-efficient when it comes to the changes of the Billing Engine.
Note: These are not just some universal laws: no one is born owning and knowing a Billing Engine. This is an org decision someone made some time ago. These are the principles of how that org is set up. “Efficiency Through Specialization” and “Focus Equals Efficiency” are the company's values that are written in the hallway.
Billy can even try to make her team more efficient and achieve a nearly hundred percent resource utilization. But will it make the whole company agile? Agile as to “fluently and effortlessly absorb changing market trends, quickly jump on selected opportunities at no additional cost”? That is a rhetorical question.
How many product owners with dedicated teams are in the org? Five, ten, twenty-five, a hundred?... All the product owners are strongly focused on their product parts, as Billy is. All the teams are deeply specialized in their product part.
“Efficiency Through Specialization”. “Focus Equals Efficiency”.
Imagine that Billy and her colleague product owners all need to contribute to larger business initiatives, bets, objectives, programs, projects, and epics (whatever they are called in that organization). These initiatives are usually created and prioritized by business stakeholders.
And this quarter, there are five big company-level bets. One is a “Customer Retention” project on top of the other things. In the scope of that objective, customer retention needs to be increased, and those changes affect the Catalog (and the Catalog Team), the Product Search Engine (and the Product Search Engine team), the Billing Engine (and the Billing Engine Team), ...
Which team will handle that epic?
Before anyone can take it, it needs to be decomposed into work tasks according to the specialization and focus of the teams and their product owners.
For instance, the Billing Engine Team must receive the tasks for the changes in the Billing Engine for the “Customer Retention” epic. The same goes for the Product Search Team and other teams.
Again, why? Because “Efficiency Through Specialization” and “Focus Equals Efficiency”. Because someone has designed a company like that.
And that's not the only project there is. How many other projects are the teams juggling simultaneously in that company? Five, ten, twenty-five, a hundred?...
In that context: what are the odds that the “Customer Retention” project-epic-initiative-bet will be started and done in the next sprint by all the team working on it together? That probability is close to zero. Such organizations cannot work as one, they are fragmented and look more like a group of small sales boats than a well-build nice-looking cruise ship.
Everyone is busy, everything is slow.
Business Agility cannot be achieved through specialization and focus. Those things can even harm it.
Business Agility requires stronger cohesiveness between the teams: a shared focus and broader specialization.
Elevating to Close The Product Gap
In case you missed it, the latest hype in the agile space is about Product. Many people are talking about Product Management, Product Managers, Product Leads, Empowered Product Teams, etc. The so-called “Product Operating Model” is the latest promise to solve our digital product development problems.
This is a promising model, and we want to subscribe to the hopes it brings. However, we also believe that culture follows structure and that specific organizational design changes will make the application of the model more successful.
Org Topologies™ offers a set of guides and practices called Elevating Structures. In this context, we discuss elevating the product owners and the teams.
Elevating The Product Owner Role
Many organizations that recognize that they are in the field of product development have an established position called a Product Manager (PM).
PMs have a rather holistic view and speak the customer and business language. We can say they live on the Business side of the company. They must be visionary and responsible for delivering a Product that addresses a real need and represents a viable business opportunity. They implement the company's strategy through the Product and work on product-related tasks such as pricing, packaging, releasing, innovating, branding, advertising, etc.
As per the Org Topologies™ map, the Product Manager is located in the upper left part of (C0/C1) the map - they oversee a large scope.
However, because of the dysfunction of the product owners (lowercase) described above, those PMs were structurally separated from real ongoing product development. They are not driving features. They are not collaborating with the teams. The product owners take the space between the PMs and teams.
It's time to change that.
To close the Product Gap, we need to connect those PM directly to the teams. In other words, remove the product owners, and make the PMs the Product Owners.
They shall act like mini-CEOs and manage a strategic Product Backlog. In many companies, such a Backlog already exists but has different names (a Product Portfolio, a List of Company Bets, OKRs).
Instead of playing the role of a tactical business analyst, the Product Owner is a strategist. They will spend most of their time managing stakeholders and prioritizing for value. Teams then can learn to work directly with the customers and stakeholders to collect the details they need.
Elevating the Teams
Elevated Product Owners will own the Products, not the teams. That means Product Owners must embrace working directly with many teams.
To move the teams within the reach of the Product Owners, we must elevate the teams by creating Teams of Teams with a business problem scope.
Each business problem scope needs a single Product Owner and a Team of Teams. Such an organizational constellation can be called a Product Group. It is a holistic unit that has an end-to-end responsibility for a certain business impact.
Creating a Team of Teams is similar to creating a cross-functional team with individuals but at a higher level of abstraction. Instead of combining individuals to solve problems at the feature level, we combine teams to solve problems at the business level. Each Team of Teams must have all the capabilities to solve any problem within their sphere of shared ownership.
Elevating the Sprints
Having a single business-level Product Backlog with Teams of Teams creates the opportunity for teams to abandon the isolation of their team-level sprints. The business-level Product Backlog contains big and important items that are best addressed through the collaboration of multiple teams. They study and do the work in a shared cadence - a Product Sprint.
We all know that a common goal makes the difference between a group of people and a team. By working in sync, dependencies between isolated teams turn from interruptions into opportunities for collaboration within the Team of Teams.
In addition, the value delivered in each Sprint will be a business-level outcome. Stakeholders will benefit from attending an overall Sprint Review to inspect the return on their investment.
Elevating Engineering Practices
An important prerequisite to getting the best out of this approach is shared multi-team code ownership.
This implies we need to break the team-feature coupling and broaden the team's scope of work from tasks or features to the whole company domain. (If a company is too big, we define parts of the business domain that are independent of each other).
The goal is for all developers to work on many components, and ideally, they can change all the code. Most people say this is impossible and undesirable because this will create chaos. On the other hand, the results of private code ownership aren’t great either: complex code and standardization problems. So why not give it a try?
Shared code ownership can be achieved gradually and thoughtfully. How about opening those repositories that need to be changed most of the time for most of the developers?
Many approaches are available to make this prerequisite less scary (shared standards, stack simplification, automation, to name but a few).
And What About the Team Output Owners?
There are many options depending on what those people are skilled in and what they want to do in the new org.
But in most cases, product owners (lowercase) possess great knowledge about some given product parts, they understand certain aspects of business processes, know how to analyze and split large requirements, some even still can code...
That would make them great team members, no?
Summary
Business Agility means that a company can decide to work on what is most important at any given moment at no additional cost.
Business Agility can be structurally enabled by:
Closing the “Product Gap”
Elevating Product Owners to the level of the Product
Elevating teams and forming Team of Teams
Elevating the Sprint
Elevating the Engineering Practices
Forming Product Groups where people collaborate jointly on the challenges of the Product
Learn more about the Elevating Structures™ to discover more ways to elevate your ecosystem and gain the true benefits of agility.
© 2024, Roland Flemm and Alexey Krivitsky
