This is part four and the last part of a series of blogs about the Agile Product Operating Model (APOM). It was inspired by a webinar and subsequent discussion on organizing a product group.
The question “How do you organize a product group?” seems the simplest to answer. Surely, you would organize your product organization around products. Each team or team of teams would align to a product, platform, or collection of products. And from my experience with start-ups, that works well. Product teams handle all aspects of product work, including discovery, delivery, and operations, which encompass support. But what happens when you grow?
Scaling or growth is the biggest challenge for product teams. For example, as a startup grows, the number of clients grows, and so does the number of features. The first area of stress is support and operations. Initially, a support team is created (and when I say team, it usually consists of 1 or 2 people) that handles first-level support requests. Then someone from the product team becomes dedicated to running and managing the services. Then comes the increased cognitive load from the number of features, making it hard for the team to focus. As a result, a new team is formed that takes ownership of a specific set of features. This leads to more teams and…
Well, you get the picture. As you grow, you tend to add people and organizational elements in response to increased workload and the perceived need to become more efficient through specialization.
Notice I say perceived need to be more efficient. Focusing on one element of the product value stream will enable a more focused approach to that process, but efficiency should not be about work; it should always be about delivering value. What is the most efficient way of delivering value? Which may or may not be directly related to efficiency or productivity in completing the work. I am paraphrasing what Donald Reinertsen says in his book, The Principles of Product Development Flow. Reinersten's first principle is: Improve Economic Decisions, which focuses on making decisions based on value rather than work.
SIDENOTE: I recommend Donald Reinersten’s book. All seven principles should be considered when organizing your product group. The idea is that product development should be treated as a flow system, and it can be more effective by applying principles around value, queuing theory, economics, and lean organizations.
However, for many organizations, adopting the Agile Product Operating Model (APOM) is not about scaling a startup, but rather about transitioning from a project-based world to one that is more product-based. Thus, there is an existing organization based on a collection of specialisms, such as applications, skills, or some combination of both. Project approaches often encourage scaling around work efficiency, which can pose challenges when transitioning to a product model.
Building organizations that enable product teams to flourish
You have all experienced that perfect period of your life when working in a fantastic team, delivering value frequently, and enjoying it. And, if you have not had that moment, you should strive for it. It is amazing. From my experience and many books, the ideal product team is:
- Small. Three to twelve people. I have seen bigger teams work, but ideally, it is the size where you can get a few tables at a bar and not have to call ahead :-)
- Cross-functional. That is a technology phrase, but if you work outside of software, you have all the skills necessary to deliver value. For example, if you are building a physical product, you may have skills in electronics, manufacturing, and other relevant areas.
- Flexible. Yes, you can have specialists, but they must blend together to do the work. And because work tends to be lumpy, those specialists better be willing to jump in and do whatever job needs to be done.
- Self-managed. Many books describe this characteristic, but in a nutshell, self-managed people do not need someone telling them how to work to accomplish their tasks. Yes, they are directed by a goal but manage themselves to deliver value.
In an ideal world, that is all you need to know about organizing a product organization. However, let's now discuss scaling or, in the case of an existing organization, reorganizing to become more product-centric.
Dealing with cognitive load (one view of scaling)
In the book Team Topologies, Matthew Skelton and Manuel Pais describe how organizations can effectively scale their product teams (stream-aligned teams) with four topologies and three interaction models. Let's explore their topologies:
- Stream Aligned Team, which I refer to as a product team.
- Platform Team is another type of product team.
- Enabling Team: This concept is similar to the Guild and Chapter idea from Spotify, providing a way to support cross-functional teams in delivering results without relying on specialist teams. For example, having an enabling team for a legacy system or skill enables product teams to pick up those skills and become more agile.
- Complicated subsystem team; OK, this is a huge question mark. I appreciate that this makes sense in certain situations, but why can't we treat these subsystems as products or enable the other teams to do the work?
The model they describe is useful when thinking about teams. However, based on my experience, I focus on two types of teams: Product / platform teams, as well as enabling teams. The value in treating both platform and complex subsystem teams as products is less about the semantics of the word "product" than about the additional benefits the idea that something is a product brings. Products have roadmaps, and they have users and stakeholders. They provide value that exceeds their cost. I understand that for sub-system teams, this seems like overhead. Still, if a team cannot quickly describe those few things, it is not a valuable capability for the organization.
Many of you say, "You have hammers (products), and everything is a nail." And perhaps you are right, but if a subsystem team has a hard time justifying its existence, then there may be something wrong.
Supporting Cross-Functional Teams
A fundamental challenge for all product organizations when considering scaling and managing team workload is determining when to split teams. One key idea in agile teams is that the team possesses all the necessary skills to deliver value. For some complex products, that means a very large number of skills, which conflicts with the sizing requirements for effective teamwork. As discussed by Skelton and Pais, this leads to different topologies, such as complicated sub-system teams and enabling teams. Enabling the team is the most overlooked idea and is crucial for agility to grow in a large enterprise.
When I worked at a startup, we had a very small team of software engineers. However, we were building integration software, which meant that as we added endpoints, we had to expand our skills. We did not have the luxury of hiring people; instead, we had to persuade others to help us. We begged and borrowed help from anywhere we could find it. As we grew, we tried to maintain a team model with all the necessary skills. This led to the need for skills to be shared and, more importantly, developed within teams. I struggled with how to develop my skills and ultimately adopted a mentoring and support model. I created an enabling team. This started with one person who spent all their time working with others helping them become more effective and transferring skills. Over time that team grew and we adopted a model where people moved out of product teams into the enabling team for a period of time.
Balancing building specialist teams that do the work versus specialist teams that enable others to do the job is a key idea. However, to effectively make the trade-off, you must think holistically about incentives and rewards. It is often challenging to incentivize people to transfer their knowledge and skills, ultimately making themselves less valuable. Building an enabling organization is relatively easy; creating an incentive program that encourages people to be part of it presents a different set of challenges. We should follow the mantra that my grandmother instilled in me when I got home from school, not "what did you do today", but instead "who did you help". A good product organization is one where everyone helps each other either formally via enabling teams or informally around professional networks.
There is no simple blueprint for success.
Could you apply a standard blueprint to your existing project-based organization? Not really. Unfortunately, every organization is unique due to a combination of existing systems, skills, culture, and bureaucracy. But the biggest reason for the differences is the people! Some people are more flexible, less power/hierarchy oriented, and desire to acquire new skills and focus on the customer. Tools like systems thinking can be helpful, and I recommend the book "Creating Agile Organizations" by Cesario Ramos and Ilia Pavlichenko. I also see some interesting ideas coming from Organizational Topologies. But in a nutshell, building product organizations focuses on four ideas:
- The primary organizational unit is functional, self-managed product teams.
- Think about shared services, internal capabilities, and platforms as products when scaling.
- Decouple product delivery from skills development and build skills (enabling) organizations.
- Balance people development (building flexibility) and product development (building value).
And because any change will ultimately be successful, it is because of the people. Remember, it is a people problem, so think holistically about the system.
For more insights, read the other parts of this series:
Read Part 1 - Fundamentals
Read Part 2 - Product Definition
Read Part 3 - Product Portfolio Management