I have worked with my share of product companies – extremely large and extremely small. One thing that always surprises me is how so many of them fail to build a scalable product team that can act as a growth engine for their business.

Scalable Product Team

What do I mean by ‘scalable product team’?

A scalable product team is one which can grow (at least linearly) if you inject resources.

Here is a test: say you have a team of 50 product folks (engineers, designers, PMs). If I give it money to grow by 100% in 6 months and deliver at least 100% more next year, can it exceed my expectations? For most organizations, unfortunately, the answer is no. There will be all kinds of challenges – some external, some internal. They may not have a good hiring pipeline (because they do not have a good brand value in the market), they may not have enough leaders who can independently take charge (and that can’t be created in 6 months), they may not have enough subject matter experts who can handle the extra work when it comes (again, hard to create this in 6 months). These are just three bottlenecks that come to mind immediately, there will be many more. A scalable product team keeps working on these dimensions at all times, while delivering the product releases, so that they can grow fast when resources become available.

VC investments work well when you have a scalable product team in place, otherwise the money doesn’t get you right ROI. Same applies to other parts of organization in a product startup, I am taking product team example because I feel this has an outsized impact on the company.

I think most startup founders understand this point and have the right intention – to build a great product team and keep improving it. Still, the result is that most companies do not do a good job of having a scalable product team.

It is hard to build a scalable product team

What I want to point out in this blog is that it is not the lack of intent, or ability, that causes this. A product organization is structured in a way (by structure I mean not only the organization structure, but the processes, and interrelationships among them) that makes it produce a good enough product team and not a great one. Even the best intent of the founders do not produce the desired change because the ‘system is wired that way’.

If you are founder or a product leader, you might ask: What does it even mean “System is wired that way.” We are not defining our own org structure, we just do what others do.

System here includes the structure as well as people and their actions. What I want to show here is a way of looking at this system which can explain what produces this problem in spite of the best intent, and hopefully also show how it can be tackled. For that, we take a detour into understanding what ‘systems thinking’ is and then apply it to a typical product company.

Making sense through systems thinking

Systems science has been around from the beginning of twentieth century. In 1960s, Jay W Forrester, published his work on System Dynamics and applied it to industrial and social systems which was continued by his student Donella Meadows through the book The Limits to Growth. Peter Senge published The Fifth Discipline: The Art and Practice of the Learning Organization which explored the use of systems thinking in organizations. Donella Meadows later wrote a landmark book Thinking In Systems: A Primer, a highly recommended book to get introduced to systems thinking – it is simple enough that it can be read by anyone from a high schooler to a veteran CEO/Founder.

Systems thinking posits that the behavior we see in a system is inherent in its structure, so unless we understand the overall structure, we can’t understand the behavior or try to change it. It warns against thinking in terms of components because the behavior emerges from the interactions between components, and just the component-level understanding is not enough and can delude us into making faulty decisions.

The key notion it espouses is that of a feedback loop. All natural systems (and most systems we have created) exhibit feedback loops – output of an action eventually becoming input to the component that causes action. Whether this is desirable for the system or not depends on the nature of the system. When the feedback loop reinforces a change in the system, we call it a reinforcing loop. For example, more sales means more money for new product building, which in turn means more sales. When the feedback loop opposes a change in the system, we call it a balancing loop. For example, more customers mean lower customer satisfaction, which lowers sales which reduces customers, and hence number of customers is balanced. (here is a short note I wrote on this topic earlier).

There is an additional notion that is very important for systems – delay. The result of a loop doesn’t show up immediately. For example, more customers will cause lower customer satisfaction, but it will take a few months (or more) before it shows up. When you increase thermostat in the room to increase heat, it takes some time before the room actually heats up. Delays can cause unexpected behaviors since the result is not immediately available. In thermostat example, the user may keep pushing the thermostat higher to get it to heat the room quicker, and when it does, it is too hot, and the user reduces the temperature a lot (because of lack of immediate response), and it cools a lot after a while, thus creating a cyclic up and down of temperature (unless the user understands the phenomenon and waits patiently for the temperature change to kick in the first time!).

These three concepts of reinforcing loop, balancing loop and delay can explain a lot about our organizations and its behavior.

We will use this to understand the structure (and behavior) of our product organizations.

Causal diagrams for product organizations

We will draw what are called causal diagrams. There are three concepts to note:

