Product Strategy: Defining & Tracking the Right Metrics.

This essay shares my perspective on product strategy. I allude to takeaways from a product management workshop I attended hosted by Amplitude (a product analytics company), along with some learnings from Guy Kawasaki’s The Start of the Start.

The objective of this post is to help you set the right metrics that align with your product strategy, to effectively track those metrics, and ultimately build the right product.

Summary

There are four parts to this essay.

1. Company Mantra
2. Company Objectives vs. Product Strategy
3. Product Strategy Metrics
4. Features-Product Strategy Alignment

1. Company Mantra

Product strategy needs to align with the company’s mission. But first, the company mission needs to be idiot proof. Specifically, it needs to be easily explainable and memorable, or “company mantra” as Kawasaki refers.

ThinkHR was recently acquired by a private equity firm. Pre-acquisition, the company’s mantra was to provide HR knowledge solutions. The mantra was succinct but not memorable; our products struggled to fit into the bigger picture.

• Example 1: We provide an employee handbook builder. Employees can be more knowledgeable by reading their company’s handbook. So what?
• Example 2: We provide training courses such as sexual harassment prevention, fire safety, handling hazardous materials. Employees can be more knowledgeable about these topics after taking these courses. So what?
• Example 3: We provide a content library ranging from how to terminate employees, handling maternity leave, to handling discrimination cases. A company’s HR personnel will learn how to handle these types of situations. So what?

After the acquisition, the company repositioned its mission: to help businesses manage people risks. Our products enabled businesses to (i) be informed about ongoing changes in laws, (ii) take actions to become compliant with the law, and (iii) respond appropriately in events that they’re already in trouble. It became much easier to explain our product offerings under this new mission.

• Example 1: We provide an employee handbook builder that enables companies to establish their code of conduct, policies, and culture. Employees must sign the handbook. Given the event that the employee breaks the law, the company could demonstrate that the employee knowingly violated the handbook. Thus, the company is not at risk for that employee’s actions.
• Example 2: We provide training courses such as sexual harassment prevention. Given a scenario where the employee still commits sexual harassment, the company could demonstrate that the employee had completed the harassment prevention course, and are thus are not at risk for the employee’s actions.
• Example 3: We provide a content library that includes how to handle maternity leave. The company’s HR director can follow step-by-step best practices to follow their state and federal laws, so that they will not unknowingly violate leave of absence laws. Thus, the company has reduced their risk of being out of compliance, which may have resulted in the employee filing a lawsuit.

2. Company Objectives vs. Product Strategy

With a clear mantra, defining a product strategy becomes much easier.

At my previous software as a service (SaaS) companies, the only metrics I cared about were annual recurring revenue (ARR), churn rate, customer acquisition cost (CAC), and customer lifetime value (CLTV). The success of the products and features I built were judged on those criteria, and thus they were the only metrics I looked at regularly.

The aforementioned metrics are critical to the business, and I interpret them as more indicative of a company’s objectives & key results (OKRs). But when it comes to day-to-day product management, however, I struggled to evaluate the whether my products/features would successfully meet OKRs. They are simply too high level and not immediately recognizable, e.g. to achieve X dollars in ARR by end of year, reduce annual churn to X% by end of year, and reduce CAC to X dollars in 6 months. I’ve managed products that failed to meet OKRs, and they were only realized after months/quarters of R&D efforts. We had succumbed to the next feature fallacy.

This is where product strategy serves as the intermediary between OKRs and building the product. Defining a product strategy and measuring it correctly will help you quickly realize whether your products/features will meet the OKRs. If not, course correct. If yes, continue onward.

Based on Amplitude’s findings from 12,000 companies, software products typically fall under three models. They are trying to win one of the following:

1. Attention: to maximize the amount of time users spend in the product.
2. Transactions: to maximize the number of times users make purchases within the product.
3. Productivity: to maximize users’ efficiency in completing tasks or workflows.

I initially struggled to only focus on one model. I thought, “Shouldn’t good companies be effective in all three models? Aren’t transactions necessary in every business because it means revenue?”

The reality is that these models all bring different types of customer value add. People will spend money on things that bring value. Stick with one product strategy.

3. Product Strategy Metrics

A few months ago, I launched a minimal viable product (MVP) at ThinkHR. All page visits and clicks in the MVP is tracked and logged in Google Analytics. I’ve been reviewing these events to help me determine how to take the MVP to the next level.

By looking at the events over a week-to-week period, I connected the dots to understand the user’s journey, i.e. how exactly are they using the product during their session.

My MVP plays the productivity game. The product delivers value by having users complete a checklist of actions to reduce their company’s risk of being out of compliance / getting sued. Therefore, I want to be able to measure or understand the following:

• How many tasks/checklists have been completed by customers each month?
• What’s the average number of tasks completed per customer over a month?
• Which tasks in the checklist were performed less than others over a month?

The results have been fascinating. The MVP comprised of two checklists, each with five different tasks. On both checklists, the first three tasks had far more completions than the final two, even though the first three tasks are more time intensive. The amount of unique usage has also remained flat over the past two months. I half expected the usage to drop over time as more users complete the checklists.

4. Feature-Product Strategy Alignment

I’m not sure why the first three tasks are being completed far more than the final two. And I don’t want to guess. My next step is to reach out and interview some of these users to understand why they only completed part of the checklist. I am trying to prove one of two assumptions:

1. From the user’s perspective, completing the first three tasks sufficiently reduces the company’s risk.
2. The user is fatigued from working on the tasks and has simply chose not to finish the checklist.

Let’s play out both scenarios. Suppose I prove that there is a perception that completing 3/5 tasks will adequately reduce the company’s risk. ThinkHR would conclude that this company is still at risk. Thus, the next features I would build would signal to the user that their risk level is still moderate/high. The goal of the features would be to incentivize the user to finish the final two tasks on the checklist.

Suppose I prove that the user simply didn’t finish the checklist due to not growing exhausted from using the platform / did not have enough time. They have an understanding that they’re still at risk. If this is the case, the features I would focus on would be to remind/notify the user to return to the platform to finish the checklist.

Once again, based on playing the productivity game, my product delivers value to users based on the number of checklists completed. Therefore, the above features aim to encourage users through different means to do just that. Features that otherwise go against the product strategy would only be an additional barrier that users have to overcome to access the product’s value proposition.