Product Led Growth and the Role of Engineering
Tags: startup, engineering, growth, opensource
Published: 2021-04-14 14:58:00

by [Akshay Rangasai](Akshay Rangasai)

Product led growth as a concept is making the rounds. [Investors cannot get enough of it](https://www.bvp.com/assets/media/state-of-the-cloud-2021-bessemer-venture-partners-report.pdf), Twitter is filled with threads about this topic, and many dedicated channels and podcasts are talking about this “new” growth paradigm. However, product-led growth is not something new and has existed for ages. The internet and digital products (Tech companies - Primarily SaaS and consumer internet) have brought this in focus. Growth in organizations has always been tied to marketing and sales, but product-led growth forces us to change that perspective and think about organizations differently.

In this post, we will explore the history of growth for companies, the rise of product-led growth, and why the key to driving it is to think about engineering and product teams as revenue generators rather than just cost resources that need to be allocated optimally. 

## How the internet changed growth for companies

Historically, the three key pillars to driving growth are Price, Product, and Distribution. Price and product dictate demand, while distribution ensures products are available to satisfy demand. The new world with digital products changes a little bit but with massive consequences.  Nevertheless, to understand why we need to focus on product as the key driver of growth, we need to dive into the history of product development and how businesses monetized products.

Before the advent of computers, most of the real-world products were physical objects that needed to be manufactured, priced and distributed. Product development took ages, manufacturing took as much time, and as if this was not enough, you needed to find distributors to distribute products. Computers solved this problem by making each step easier and faster and created a whole new category of digital products.

The software was quicker to make and did not have the manufacturing overheads, but distribution was still a problem. The other big problem in both models was the product itself. You did not know if the product was good or not till you bought it. The ability to have information to make sound product decisions was again constrained by distributing a publication (Like Gartner). If you subscribed, you got it; if not, you didn’t. This meant that product development was a cost, and sales and marketing were revenue-generating functions. Distribution was key. Most companies treated engineering and product as allocated resources, and sales took a lot of the value generated from selling this product. This was just how the old world worked.

The software also hacked the working capital cycles that plague most manufacturing companies. Not only do you need to set up the infrastructure and pay wages to workers, but you also had to foot the bill for each item being made, and then you made it back when selling the product. As your company scaled, so did the requirement of capital. Scaling rapidly was not just a function of people but also a function of how much money you had, or how many loans you could get to foot this bill. Software hacked this cycle; it was infinitely distributable, without any additional cost of production. If you had enough distribution, you could scale easily. The collection cycles also made the companies cash-rich and did not need as much money as other product companies to grow.

Then came the internet. While you can claim that the internet made distribution cheaper, it isn’t really clear if it did. It made distribution faster, but discovery (of products and customers) was still an unsolved problem. Gartner subscriptions came via email and mail. Search engines made distribution cheap. Discovery, which was one of the hardest problems to solve, got solved because of the speed and reach the internet offered. AWS made software development cheaper, you did not need a boatload of capital to start a software company. Gartner is getting replaced by Capterra and G2 for the same exact reason of discovery is cheaper, as is distribution. 

All the constraints that existed before to make sales the top dog in a company have been eroding over the years. These advances have made it a level playing field (for the most part). Information availability (G2, Capterra), near 0 cost of distribution and setup means that the only way a company can differentiate itself significantly from competition and win is through product.

## The new role of engineering in product-led companies

Cloud computing has made CI/CD possible, and this rapid iteration helps create value immediately instead of long product cycles. Every new feature that is released is monetizable almost instantaneously. Your engineering and product organization is directly contributing to revenue in a measurable way. This is not just an account expansion, or user acquisition focused growth; Retention is also significantly affected by your product's quality. Retention is the first step to growth. 

Engineering has always been an expensive talent in organizations. Whether it was for silicon chips or software, it was a scarce skill always in demand. The old paradigm of product development classified these skills as costs, making sense in that era. However, for product companies selling software and other digital goods, engineering should be seen as a lever for revenue generation. 

Newer organizations, especially in software, still treat engineering as a cost and allocate resources based on the cost that is saved by deploying this skill across the organization. Thus we see 100s of companies building their own recurring subscription infrastructure when [multiple SaaS companies](http://chargebee.com) exist to solve this problem. Non-customer facing development improves efficiencies within the organization, but allocating the same resources to customer-facing development could potentially have a significantly greater RoI if internal tooling is handled by other bought software or potentially spending as little time as possible in building internal tools (Non-customer-facing software).

What we think this means is that org and incentive structures need to change. It is not just a sales and marketing team generating revenue but also teams of product managers and engineers responsible for revenue growth. This may sound too harsh given how teams are structured now, but with better focus and newer org structures, this will only seem natural. 

## Our experiences and conclusion

We think it is time for companies to rethink their build vs buy decisions and consider product and engineering revenue generators. Opportunity costs in whatever form must also be taken into account while making these decisions. In the new age, the product will determine the winner, and it is essential to align your teams on this mission.

Our experience building Appsmith has yielded disproportionate returns by keeping engineering’s primary focus on customer-facing features and requests. We are seeing impressive growth over the last few months with pure product improvements and additions (support is included, of course, by our engineers!). Maybe we were lucky as we are building an internal app builder, and our team was forced to eat our dog food, but this is something that we believe has worked well for us, and we think other organizations should consider it more seriously.  

If you have any questions, suggestions or feedback, please feel free to share it at akshay@appsmith.com

Cover Image Credits: Photo by <a href="https://unsplash.com/@isaacmsmith?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Isaac Smith</a> on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>