Practical guide to defining a product strategy

Michael Dubinsky
10 min readDec 9, 2021

--

Setting and executing on a clear product strategy is critical whether you’re a product leader, individual contributor owning a whole product or an area of an existing product.

In this post I’ll walk you through my thought process when building a product strategy.

I will start with the assumption that you know your product — who is it for, what problem it solves (e.g. what’s the value proposition), etc’. If you don’t - then your strategy should be to figure it out before anything else!

Once you have your mission and vision statement clearly identified you can engage in defining a clear strategy to execute towards that vision.

“If you don’t know where you are going it doesn’t matter which road you take.” Lewis Carroll, Alice in Wonderland

Your goal as a product manager is to ensure your customers are able to successfully evaluate, onboard, operate and get value from your product.

Ensuring customer value is an ongoing process which you should continuously execute and use to refine and prioritize your product’s capabilities.

My personal view that as a PM you should look at the entire product value chain and work with the other teams (product marketing, sales, support, etc) to drive their engagement towards the problem areas you’ve identified in order to deliver the best customer experience.

Your strategy would be centered around these core pillars, however it is critical to understand how to define clear objectives for each of these pillars and use key metrics specific to your product, value proposition and customers to evaluate whether you’re meeting these objectives.

The one metric to measure your product

I’m a big believer in the ‘one metric’ approach — where you define the one key metric which will provide you the best correlation between your product’s value proposition (based on the pricing model) and whether it’s being successfully delivered to your customers (more details on this approach available here).

Define the goal for the metric based on your organizational objectives. Work with the executive team to translate business goals into product goals. For example — if your goal is to reach $5M in ARR and your business model user/month with an average sales price of $10/user/month then you have to license ~42,000 users throughout the year.

Since you want to make sure these users get the value of your product (to avoid churn. Customers who buy and don’t use — churn!) your product goal could be set around reaching 80% active users (out of licensed users) — e.g. — you need to reach ~33K Monthly Active Users (MAU) on your product.

Your goal is to identify and continuously drive improvement in the riskiest areas in your product which have the highest chance of preventing you from reaching your target goal!

Let’s use 2 examples which deliver specific product’s value proposition and their ‘one metrics’:

Example #1 — Slack — a product aimed at improving user’s productivity Priced per active user (the more users you help be more productive the more valuable the product is).

The ‘one metric’ for Slack would be Monthly Active Users to measure the overall product’s adoption.

Example #2 — Datadog —a product used proactively identify and resolve issues in production environments — Priced based of the # of hosts monitored (the more containers are monitored the more data and insights you get).

The one metric for Datadog would be ‘Monthly Active Hosts’.

Evaluate the ‘whole product experience’ through the lens of the key metric. How would you reach 33K active users?

To evaluate each of the areas, you should define ‘sub-metrics’ to help you objectively evaluate whether you’re on the right track. Your goal is to understand (as objectively as possible) where are the biggest blockers to your product reaching its target objective and prioritize solving those blockers via your strategic initiatives.

The ‘evaluate’ phase

Are you getting enough prospects to hit your goals?

Let’s assume you’re using PoCs/Free trials to convert prospects to paying customers. First you should evaluate whether there’s enough sales → PoC conversion. This is not a product metric per se, but it directly impacts the product success. You want to hold your marketing and sales teams accountable for getting enough customers into the sales and PoC pipelines to successfully hit your target milestones. This is also a good (initial) indication for “pitch market fit”.

There are multiple ‘industry metrics’ around what a good conversion rate looks like. I recommend using these as a ‘high-level’ sanity check, but focus on whether your current conversion rate can get you to the target objective set by your CEO/GM.

If you can’t — you can/should work with your product marketing, marketing and sales teams on the solution’s ‘pitch-market fit’ (or even the product market fit). Don’t leave this to chance (or quantitative feedback only) — collect qualitative feedback — join sales calls, do product demos, understand your prospects problems, challenges, etc. One example of a clear product initiative which can be defined to assist with the pitch → PoC conversion problem is delivering better product demo scenarios.

Are you converting enough trials?

The goal of your prospect during the trial (or proof-of-concept) is to evaluate whether the product delivers on the value ‘promised’ during the initial presentation/campaign.

Start with the metric to help identify whether there’s a problem during this phase.

What % of trials are converted to paying customers?

If you identify this as an improvement area you should define quantitative measures to assist with trial evaluation such as: demo to trial registration, initial onboarding time, time to first user/host, etc’.

You should also measure the engagement during the trial and the specific journeys you want the customer to complete.

Let’s use Datadog for this example — You can measure the ‘time to first host’, or ‘time to first log’ to represent how long it takes to get data into the platform. Then you can use specific engagement targets to make sure customers test and realize the value of the platform, for example — ‘data queries/week’, ‘# of alerts configured’ and ‘# of alerts resolved’. These metrics would measure whether your prospects are successfully testing the key value proposition of the product — identifying, investigating and resolving production incidents.

It’s also important to engage your prospects during the trial to collect qualitative feedback and understand what do they need to ‘prove’ during the trial.

Once you’ve converted the prospect to a paying customer — you need to make sure they can successfully onboard.

The ‘onboard’ phase

This is one of the key areas to drive your ‘active usage’ metric up.

Even with an extremely successful trials, onboarding the real ‘production’ use-cases is often more complex and requires additional integrations with the different organizational tools (authentication, deploying end-user applications/agents, integrating API calls/SDKs, etc’).

Are you successfully onboarding new customers?

Identify your onboarding metric to help evaluate whether you have a problem in this step.

Assuming you’re selling licenses (vs. using ‘pay-as-you-go’) you could measure the % of active licenses (MAU) out of sold licenses. In a ‘pay-as-you-go’ model you could evaluate the active usage growth month-over-month, but it won’t necessarily be a direct result of onboarding challenges (perhaps there’s a soft limit due to the customers’ use-case, pricing model, etc’).

