Economics of Software (Part 4): Measuring the efficiency of product teams using the output curve

It is the fourth part of the series on Economics of Software. You can find the entire series below:

1. Part 1: Why traditional economics concepts do not apply to software?
2. Part 2: Elasticity of demand explained for software products
3. Part 3: When to invest in the infrastructure using the cost curve?
4. Part 4: Measuring the efficiency of product teams using the output curve

So far, we have covered many concepts like supply and demand, the elasticity of products, cost curves to determine operational efficiency. This essay will explore the output curve to assess efficiency. Furthermore, when and whom to hire.

What is an output curve?

An output curve is a relationship between the number of employees and their output. It helps us determine the efficiency of the employees. The output curve for traditional industries like manufacturing consists of the number of goods manufactured by the employees. Let’s take the example of mobile phone manufacturing from the earlier essay.

As we keep adding employees, the amount of the goods produced also increase. But it does not tell us anything about the efficiency. So let’s take the average of the number of goods produced per employee and plot a graph:

After we add the 4th employee, productivity decreases. If we plot the same curve with the cost curve learned earlier, we will get a complete picture of the operational efficiency. It provides us with helpful information about how to grow. For example, in this case, every manufacturing unit should not have more than three employees. Let’s try to understand something similar for software teams.

Plotting output curve for Scrum teams

As I mentioned a few times before, the marginal cost for software is almost zero. Once you have the product ready, you can produce infinite copies. This makes it difficult to plot an output curve. However, we could achieve this if you have a Scrum team. Scrum is an agile project management technique focused on increasing efficiency and reducing wastage. It has a concept of story points and velocity that could be useful here. I won’t go deep into the explanation of Scrum because that’s a topic for another day, but let me provide you an overview:

1. Scrum consists of breaking down the project into smaller chunks called sprints. The duration of these sprints could be two weeks (or more, but it should be constant)
2. Every feature you will cover in the sprint has a weightage called story points.
3. These story points differ from feature to feature. For example, if a feature is complex, it will have higher story points and vice versa.

Now, let’s take a hypothetical example and plot an output curve:

As per the graph above, having more than three engineers per team would reduce productivity. So it is best not to have more than three engineers per project.

However, there are a few flaws with Scrum. First, the story points are subjective to every team. So if you have a huge engineering team, the story points will vary from team to team. So this method becomes unreliable. Hence, we need to determine a different way for an efficient hiring process.

Hiring matrix for product organizations

We have established that measuring productivity could be difficult for software companies. Unless we get clarity about productivity, it is difficult to understand when to hire. But as a product organization, we should not employ recklessly. Although there are metrics like revenue per employee, it comes into the picture after hiring. So let’s try to take a jab at it.

There are two segments in a product organization:

1. Supply team: Consists of engineers, QA, designers, product managers who drive the supply side of the software
2. Demand team: Consists of sales and marketing folks who drive the demand side of the software.

Unlike other industries, KPIs for both supply and demand defer because of the zero marginal cost of the software. The demand side has clear KPIs like increasing sales or customer acquisition. And the supply side, well, there isn’t one that could directly relate to the business. You have performance and release frequency, but it is not directly related to the supply side metrics. To understand the hiring strategy for the product team, we need both supply and demand to have the same metrics. So how could we do that? Adoption and Acquisition.

1. Adoption: As the name suggests, deals with the supply side.
2. Acquisition: As we already established, it deals with the demand side.

Have a look at the diagram below:

Let’s try to understand every single scenario and how it helps us in hiring:

The obvious question is determining a good benchmark for adoption and acquisition. Product or feature adoption varies from product to feature, but I strongly recommend you read Intercom on Product Management; they have done a great job explaining feature adoption. As far as growth metrics are concerned, they also vary from company to company and phase to phase. For example, if you are in the super early stage, then 100% growth MoM would be feasible for you, but 30-40% growth MoM would be treated as a victory as the product matures.

How does this help me as a PM?

Unfortunately, the Product Manager is the most influential person in a product organization but has little control over the organization. Unless you are a senior product leader, you are very unlikely to have a say in the hiring decisions. However, you could always provide opinions in the hiring decisions. After all, delivering a successful product is what you care about. If your peers are hiring at the wrong phase, you will be able to figure it out.

And that’s all we have in the fourth part of the series. I hope understanding the output curve was helpful to you. Feel free to share your feedback at nihar@sawant.me. I am more than happy to hear your thoughts.