Few topics are discussed more often in companies than the organization. How to organize people into teams? How to organize functions into departments? Where to allocate responsibilities? The problems of the existing organization. How much better things would be if we did it differently? And so on.
This is particularly the case with product management as it sits right on the boundary between the business and R&D side of the company. Interestingly, we can identify a trend where in some companies, like Airbnb, the product management function is disbanded. Instead, product management becomes a part of everyone’s role and each individual is expected to spend time on aligning the why and what with their peers, the team and the rest of the organization.
Although the Airbnb approach isn’t for everyone, it highlights an important principle: we should focus on the activities that need to be performed and spend less time on the specific organizational structure. Earlier in this series, I mentioned the BAPO model where we start with business strategy, define architecture based on that, then define processes and ways of working and only then talk about organization.
However, no matter how we think about this, product management activities need to be organized and we need to discuss how we go about this. Rather than offering an organizational blueprint, we’ll discuss a set of principles that are helpful when thinking about the organization. These include “span of control”, avoiding specialization, minimizing handovers, end-to-end responsibility and alignment through architecture and KPIs.
First, in management, there’s a concept of “span of control,” indicating the number of direct reports a manager can handle. The notion is that the more hands-on a manager needs to be, the smaller the “span of control” is. In product management, similar principles are used concerning the scope a product manager can handle. One of the things that generally is highly underappreciated is the role of automation in the ability to increase the scope or span of any function. By automating all the lower-value, more mundane and repetitive tasks, the idea is that each individual can manage a much larger scope than without the automated support.
This is critically important as every time we seek to scale an activity by breaking it into two roles, we’re introducing a significant cost for coordination and alignment between the two individuals now occupying the two roles. Anywhere we can avoid separating an activity into multiple roles or, where feasible, reintegrate a split activity into a single role, we increase the efficiency and effectiveness significantly.
Second, avoid specialization. As humans, we have a natural tendency to seek to specialize – it can easily be claimed that much of the progress of humankind is driven by specialization. However, specialization only works if the task we specialize in has longevity. The challenge in digital companies is that things move so quickly that something that was critically important yesterday is no longer relevant today. As we often consider our specialization as something very important, it leads to a situation where we stick with it even if it’s no longer relevant. Instead, we need to be generalists who can rapidly move from one area to the next without getting stuck in any specific one. We have to focus our energy on that which is most important right now and move on as soon as it stops being that.
Third, few productivity killers are more effective than handovers. The idea of having one person do the first part of a task and then handing it over to somebody else for the next part is a beautiful concept in theory but pretty awful in practice. It works if the activities are highly standardized and repetitive, but in that case, the activities should be automated anyway. For work that requires human intelligence, we typically run into the “knowledge iceberg” problem: what’s documented in the handover is only 1-10 percent of the total knowledge accumulated. The remaining knowledge sits tacitly in the head of the person who did the first part of the task and isn’t transitioned as part of the handover.
This brings me to the fourth principle: end-to-end responsibility. In my experience, individuals and teams should to the largest extent own a slice of functionality from the early stages of exploration to the evolution of the functionality after it’s been released to customers. Of course, there are always “buts and ifs” associated with this, but where we can accomplish it, we succeed in minimizing handovers and keep all the relevant knowledge in the heads of the team members.
And then, finally, this requires us to think about architecture as a careful design that can significantly simplify the end-to-end responsibility for teams with minimal interaction between them. Most of us waste a significant portion of our lives in meetings. These meetings are typically there to synchronize and align. Although it works, it’s much less efficient than synchronizing through architectural interfaces. As long as none of the teams materially changes the interface, both sides can work independently of each other.
The second part of the fifth principle is concerned with KPIs. Rather than bringing everyone together in meetings to discuss, defining KPIs that each team is responsible for as well as defining guardrail KPIs that aren’t allowed to deteriorate beyond a certain level allows for teams to work independently in situations where one’s work does affect the other. Defining and tracking KPIs can minimize process-driven interaction, which goes a long way to increasing performance.
Instead of providing a blueprint for organizing product management, I’ve discussed five principles to consider while organizing the product management activities. These include “span of control”, avoiding specialization, minimizing handovers, end-to-end responsibility and alignment through architecture and KPIs. We need to organize the work, but we shouldn’t get stuck in one way of thinking about it. As Peter Senge said: “The learning organization is an organization that’s continuously expanding its capacity to create its future.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
