AMA: ActiveCampaign Senior Director of Product Management, Veronica Hudson on Product Management KPI's

This is not a single KPI, but often in the past, I've seen KPIs set that are not tied back in any way to broader business goals. For example, if a product manager on my team came to me and said, "My KPI for this product launch is 30% adoption in the first month." My first question would be, "How does that relate to our broader business goals of increasing net retention or driving trial conversions?" That KPI should only be measuring adoption if think it will directly impact one of those broader business goals and we have a way to measure it.

This has been a hot topic on my team recently. I think the default answer for many is that PMs own all of the metrics around a feature launch, including adoption. However, I believe that Product Marketing and Product need to be incredibly close partners on adoption KPIs, with each partner measuring the levers that they have control over to understand where they can drive the most impact. Once a feature is launched, the PM can listen to customer feedback and look at usage data to understand what is and isn't working and begin to incorporate some of those changes (albeit weighed against everything else in their backlog). PMM, however, does not need to get engineering involved to experiment and iterate with adoption. For example, maybe they are seeing better adoption rates with customers that click through their Pendo guide before trying the new feature. Can they perhaps begin to segment the overall customer base and make guides that are targeted by vertical or use case and retarget the customers that skipped it the first time? While team members from product and product marketing should collaborate closely on every phase of a launch KPIs from awareness through adoption, each team should lean into the strengths of where they can drive that adoption to really move the needle.

Create forcing functions that will encourage KPI creation and analysis throughout the product life cycle. Here are some ways I've had success in doing so: * I've found OKR exercises to be incredibly helpful in orienting teams around KPIs. As you set those Objectives, you have to also understand what your key results are, which often requires KPI measurement. Once the team has landed on those, it can become a topic of discussion throughout the product lifecycle...how is this helping us hit our key results? (This can also be a helpful prioritization tool, but that is a topic for another AMA.) * Ensure that in every product brief, PMs and PMMs are answering the question "How are we measuring the success of this product and product launch?" By answering the question early on, it forces the team to think critically not only about why they are building this feature, but how they will know if they are right. * Create a regular cadence of reporting on the health of your product line or area of ownership that welcomes debate on the what, why and how of what is being measured. * Bring team members across the org into KPI discussions on a regular basis. A CSM might have an incredible insight on what is being measured as it relates to customer satisfaction. An engineer might elevate a health metric that could be leading to churn. A support rep might identify a canary in the coal mine as it relates to defect trends. This type of discussion gets the entire org invested in KPIs and keeps them top of mind.

Bringing engineering into KPI discussions is a must for any Product Org, especially when we are considering key B2B business metrics like churn and retention. I think product managers can often get caught in the trap of only considering which new features are going to drive the business forward and excite new customers, but no business will survive on new customers alone. How are you keeping your current customers happy and satisfied with the product? This is where some important engineering-driven KPIs come in: 1. Uptime: Understanding uptime and the reliability of your product are a key component to determining if your customers will be satisfied with your product. If you experience frequent outages or incidents, customers will run out of patience and start to look for other solutions. 2. Load times: How responsive are our pages and how quickly do they load? This is especially relevant in a B2B context where customers are potentially wasting money or losing deals with every extra second they have to wait to perform a task in your platform. 3. Reliability: While this may sound similar to uptime, reliability needs to be measured in the context of the feature you own with engineering. For example, with an ESP, what % of time do my email sends complete within our SLA? 4. Defects or Support Escalations: We strive to keep our total number of defects below a certain threshold. Our hypothesis being that fewer defects indicates a more reliable product and likely, more satisfied customers that feel heard when they take the time to let us know something is wrong with the product.

Maybe this is controversial, but I believe KPIs should be hypothesis-oriented with an eye towards learning what is and is not working to move the needle on an overarching business objective rather that just a random number we think might mean...something? Let me give an example here. Say we are launching an update that we believe will increase adoption of a feature most closely understood to drive retention (ie customers that adopt this tool tend to stay with us longer and spend more money). I would not want to make my KPI 80% of customers use the new update. Why? Because I have no idea if that number is attainable. That number also does not indicate if we are moving the needle on adoption of the feature this update is meant to serve. Rather, I would make my KPI hypothesis driven and track the launch of the update against adoption of the existing the feature. If we see adoption increasing, we proved our hypothesis correct. It doesn't necessarily matter early on by how much adoption is increasing, just that our hypothesis seems to be on the right track. From there we have lots of options: * We can look to iterate on the update based on customer feedback * We can call more attention to it via in-app messaging * We can better incorporate it into the onboarding flow * We can work with PMM to call more attention to it in our docs and marketing announcements Being hypothesis-oriented in KPI measurement ensures you are constantly learning from your product launches vs setting a number, achieving it and then moving on to the next thing.

Every KPI exercise should start by asking, "What are the direct business outcomes we hope to move the needle on with this intiative?" So often I see KPIs focused on something like pure adoption metrics. Ok great, we want people to adopt this feature but WHY do we want them to adopt it? * Do we think it will help reduce churn? * Do we think it will drive conversion? * Do we see a correlation between customers that adopt this feature and stay past the 30 day mark? * Is this feature a key part of our Aha moment? I find that a good measure of if a KPI is more than just a proxy is if it cuts across at least two areas of measurement. For example, looking not only at the customers that adopted that feature, but also their overall net retention. The more data you can can layer on to a KPI to help understand the business outcome it's driving, the stronger measurement it will be.