1. Words (variables): The words represent quantities whose value changes over time, also called variables. They can be tangible, like the size of product team, or intangible, like brand value. 
2. Arrows: An arrow between two variables suggests a causal relationship – one quantity causes another quantity to change. The relationship can be positive or negative which are shown by black and red arrow respectively. 
3. Relationships: A positive relationship (shown as a black directed arrow) between quantities X and Y means that Y changes in the same direction as X – when X increases (or decreases), Y increases (or decreases). A negative relationship (shown as a red directed arrow) means that Y changes in the opposite direction of X – when X increases (or decreases), Y decreases (or increases).

New products are launched periodically

So new products get launched, which increases sales (positive relationship), which in turn increases R&D budget, which increases Product team size, which improves release efficiency (how much new features can be released in unit time), which in turn increases the number of new products (or feature). Thus this is a reinforcing loop. This will keep driving the sales up and the team size will continue to grow. But can it grow infinitely?

Product team becomes too big

As the figure indicates, as the Product team size grows due to the reinforcing loop in Figure 1, the % of leaders and SMEs required for the team starts going down (negative relationship between Product team size and Leader and SME %) because it is much harder to hire/groom leaders or SMEs in short time. Reduction in this ratio causes the release efficiency to go down (so less can be released in the same unit of time), which slows down the new product release. Thus we have a balancing loop that gets activated. Is that the only balancing loop?

Customer list becomes large

The diagram gets a few more variables and arrows but the idea is simple: as sales grow (due to the reinforcing loop of Figure 1), it increases customers, which reduces customer satisfaction (too many customers means less attention on each customer). Release efficiency is applied to product improvements which increases customer satisfaction. However, more focus on new products will cause less focus on Product improvements, which gives rise to another balancing loop. Depending on how company has managed, some of these balancing loops (including the one in Figure 2) can overpower the reinforcing loop in Figure 1 and the grown can slow down significantly. Can we do something about it?

Addressing Leader and SME scarcity

As the figure shows, the organization can offer Learning and Development to the existing product employees so that Leaders and SME % can be increased, which will improve the release efficiency. Note that we have added the variable Feature backlog to capture the fact that customer requests accumulate, and the more they accumulate, the more ‘all hands on deck’ phenomenon can kick-in which means less Learning and Development (hence negative relationship). If the Release efficiency goes down, that also will reduce Learning and Development (to try and improve the efficiency). This is a reinforcing loop (Learning and Development –> Leader and SME % –> Release efficiency–>Learning and Development), however its intensity will be determined by how much is it dragged down by Feature backlog and reduced Release efficiency.

And so on..

As you can imagine, there are many more reinforcing and balancing loops at play here, and specific companies will have specific loops in their system. Important thing to note is the way we think about the variables and relationships and the fact that we always look for loops to understand the behavior.

We have not talked of delay but it is everywhere in this system. For example, customer satisfaction drops after a few months and not immediately as customers accumulate. Learning and Development impact on Leader % takes time to kick-in.

There are two important points to note in these diagrams.

When there is a balancing loop in the diagram, pushing hard doesn’t help – the system pushes back harder, and the change does not stick. So when you see something like this happening in your company, there may be a balancing loop somewhere that you are not accounting for.

You should also be aware of reinforcing loops. While they can drive growth because increase in a variable increases the other (more product launches means more sales), it can drag you down when the variable decreases (a slowness in product launches will slow the sales, which in turn will slow the product launches further) and can be worse than a balancing loop in some cases.

So what about scalable product team?

We can now come back to the original question: why is it hard to build a scalable product team? As Figures 1-4 show, there are multiple reinforcing and balancing loops at play in a product organization, each with delays. If the causal relationship has high delay, the benefits or losses caused by a change in the variable show up much later than the action that caused it. This means a few things:

1. The impact is a long-range impact and a high-velocity product team doesn’t have time to invest in such long-range measures so they don’t do it, instead they look for a short-term measure which may have unintended consequences by creating new loops (training and coaching takes time so let’s hire a professional manager to manage people, which means the people remain untrained and the professional manager not knowing the product causes demotivation in the team which reduces release efficiency).
2. The impact comes so late that people do not realize it is caused by the change in that variable that was done by them (a decision to not train people can make them inefficient, causing stress, and they leave, but the attrition is blamed on the individual or the manager).

We talked about two reasons why organizations may not have scalable product teams: lack of brand value to hire people on demand, and lack of sufficient leaders and SMEs. As you can imaging, both of these are long-term impact activities and usually gets deferred. Most of the problems caused by not investing in these measures can be attributed to factors beyond our control (bad hiring conditions, people don’t want to put the hard work to learn, etc.), we end up not increasing the priority for these initiatives either.

If only more founders and product leaders could apply systems thinking!