How would you change a product team/organization to be more KPI driven?
What a terrific question! This is one takes time and depending upon your organization will require patience.
The best way I have learned, is to ask "why" a particular feature is being prioritized, and the "impact" it is bringing to the customer. The best way to create change is to start with your own product team (even if that consists of you as the PM, engineering, and UX/UI). For every epic/story, make sure to note down the KPI that it will impact, and why that is important to your target (end) customer.
After a few cycles (e.g. sprints if you follow the agile approach), share the results of how your product work (launched features) impacted the KPI you were measuring, and why that is critical to your overall business.
Evangelize this within your org, and see if there are one or two other teams who are interested in following suite.
The more you share and report broadly, the easier it is to create change internally.
To make a product team/organization more KPI driven, it is always best to start at the top. The Head of Product at your organization should provide the broader PM organization with the strategic context of what business objectives are essential for your team to hit.
From there the PM team can take that business objective and break it down into their own objective and key result.
If you are a product leader seeking to make your organization more KPI driven, what I would do is identify what metrics matter to your business and put those into individual PMs goals. For instance, let's say it's critical for organization to ship Product Y at the end of Q2. PMs Bob and Anna are responsible for Product Y. Then I would make it part of Bob and Anna's individual performance goals that they deliver Product Y by the end of Q2. Of course, there are going to be many reasons why Bob and Anna may not be able to deliver Product Y (the big one being engineering or design). And while these reasons may be true by clearly stating in their performance goals that they are accountable for that deliver this ties Bob and Anna to ensuring that outcome occurs and that they keep you posted on what needs to be done to reach that outcome.
If you are an individual contributor seeking to make your organization more KPI driven, I would start with your own product. Ensure that you are aware of the key metrics your organization values (e.g. Annual Recurring Revenue, Daily Active Users, etc.) and determine what key results your product needs to hit to help your team reach that outcome. I'd then focus on sharing your KPIs with your manager and peers in engineering, user experience, and product marketing for alignment. With KPIs aligned, I'd regularly update others on your metrics and show progress. Others will notice and likely start requesting that your peers follow.
Becoming more KPI driven is a matter of desire and taste. No person, team, or organization attempts to change without believing that behaving differently will result in an improved outcome they care about. It's only possible when leaders buy into how it would improve the success of their teams and business (e.g. profitability, valuation growth, employee engagement, talent retention, positive social impact, etc.) Some companies are steadfast that the use of KPIs should not equate to being data driven everywhere in the company. They prefer to have data informed teams that reserve room for intuition and qualitative insights. There is no right answer here.
If we find ourselves with a company that's bought into a shift towards being KPI driven, but is trying to figure out how at the team, group, or division levels, then I'd recommend the following:
- Have the leaders of the team/group/division define their strategy for a period of time through written outcomes, assumptions, and principles that are most critical to their success.
- Gather all the data already available and audit it for quality and trustworthiness, then see if you can model your product or business (i.e. in a spreadsheet) to see if the assumptions you've made and outcomes you've articulated can be explained by your data. If not, note what's missing and how you could gather it (and be comprehensive at this stage).
- Work with your engineering and/or data team to instrument the metrics you need, backfilling where possible. Remember that you'll need continuous energy to ensure your data remains audited and accurate, as data corruption can severely disrupt your KPI-driven organization.
- Develop a process for regularly collecting, analyzing, and reporting on the chosen KPIs. Without this ritual, your efforts will be for not. Being KPI-driven means knowing and using the data to make decisions. In my experience, to get the flywheel spinning, you need to have weekly rituals that can morph to monthly rituals. These can be augmented with quarterly business reviews.
- Make sure that the chosen KPIs are easily accessible and understandable to all members of the teams. This may involve creating dashboards or other visualizations to help team members quickly see how the product or organization is performing. Repeat your KPIs at kick-offs, all-hands, town halls, business reviews, and anywhere else you gather. It's only when you think you're over communicating them that you've probably approached a baseline level of understanding of the KPIs, and how they inform decision making, across your company.
- Provide regular training and support to team members to help them understand the importance of the chosen KPIs and how to use them effectively to improve the org. If you have a wiki, put your tutorials there. Make it mandatory to consume these during onboarding. Offer self-serve tooling. The more people can be involved with the data, the more you'll make this cultural shift.
- Regularly review and adjust the chosen KPIs to ensure that they are still relevant and useful. Account for any changes in your outcomes, assumptions, and principles. Assess suitability annually. Set targets annually and adjust mid-year. Some companies do this more often, and your culture should dictate what's best.
- Lastly, make sure that all KPIs have their lower level metrics clearly mapped for the company to see. Teams influence these input metrics more quickly, and the mapping brings clarity to decision making.
This change can be driven by focusing on fostering a data-forward culture. Start by ensuring all your product teams have clarity of vision and outcome goals.
This leads to product backlog features having clear, measurable and time bound goals
During roadmap planning, use these backlog goals as input for prioritization
Lead your team to embrace outcome-focused product launches. Change ‘Done’ definition from ‘development complete’ to ‘when customer and/or business goals are met’
Another important ingredient is creating a healthy atmosphere for ownership. Embrace a fail fast and learn faster approach and give your teams the ownership, accountability and support to be KPI-driven.
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.
This can sometimes seem like an impossible task - but there are some core change management principles we use at BILL that you can use to help people get excited about the idea of making the move.
Step 1: Prep the organization for the change
You have to get people to move from their current beliefs and behaviors to the desired beliefs and behaviors. You can do this in a few steps (1) Understand what their fears and concerns with the change, (2) Share a clear vision and strategy to address concerns and feedback, (3) Get buy-in to try it, (4) Set clear goals and share how success will be measured, (5) Share a detailed plan for how the change will work.
Step 2: Implement the change
This is usually the hardest step for moving to be more KPI driven - since it usually requires investment from teams to get their products instrumented. This can sometimes feel to teams like they have wasted product development cycles building in a bunch of metric measuring, but understanding current baselines is the first step to getting more data driven. This is also the most challenging part - since many teams assume measuring alone = KPI driven. You will likely need to provide training, templates, etc to help teams understand the KPIs are about using the KPIs as the data to inform the decision making process. If this is overwhelming to start - you can always start piloting with one team.
Step 3: Embed the Change
Once you implement the change and get people to start being more data driven - you need to make sure it sticks. You can do this by celebrating wins, highlighting it in team meetings, and consistently reenforcing the message.
Step 4: Review and Evaluate the Outcomes
Once you have some cycles under the team, to ensure that the change sticks, make sure to communicate widely the wins and the learnings from the change. This ensures that there is transparency in the change and people can see the positive effect of it on the company.
This is a challenge all organizations face as they scale. Most of my experience is in startups, and I know first-hand how hard it is to transition from instinct to data-driven decisions. It's not something you can just flip a switch on - it takes a very intentional mindset and at least one person to really champion.
It sounds like you already have the crucial first ingredient: the desire to be more data-driven. In my experience, there are a few critical steps to take to start to make this transition. They will take time and commitment from you and it's ok not to get each perfect initially:
Get leadership alignment on core business objectives. Without clear business objectives, KPIs are just noise. Get alignment on objectives like growth, retention, or revenue. If you can't get direct alignment, make educated guesses based on company context and strategy. As you move into defining KPIs, one trap to avoid is focusing on KPIs that are out of your team's control - there's no faster way to get the team to give up on KPIs.
Invest in good data infrastructure. You'll need the right tools to measure what matters: a product analytics platform, accessible database, and either a BI tool or well-structured spreadsheets to start. Without measurement capability, KPIs remain arbitrary numbers.
Develop team rituals around KPIs. Build regular touch-points/rituals: weekly metrics reviews, monthly deep-dives, and quarterly goal reviews. These may feel awkward initially - that's normal. Keep iterating until they become valuable.
Change decision making processes. Whether you're in leadership or not, incorporate data into feature proposals and planning. Set clear success metrics before new initiatives. Make data an expected part of the conversation.
Invest in your team's capabilities. Your team will have varying comfort levels with data. Lead by example, share resources, and celebrate data-driven wins. Conduct team trainings or provide access to learning resources. Build internal documentation to support the journey.
Remember, this is a gradual transformation. Focus on steady progress and celebrate the wins when data-driven decisions pay off (build positive reinforcement). Success comes from making metrics a natural part of your team's workflow, not a forced addition.
KPIs need to be relatable to the team and part of your product and company cadence. They also need to tie to the company goals. I like to utilize yearly and quarterly planning for the company as the start of the product team cadence and then spend time with the product team to ensure we measure what matters. For example, if you are trying to drive growth - map out new product launches and tie the KPIs to the launch. If you are trying to reduce costs, tie your KPIs to reduction of support tickets or other manual process around the company. It is important that the KPIs have context for your entire team so that they understand why they are important and how their work impacts the success. Teams cannot only focus on KPIs, they need to also have a vision, communication and most importantly maniacal focus on customers!
See question: “What are good OKRs for product management?” for a general introduction to the topic.
Being more data-driven is about the entire strategic planning methodology. It could feel natural to start with having execution KPI or KR, but those will only be good if you came up with those metrics in a scientific way.
See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs.
To change the organization, you need to look into change management literature. This is a vast topic that wouldn’t fit in this AMA, but here is a framework I used successfully many times: the DICE scoring from the Boston Consulting Group. This puts emphasis on several key necessary elements of successful transformation:
Implementation iterations and milestones (shorter = better)
Available skills to embrace the change (training)
Commitment of senior leadership (classic area of failure: politics)
Account for additional efforts (changing efforts requires reducing usual workload)
Top Product Management Mentors
