The irony of product-led growth

It is a common sight in product organizations that product roadmaps are packed with new additions, as if every user is desperately waiting for all of them. Contrary to this assumption, a considerable proportion of the user base is primarily interested in the core value of the product, while the rest of the features are just perceived as noise. And exactly this circumstance is a little-noticed conflict of interest in product-led growth: PLG leverages the product itself as the primary driver to increase market share. However, the product scope does not necessarily have to grow in order to increase the market share.

The paper "Adding is Favored Over Subtracting in Problem Solving" published in Nature, offers valuable insights for anyone involved in prioritizing product initiatives. It reminds product leaders to strike a balance between expanding the range of functionalities and removing complexity from the product to drive both customer and business value.

Expanding the scope of a product isn’t inherently wrong. So pause and consider for a moment: is there a simpler way to solve a user problem? Maybe it's not a good idea to overload the product even more. Instead just focus on the core functionality and remove all the bells and whistles that have accumulated over time.

Marty Cagan coined the terms “feature teams”, “delivery teams” and “empowered product teams”. The distinction between addition and subtraction in product development can well be assigned to the different team types: feature and delivery teams tend to constantly add something in the hope of adding user value and contributing to the growth of the product. Empowered product teams, on the other hand, have the autonomy to take a step back and consider the possibility of creating value through subtraction.

There is a plausible behavioral psychological explanation why adding is easier than removing (in product management and also in completely different disciplines).

The researchers Meyvis & Yoon argue that people naturally lean towards solutions that add rather than subtract, even when adding is more complicated. People do this because they do not consider the subtractive solution at all, or it’s dismissed as being less valuable. Taking something away might seem less creative or even provoke a negative reaction from the original creator.

In many product organizations, the mindset “more is better” drives decision-making. Adding new features is seen as progress and a way to differentiate from competitors. But instead of asking, “What can we add here?” product managers should more often ask “What can we remove?” to solve a user problem. Subtraction isn’t just minimalism for its own sake - it is an approach that brings four benefits in product led growth:

Product led growth relies on a strong user experience: the product itself is responsible for acquiring new users so it’s key to prioritize it above all. Reducing the number of choices simplifies the user experience and is helping users to focus on core functionalities. Bloated products force users to wade through options, consuming time and increasing the likelihood of abandonment. Jakob Nielsen has long warned that “Every extra unit of information in an interface competes with the relevant units of information and diminishes their relative visibility.”

Cognitive load refers to the mental effort when processing cognitive tasks. This applies equally to software engineers, product managers, UX designers and all other team members involved. As the product becomes more complex, the cognitive load to extend it increases. For example, software engineers face a higher level of cognitive effort to read existing source code or to understand the dependencies between system components.

For designers and product management, bloated products result in longer lead times: The ideation and conceptual work becomes less efficient and takes an unnecessarily long time if a large number of legacy issues have to be taken into account.

The team can now invest the freed-up cognitive capacity in more meaningful areas than the maintenance of unnecessary ballast that has accumulated over time.

Eliminating features can reduce technical debt, so the unnecessary complexity that accumulates in a system over time. Or ”cruft”, as Ward Cunningham called it. Cunningham is a software engineering pioneer who coined the concept of technical debt in the 1990s. By eliminating it, both users and product engineering teams benefit from more stable systems and lower failure rates in production.

The book "Accelerate: The Science Behind DevOps" shows a clear link between technical debt and error rates (measured by the Change Fail Rate): "We believe this new work could be occurring at the expense of ignoring critical rework, thus racking up technical debt which in turn leads to more fragile systems and, therefore, a higher change fail rate".

Now the hypothesis is: by getting rid of technical debt, you stabilize the product. As a result, the number of defects in production decreases. Fewer defects are good for the user experience and contribute to product-led growth.

Subtracting unnecessary parts of the product can lead to directly measurable cost savings. Especially In a cloud environment such as AWS, that is in many cases based on "pay for what you use" pricing. For example, costs arise from the use of EC2 instances to host applications or backend services. Or with AWS Lambda, pricing is based on the number of function calls and the computing time used. So the rule of thumb is: the less happens, the lower the costs. The freed-up financial resources are now available elsewhere in the budget allocation to 

Picture the planning process for your organization’s upcoming priorities. According to Meyvis & Yoon, the issue is that subtractive solutions often aren’t considered, and even when they are, they’re undervalued for socio-psychological reasons. It’s up to the product leadership to explicitly highlight the user and business benefits of subtractive solutions, ensuring they are recognized and appreciated. 

This could be done through initiatives aimed at simplifying products. Or even better: by empowering teams to choose whether the solution should add or subtract functionalities to solve a user problem. Another approach: using frameworks like OKRs, organizations can set objectives that allow for both additive and subtractive key results, giving teams the freedom to decide how to solve user problems.

For almost all leading tech companies, it is part of product portfolio management to discontinue products or features when they are at the end of their life cycle or do not meet the original expectations.

For example: LinkedIn has decided not to continue with its own story format. Uber ended its loyalty program “Uber Rewards”. Apple has said goodbye to the touch bar for Macs. Websites like “Killed by Google” or “The Google Cemetery” list hundreds of products and features that Google has discontinued over the years. Google+ is another prominent discontinued example (Google’s social network in the 2010s).

Can we celebrate products that have been shut down as a success? Not in the short term from the perspective of the killed product. But definitely in the long term and with a view to the underlying approach in product development. The examples mentioned have one thing in common: the companies rely on iterative development - failures are just as important as successes. Failures are carefully observed, lessons are learned and there is a good chance of a big hit in later iterations.

It's useful to remember that despite the widespread bias towards addition, there is considerable value in subtraction to drive product-led growth. If simplification is made in the right places, the user experience of the product benefits, technical debt is reduced, the team cognitive load decreases and cloud costs can be saved.

It's up to the product leadership team to foster a culture of simplifying products and to empower teams to decide independently whether subtraction is the appropriate approach to drive customer and business value. Not continuing with a product or feature is not an admission that a hypothesis or even a big bet did not work out. It’s an intermediate step in iterative product development: simplifying and refining can make great progress in product-led growth by focusing on the core value of the product and learning from each iteration.

Read more great Product-led Growth content on Mind the Product