Coordination Costs

Article originally published at Product Manager HQ on July 26, 2021.

Product managers are not just in charge of the products they build — they’re also in charge of the processes and systems around them, as they continue to unlock multiplicative value for their company.

Based on my experiences, I’ve found that there’s a rarely-discussed cost when it comes to shipping more and more products. That cost is what I call coordination cost.

You’ve run into coordination costs before. When you’re only working with one or two people, information flows very easily. But, when you’re working with twenty people, information is hard to get across. That’s the problem of coordination.

I’ll share a couple of mental models below on how I think about coordination cost, and how product organizations can tackle them. Note that this won’t be from the perspective of any single individual contributor, but rather from a total portfolio level.

The early days of a software company

When you first get started, your company really only has a single product and a single product team. As a software company, the product is the value of the company — no more, and no less.

So, let’s say that value(company) = value(product) to stand for that. The only way to make your company more valuable is to make your product more valuable, whether that’s identifying better product/market fit or whether that’s finding new features to ship in your product.

While small companies are heavily constrained by resources, the mission of the product team is crystal clear — there’s only one single mission to go after.

Let’s use some theoretical numbers to bring this concept to life. Let’s say that this is the breakdown of the company’s value:

Link to model: https://docs.google.com/spreadsheets/d/1fl_Wj4IMQ6k77wpoRKioQyvQH-VFu31lggefZUXr0vI/edit#gid=0

But what happens when a company introduces a second product line?

Adolescence of a software company

As the company grows, it finds that it’s getting diminishing marginal returns on the product that it’s built. It might have reached market saturation, or it might find that there are new opportunities outside of its core product where it can play.

The company decides to launch a new product. Now, we can say that the value of the company looks like the below:

value(company) = value(product1) + value(product2)

At a high level, this seems to make sense. After all, when you build a new product, you have a new market to go after and you have new streams of revenue that you can capture. Here, we can generally say that adding new products to a company’s portfolio appears to unlock additive value so far.

This is an easy way to quickly add value to an existing company. Investors might be pleased that the company increased its value so quickly. Here’s what that value might look like — note that the first product has more value since it’s been around longer and has attained a larger customer base, whereas the second product is still young.

Link to model: https://docs.google.com/spreadsheets/d/1fl_Wj4IMQ6k77wpoRKioQyvQH-VFu31lggefZUXr0vI/edit#gid=1385985643

But, any software company that is beholden to its investors must demonstrate additional growth. So, to double again, the company now must build two more products on top of its existing two products.

Now, the value might theoretically look like this:

value(company) = value(product1) + value(product2) + value(product3) + value(product4)

Yet, things seem to go haywire. As the company adds on more products, it doesn’t seem to be expanding linearly anymore. Rather, it appears that as the company adds on more products, its growth curve continues to slow down. Why is that?

Well, we forgot to account for coordination costs.

There are many kinds of coordination costs. Sometimes you’ll build something, just to find out that someone else already built the same thing. Other times, when you build a feature in your product, you cause a bug in someone else’s feature. Sometimes, you’ll use inconsistent architecture, which causes the engineering team to slow down significantly.

So, now our world looks like this:

value(company) = (value(product1) + value(product2) + value(product3) + value(product4)) * (1 — coordCost), where the coordination cost is a tax on all of your products.

If you’re familiar with the handshake problem, the number of times that you have to shake hands is (N-1) * N / 2. Let’s pretend that each handshake you must conduct is equivalent to 5% of productivity. Here, because there are 4 teams, this is (4–1) * 4 / 2 = 3 * 4 / 2 = 6 handshakes, which is 6 * 5% = 30% of lost productivity.

Link to model: https://docs.google.com/spreadsheets/d/1fl_Wj4IMQ6k77wpoRKioQyvQH-VFu31lggefZUXr0vI/edit#gid=2075349707

Notice how the total coordination cost is 240 units of value, which is higher than the 100 units of theoretical value of the company’s third product! As the company ships more and more products, it takes on a deeper and deeper coordination tax.

So how do companies get around this problem?

Mature software companies

A mature software company understands that there are significant coordination costs involved in shipping so many distinct products. So, it decides to invest in teams that are solely focused on reducing the costs that come with coordination.

The value of that team’s product is quite literally $0, because they’re not selling the product to anyone. Yet, this internal productivity team is insanely valuable. Why is that?

It’s because they’re decreasing the coordination cost. Imagine that you have a platform team that standardizes the way in which code is written. That might decrease the cost of each handshake from 5% down to 2%. Now what does the world look like when the company ships this fifth “product line that is solely focused on productivity”?

Remember, now that we have 5 teams, we need to recalculate the number of handshakes. We now have 4 * 5 / 2 = 10 handshakes to deal with. But, each handshake only costs us 2% now, so this is a coordination cost of 10 * 2% = 20% loss.

Link to model: https://docs.google.com/spreadsheets/d/1fl_Wj4IMQ6k77wpoRKioQyvQH-VFu31lggefZUXr0vI/edit#gid=2011582128

This internal team increased the company’s actual value from 560 to 640, which is a gain of 80. That means that it’s almost as valuable as a whole other product line on its own!

On top of that, this benefit lasts for all of the new products that continue to get shipped, which means that the company can now keep building with less loss.

Ways to decrease coordination costs

While coordination costs aren’t particularly important for early-stage small companies, they wield outside influence on the ability for mature software companies to deliver value. So, mature companies are always looking for ways to bring that coordination cost downward.

What are some ways they can do so? Well, the root cause of coordination cost comes from teams not knowing how to interact well with one another. So, finding ways to make it easier for teams to interact will reduce friction, which has a real impact on the bottom line.

Here are some concrete ways to reduce friction between product teams:

• Documentation
• Design patterns
• Mission statements
• North star metrics
• Dedicated platform teams
• Standardized product processes

Documentation makes it easier for teams to understand what other teams are building, how it’s built, and why it’s built that way.

Design patterns help teams understand what the best practice is for building a particular kind of functionality.

Mission statements ensure that everyone is working towards a common objective.

Similarly, north star metrics help keep teams tightly aligned towards the same goal.

And, by centralizing particular kinds of platform knowledge into a dedicated platform team, companies can strongly enforce a particular set of design patterns and ensure that their products are being built scalably, reliably, performantly, and robustly.

Lastly, by standardizing product processes, such as product spec reviews, feature release cadences, quarterly planning, experimentation, etc., companies can ensure that their product teams are speaking the same language, and that they’re not comparing apples to oranges.

In fact, one way companies standardize product processes is by creating dedicated product operations teams, which is a great way for mature product companies to continue scaling their impact.

Closing thoughts

I regularly tell aspiring product managers that it’s pretty different working at small software companies vs. large software companies. One of the key reasons why is the coordination cost.

At small companies, there are few coordination costs, so product managers can focus on the nuts and bolts of product management.

At larger organizations, coordination costs can consume significant value, so product managers at large organizations must dedicate significant time and energy towards reducing coordination costs. Those activities might include documenting their product behavior, clearing spec reviews with peers, or other product processes that are typically absent in smaller companies.

No matter what, as your company grows, you will run into the need to mitigate coordination costs. So, having this framework handy will help you stay ahead of the curve!

Want to learn more about coordination costs? Chat with other product managers around the world in our PMHQ Community!