Spend time investigating the onboarding process to understand it’s flow/steps. How long does it take? What’s the customers feedback? What are the most complicated/longest steps in the onboarding process? Are there additional teams (personas) involved in the onboarding, and if so — what are their needs?

  1. In some cases, successful onboarding means changing the people’s behavior — using Slack instead of email is something which people need to learn, so even though you may have successfully PoCed, deployed and integrated Slack into your company’s environment — users may not start using it until there’s a driver for them to do it. (Someone sending them a message, a new relevant channel opened by a team-member, etc’).
  2. In other cases there could be a ‘deployment blocker’ for a customer preventing them from using your tool. Hopefully these are identified during the PoC process and you could engage with the customer on resolving these blockers. However there are multiple cases (I encountered personally) a customer has hit a blocker during the actual deployment phase. One such requirement I’ve often seen in enterprise organizations is the requirement to integrate with the corporate identity provider to authenticate and authorize users. This is a critical requirement for all enterprise customers, which involves additional teams on the customers’ side and additional requirements for the product.

Clearly knowing and prioritizing your product’s deployment blockers is critical in enabling your customers to successfully get the value of your product.

The next step is to look into the value realized by the customers successfully onboarded.

The ultimate goal is to avoid churn and increasing your product value/adoption/stickiness, eventually driving towards greater customer satisfaction.

The ‘value’ phase

Once your customers successfully onboarded, it’s now the time to realize the value proposed by the product. Whether it’s an increase in productivity, or reduced time to resolution of incidents — if it’s not realized by your customers — it means your product doesn’t live to it’s promise, which in turn would result in customer dissatisfaction and churn.

You should identify which metric correlates best to the value realized by your customers, based on your product’s premise.

Based on Slack’s key metrics (which are discussed in this great post) we can assume their key ‘value’ metric is centered around the time each user spends in the platform and the # of messages sent. These make perfect sense — the more you read (time spent in Slack) or create reading material for others (messages sent) the bigger the value of Slack to you and your organization.

For the monitoring solution, I wasn’t able to find concrete key metric examples from the likes of DataDog are NewRelic, however trying to think through their product I assume a ‘value’ metric could be # of alerts resolved and the time spent in the product investigating (querying) data. This would provide insights whether after integrating the VMs/containers into the monitoring solution (active sources) the engineering teams are actually using the solution to alert, investigate and resolve issues.

Are the customers happy with your product?

Perhaps they’re actively using it, but there’s frustration with the ongoing maintenance? Maybe their use case is not solved completely and the customer is using work-arounds to solve the use-case end to end, causing frustration and questioning the value of your product? An NPS score or customer surveys could be used to evaluate this at a high-level, however — customer interviews are your source of qualitative data to better understand the issues.

Is your product integrated into the organizational workflows?

An additional way to reduce churn is to evaluate how ‘sticky’ your product is (E.g. — how easy it would be for the customer to switch to a competitor product?).

Integrating into organizational workflows and processes will help your customers get the value from your product, as well as making it harder to switch from your product to the competitor.

Think about the monitoring example — if the solution is integrated into your SRE/DevOps LiveSite processes (e.g. — integrating with alerting systems, Slack channels, building and executing remediation playbooks) then it would streamline the value your product delivers directly where it matters the most which in return will drive the stickiness of your product.

Putting your product strategy together

Based on the targets and the metrics you defined you should already be able to set a clear high-level strategy. I like using the ‘pillars’ approach to clearly articulate the focus areas of your product. For example:

  1. Reach 33K MAU by end of year. This will encompass the pitch, PoC/PoV and onboarding flows. You could then define ‘sub-metrics’ to evaluate the PoC success, conversion and onboarding.
  2. Deliver on key customer value — this is the ongoing value your customers get from your product — for example “Reach > 200K daily message on the platform”, or for the monitoring example it could be “>50% of critical alerts actioned on within 2 hours”.
  3. Drive integration to organizational processes — “> 30% of customers have 2 or more 3rd party tools integrated into your product
  4. Deliver friction-less maintenance — “Reduce # of support calls by 50%” or “Ensure 70% of endpoints are using the latest client version within 30 days of release.” as 2 examples.

Once you’ve identified the problem areas, your objectives and the key metrics, you can use them to evaluate, define (and prioritize) the different product initiatives you want to drive. More on that — next time!

It’s also important to evangelize and clearly communicate the strategy (and the logic behind it) to the entire team — PMs, UX, product marketing, engineering and executives to align everyone behind the goals.

Summary

My approach to defining a product strategy is based on evaluating the different phases of your customers’ journey with your product and addressing the ones with the biggest risk to your product/organization goals. The metrics are there to help you identify where the risk is, it’s you and your teams job then to understand why it’s happening and how to solve it.

A product strategy is not a ‘one-time thing’. My recommendation is to evaluate your product strategy every 6–12 months in order to identify how you executed on your initiatives and evaluate whether the key metrics you’ve focused on for the last 6–12 months are still the right metrics to drive going forward. This is often enough to adjust as needed, while still not being ‘too often’ which could drive your team crazy with constantly changing strategy and objectives.

In my next post I will cover the execution process and how you can define and prioritize the different initiatives and align your daily product execution to the strategy you’ve defined.

“Without strategy, execution is aimless. Without execution, strategy is useless.” -Morris Chang

Hope you enjoyed reading, feel free to leave comments and reach out at @michaeldubinsky on Twitter or LinkedIn for any feedback or questions.

Michael.

--

--

Michael Dubinsky

Currently Head of Product Management for Symantec, previously VP Product * 2 for successful (acquired) startups. Into music, physics and scuba diving.