What exactly is a product-led process?
Something that has been bothering me a lot as a PM (keeps me up at night, if you will) is figuring out what the “right” way to build products looks like. I’ve been a big fan of books and industry-leading companies that demonstrate how to build great products and what a great product-led strategy looks like, but product management is an interesting space — there are no right or wrong answers, a dilution of best practices out there, and a high variety of different processes companies follow. So I went on a hunt: What is the ultimate end-to-end process on how to decrease users’ time to value and how to learn quickly internally? What can I do to get there?
When we think about what makes a strategy product-led, I’ve narrowed it down to these main signals:
- Ensure product-market conditions are right
- The product offers a uniquely, valuable solution
- User is able to realize significant, ongoing value quickly and easily
- The product delivers real value before the paywall
- The product has features and functionalities that allow it to serve as an acquisition channel for marketing, selling, and onboarding new users.
- Marketing funnels lead to product engagement
- The product has a built-in network effect
- Within customers’ companies, there are product champions that will drive the internal adoption of the product.
So, that brings about the question: what is “right”? How do we know something provides “significant, ongoing, real value”? How do we ensure that product champions will be the main source of marketing to product engagement?
To establish a product-led strategy, product teams firstly need to be empowered in solving and understanding customers’ pain points. This means that leadership has to be 100% customer-centric. Not business-focused, not sales or marketing focused, but 100% dedicated to solving customers’ problems and converting them to being the product’s fans. There also needs to be an investment in enabling the product to be self-serve and getting customers to adopt it independently.
Before I jump into the breakdown of the process, it needs to be emphasized that this is going to be iterative, frequent, and constant. With product-led growth, product (especially growth-focused) teams need to revisit the customer journey on a regular basis. This will avoid outdated assumptions and decisions that are not backed by data.
What does solving customer problems look like?
When I think about what solving customers’ problems look like, I always refer to the Product Kata by Melissa Perri in her book Escaping the Build Trap.
Within the Product Kata, there are four main areas that we’ll break down into more granular ways of thinking:
- Understand the direction
- Problem exploration
- Solution exploration
- Solution optimization
Marty Cagan also talks about the four big risks when it comes to building better products: value risk, usability risk, feasibility risk, and business viability risk.
1. Understand the direction
This first step is to assess business viability. This is a given because the purpose of building a product is to ensure that it falls under the core competency of the business and that the idea works for all areas of the business. This will be through understanding the company’s vision and the strategic intent, or the company-wide product initiative.
This can be reflected through the company’s OKRs. It hinges on the entire company agreeing on what objective they should be working on and breaking that down into the respective teams to ladder into those specific key results. The company and leadership team needs to have a combination of the vision, goals (objectives) and metrics (key results) to create a system where the company can make decisions about its products. Within those OKRs, it’s important to align as a product team on the North Star and proxy metrics to ensure that the high-level OKRs are not “set and forget”. I learned this concept of proxy metrics a while back from Gibson Biddle’s newsletter, and it has helped our team focus on small experiments that bring about improvements in incrementally moving our conversion rate metric.
Proxy metrics are more sensitive metrics (compared to the North Star ones) that help measure progress and validate hypotheses quickly. The proxy metric should be sensitive (so that we can affect it in the short-term), independent (not affected by other product teams’ efforts), and not average (mostly focused on the bigger portion of customers and not just a subset).
When it comes to a product-led strategy, usually when we think about 5 key pillars:
- Virality (viral loop of value)
- Frictionless signup
- Deliver value quickly
- Value before money
- End-user focus
When it comes to specific North Star metrics, that pertains to customer activation (beyond engagement), shorter time to value, and then alternating KPIs based on changing growth priorities within the org. In this example, I’m going to use delivering value quickly as an example during the onboarding process. Assuming that we are in a company that has a high activation metric once a customer has engaged with the product, the North Star metric in this case might be focusing on monthly retention for first-time users. Within that, there are a few hypotheses that we can come up with:
- A more personalized onboarding experience
- A simpler onboarding experience
- Unique tools and features
Within that, proxy metrics should help prove out which hypothesis will improve the North Star metric, which in this case is monthly retention for first-time users. In that case, perhaps a proxy metric that we might use is a percentage of customers that have done a specific action on the product that has the high activation metric within their first month of the service.
The specific action is of course dependent on the product itself, and what the key activation action has been for the many other engaged customers that have stayed. We’re focusing on new customers in their first month given that that is (if true for that particular company) the crucial time in converting a customer from acquired to active.
This is one of a few proxy metric examples, and it can be more granular or wide-reaching, depending on how focused the problem we are trying to solve is. The key here is to be careful in not measuring vanity metrics or output-oriented metrics. Instead, it should help inform decisions and understanding when evaluating success.
All product-related activities contribute to revenue or cost for the business. It is important to not only identify lagging indicators (retention for example, given that it will take weeks or months to know whether a customer has stayed or left) and leading indicators (like the engagement of the product to understand happiness and customer value with the product).
At the same time though, we won’t be able to set success metrics of a specific hypothesis yet without investigating the problem. We will need to understand the problem discovered and the solution we are implementing to solve to set more granular success metrics that ladder up to it.
2. Problem exploration
My favourite part of being a product manager. In my ideal world, my days as a Product Manager are spending time talking to real-life customers to get to the heart of their problems. I’d be spending my time working with my product designer to do user research, observations, surveys, and customer feedback. But, unfortunately, we know that is not a common practice in most companies. Time is of essence and resources are limited.
This step will be crucial in helping us address value risk. This is to uncover whether customers will buy it or not.
For product-led companies, they empower product managers to identify the pain point and the root cause of their problems. In our case here, it might be talking to new customers that have dropped off the onboarding process or are simply not engaging with the product despite being on a free trial. And even if there is corporate bureaucracy, it’s time for us to get creative. It can be through working with customer success or sales reps in a B2B environment, or reaching out to our personal network if we’re in a B2C environment.
The key here is to ensure that we are asking customers the right questions — and not finding scrappy solutions. This can be through asking whys, and leveraging various mental models to ask better whys: first principles thinking, or inversion. It is to essentially ask the question “what is the biggest problem standing in your way to getting from point A to point B?”
When it comes to problem exploration, there are many techniques that we can work with our UX team to use: customer interviews (to understand customers better, the problems that they are trying to solve, how they are taking the route to solve those problems, and what is required for them to keep coming back) or customer visits (or as the book Inspired calls it, the concierge test), with both approaches often having a user research methodology behind them
This can be through the utilization of reference customers, which can be a powerful subset of customers that are not only bought into the product in making it succeed but also a great leading indicator of future product success. This can also be through creating a customer discovery program if there is a broader number of customers (usually B2C) that will allow for a wider reach of testing product ideas and a large recurring base.
Interestingly (and usually), solving one problem may uncover a bigger one. And upon discovering a bigger, relevant problem to solve, it is time for the fun part —solution exploration.
3. Solution exploration
During the solution exploration process, there are a few key questions to always keep in mind.
- What is that overall one problem our product is solving?
- Which alternatives could our customers draw on to solve that problem?
- What are the core value propositions that define our product?
- What makes our product unique?
This is also the time to start bringing in more teams (product team members and stakeholders). If there is high dependency, it is important to start bringing in other product teams. If there are business requirements that need clarification, it is important to bring in temporary stakeholders like customer success. Most importantly, the trifecta must be fully involved in the process: Product, Engineering, and UX. This can not only keep the product team empowered and accountable for the results, but also avoid confirmation bias since the three main pillars will bring about their own unique perspectives to the discussion.
There can be a few approaches to solution exploration:
- Upon coming out of the problem exploration phase, there may usually be a lot of uncertainty around the problem. This is where experimentation comes in, where we will be focused on building to learn.
- If the problem is “easy to fix” (for example, an expected button is not displaying on the screen), then jump over to solution implementation with success metrics measuring whether the fix has an impact.
For this particular section, we are going to be focusing on experimentation assuming we are dealing with large uncertainty around the problem. During this phase, we need to answer the question of “how do we generate the types of ideas that will truly help us solve the difficult problem we are seeing right now AND will help us improve the North Star metric we are trying to drive?”
With the specific problem that we are trying to solve now, let’s assume that what we have uncovered is that many customers don’t know how to even locate the specific product that we are trying to drive after onboarding. With that, it’s time to run an experiment on whether helping customers have a clearer, more direct onboarding flow towards the specific product will result in an increase in the percentage of customers that have engaged with the product that has the high activation metric within their first month of the service.
From there, we can set our success metric for the specific experiment based on the subset of impacted users. This can be through:
- Using Lean Startup methods such as concierge experiments (performing the service manually) and wizard of oz (prototyping with an un-automated backend).
- Discovery prototyping methods such as concept testing. This can be done as generative or evaluative. If it is generative (gain more awareness about what a customer desires in a solution), it is asking questions that put a customer when they are experiencing the problem and are asking them questions on whether it would solve the problem or not. If it is evaluative (test a hypothesis), it is asking through asking for a commitment from the user and see if they are interested — in the form of landing pages if it’s a net-new product or some other investment.
Solution exploration is a cost-effective way (time and effort) to learn something by exposing issues that we didn’t think of and tackling the usability and feasibility risk. This will help us understand whether customers can figure out how to use the solution and whether it is feasible for our engineering teams to build it (as well as uncover the possible technology, skill, and timeframe limitations). Assuming the experiment was a success — and by success, it is dependent on the increased rate of customers that have engaged with the intended product within their first month of the service — we will now need to work with the engineering team to address problems that are related to building the solution. This could be tested in the form of a spike (time-boxed investigation) or writing a small percentage of code to understand the scope of the work.
4. Solution optimization
This is an interesting one, especially when it comes to product teams that are solely focused on growth. The aim of growth-focused product teams is to run lots of tests and experiments, then hand those off to other teams that can make it a more sustained investment.
- What is the current state? Talk about it in terms of comparing it against success metrics and North Star one.
- What did we want to learn?
- What were the next steps in terms of how we can learn?
- What do we expect from those next steps?
In a truly product-led structured organization, there would be product teams and then growth product teams. Assuming that understanding the direction, problem exploration, and solution exploration are all roles and responsibilities of the product growth team and that the identified solution would be then handed off over to other product pods, the question is, how does solution optimization fit within a product growth team?
Upon proving value, now it is time to communicate and get buy-in. When speaking to stakeholders and other product pods, it is important to include the following inputs:
- Risks involved and how the team has eliminated or mitigated those risks
- Estimated time to build (t-shirt sizing in collaboration with engineering team) — ideally it would be a small effort high impact feature
After receiving feedback and buy-in, it is about mapping out the proposed solution through story mapping to ensure that everyone is in alignment to prioritize the first release.
During the story mapping session, the fundamental steps are arranged in chronological order based on when a user would perform the particular task relative to their overall workflow with the product. After listing it all out, we can then prioritize the work and cut out a few less-critical components in the first version.
It is crucial that the success criteria have already been defined, and after launch, it’s about continuous measurement and iteration until the success criteria are reached. Expectations should be set that the first version is more of a hypothesis than a set-in-stone feature, so if it does not end up hitting the goal, we need to be comfortable with rolling it back.
Through utilizing the Product Kata above as a guiding post for the end-to-end (or loop) process in building out a PLG feature, it will help us build with more intent. It will help us “set the direction with [our] success criteria, understand what problems are standing in the way of [us] reaching it, and systematically tackle them through experimentation”.
To build a product that is truly for the end-user, it is important to always be solving for the customer’s pain points. These customers are usually looking to automate or simplify an annoying task. “Building a product for end-users is about aligning to their pain.” And to solve an actual problem, it is about focusing on outcomes and not outputs and asking better whys.
