Be(com)ing a Product-Led Company

Being a “Product-led company” is a buzzword that’s being talked about quite often. Some companies want to move to a product-led model, some are strongly product-led, while some say or think they are but might be working off external requirements from a limited number of clients/users a majority of the time. While it’s quite hip to talk about product-led, let’s first review the background and then talk about pragmatic actions to be(come) product-led versus what a service model looks like.

Why Would You Want To Be Product-Led?

Mostly, scalability. Also, it’s a very satisfying challenge to crack ;)

If you want your product to solve problems for a wide customer base, you need to find how to create value at scale. The Product Management toolkit offers various approaches to iterate and improve your solutions in order to achieve that scale. However, to be efficient, you need the whole company to stand behind the drive.

Of course, if you talk to a service business that has 3 clients, builds features as per their requests, and is working well - no need to change anything. It fully depends on what you want.

Unlike the service business, building at scale means purely individual build requests will be distractions. Scaling means selling every hour of invested work many times over, not just once.

The Product Aspects

Putting the product first means deep focus in all areas of a company. A few practical highlights along the product life-cycle are as follows:

Audience.

It’s impossible to build software that makes everyone happy. To scale, it’s important to focus on the audience groups that will bring you scale rapidly. Whether B2B or B2C, identifying your different audiences and what you think your product will do for each of them is the first step. Large enterprises? Individual consumers? SMBs in a particular vertical?

As an example, if you are gunning for SMBs, you will need a self-service signup. If you don’t have that, it will simply cost too much to onboard SMBs manually, driving your profit down massively. Hence, it’s crucial to identify and prioritise your audiences.

The service model counter-example: you have clients who are your audience and tell you exactly what they want.

Prioritisation.

The second hard step is to prioritise all your various ideas into a roadmap. For this, you’ll need a framework that allows you to rank your ideas. Consider a growth phase in which you want to acquire a large number of new users. You will focus on product features that are attractive for new users, and on growth mechanics. By applying that filter to your list of ideas/features, you can sort them and come up with a roadmap!

As an example on Gmail, we identified a major friction point for users to adopt Gmail: they would lose all their other email history, wherever it was they were migrating from. To grow faster, we prioritised import functionality. This removed a major stumbling block and allowed us to grow faster.

The service model counter-example: the priority is what the client wants. Whether driven by fixed dates such as a Christmas sales rush or a fixed marketing campaign tied to the school start - the client will tell you what and when.

Scope & impact.

Of course, the prioritisation won’t work unless you actually assess the impact of all the features within the current prioritisation. This is something the product team needs to do, by getting what information they can through talking to many teams, doing some research, and probably crunching some numbers. This is something that will help to not only have an idea of what a launch of that feature would presumably look like, but also to create a set of success metrics.

When building an ML-driven ads targeting engine, we wanted to predict our impact. We started with estimating how much more click-through we would have. But we found out that the easiest way was to estimate the potential incremental revenue per segment and geography, which also gave us a very simple way to communicate complex ML features with the board.

The service model counter-example: clients say why they need the features and what this represents for them.

Launch & measure.

Once launched, to understand whether a feature contributes to the success of a platform, you have to measure how it performs. Does it perform as predicted? You’re good at predictions :) Does it underperform? Maybe something’s wrong with the implementation, or it’s not as useful as you thought and you might consider shutting it down. Does it perform way better than expected? There might be a winner in the making that you need to double down on. In short, measuring will allow you to take decisions on what to do about certain features.

On a B2C mobile music tech app, we wanted to know what the effect of a feature focused on retention was. We used Mixpanel to segment the cohorts of users just before the launch of the feature vs the first batch of users who signed up with that feature. We made sure we knew our maths to make sure we’re excluding noise and biases from our numbers to understand the (hopefully) positive increased retention, and then let that be our guidance for analysis and future decisions - not what we thought of our feature.

The service model counter example: the measurement is the launch. The client has the feature, success. Even if only a single employee of the client uses a feature, it may just be that this person performs a critical task - hence the feature is successful just by having been built.

Last but not Least, Growth

We started out by saying that scale is the goal, and with the habit of measuring your launches, you can set up and run experiments to drive growth. This includes working on every aspect of the customer journey from acquisition, engagement, payments all the way to retention and referrals.

A great description of growth experiments at Duolingo, a language-learning app, to go from 5m to 200m users, has been written up here: https://twitter.com/Eepsita/status/1333407747111407621. 

The service model counter-example is around what the parameters are you can change: charge more through for example upselling new features to existing clients, or raise prices (to be done very carefully), or get more clients. The latter requires you to either hire a larger team to service those clients, or to start thinking about your product to be applicable for more than just a client - which slides you towards product led thinking.

What About The Other Teams?

For this to work, other teams need to be part of the effort. Let’s review a few examples:

Sales & Marketing

The core activity of these teams will change. They go from making a customer happy and having individual discussions with large customers to devising strategies and tactical initiatives for large groups of people. Instead of having discussions around what feature would make one happy, the effort is focused on how best to capture large numbers of users’ attention with the core values of the product. Additionally, the team will be key in helping with market research, geographical planning and the likes.

Customer Support

Instead of getting calls from a few large customers, CS will need to field a much larger volume of messages/calls, but often with less depth than expert customers. This opens up possibilities to scale on the knowledge side, since much of the basic knowledge can be encapsulated in written form on FAQ pages, chatbots, email templates etc

Additionally, the CS team will be the first to know what users like and dislike, and its input into prioritising the roadmap is invaluable. The Product team and the CS team need to communicate often.

Leadership

In fully digitally native product companies that have started like this from day 1, it is mostly understood how this kind of model is run. But any other company will have to adjust its leadership management style. Growth being an integral part of the company means that management cannot simply “wait for results”, but has to actively take part in the planning. Hard decisions will need to be taken to prioritise, at different times, initiatives from different teams that seem to be competing. A very good illustration of hard decisions is the story of how Facebook stagnated at 80m users and had to figure out what to do. Focus on product? Focus on growth instead? Focus on money? They took the decision to focus on product and growth, and deprioritise everything else for a while (incl. revenue) in order to free up staff for those two focus areas. The story is here: https://twitter.com/DanRose999/status/1312215292609662977. Those are very hard decisions to take.

Additionally, senior leadership will need to explain this to the Board in a way that allows them to see the goal and the path to that goal, while being aware of the risks. In larger, incumbent companies, a strong product-led model clashes with reducing the risk on future earnings, which results in many incumbents shutting down their experiments mid-way after a couple of years. If one plans a product-led company, think about your leadership layer all the way to the Board.

Enabling The People In Your Company

One very important aspect to mention, and that is often overlooked to an extent, is the team. When changing models, the team cannot always easily follow. Management needs to set up the structure so that those who want, can thrive, while those who fear being left behind can get help at being embedded into the new operating model.

Enjoy scaling!