The worst KPIs to commit to are the ones you can’t commit to at all. We can set targets and metrics and make dashboards, but that’s exactly what they are - targets. I recommend looking at past performance and trends within the data and setting a realistic yet aspirational target to work towards. After that, begin iterating on your target. Revisit the KPI, analyze, adjust, and communicate your findings.
In the past I've worked on new library launches, major upgrades, and I'm actually in the process of an end of life (EOL) effort right now. While these types of efforts have their own nuances, the core principles remain the same.
The framework I use for setting KPIs for a new product or area typically looks something like this:
I’ve worked with developer focused tooling for almost 7 years so I know exactly what you mean here. On almost every new feature or product our teams put into motion, we have a huge list of factors to consider such as security, legal, or billing. For developer tooling, there’s usually no change to pricing or billing, no new SKU. Does that mean these types of products don't provide value? No way! Libraries, SDKs, APIs, CLIs, and other developer focused tools are a huge part of the overall product. They can open your product up in a way to create value you never imagined.
When it comes to making a business case for investing in a product feature or measuring value created by these efforts, I look at other ways the business will be impacted. Will this feature help reduce friction in the sales cycle, or is this library a market differentiator amongst similar products? Will change this improve customer sentiment if we roll it out? Will it help accelerate time to value for our customers? Will it help our customers operationalize including our product in their stack and ultimately make our product more sticky within an organization? You can put KPIs, metrics, and even dollar values around so many of these items.
Developer Audience - now we are talking! As someone who worked as an engineer using SDKs, then building SDKs, and then moved into Product Management, I have a lot of opinions on this! We can definitely think about a ‘developer persona’ the way we all have different personas for our respective products, but all developers are definitely not the same. Building for different development platforms can add another layer of differentiation and complexity as well.
I have a secret though, when you work on developer tools, you already have an amazing pilot group - the engineering team building the product! The teams I work with come to customer meetings, drive discussions with our users, write documents, and pitch new ideas. They are your biggest untapped resource if you’re working on developer focused tooling. If I'm struggling with a decision or just need a pulse check on something, the team is the perfect group of people to ask! As I mentioned before, I'm always tagging Engineering, PMM, and other team members early and often in documents or analysis as soon as I start on something new.
My second biggest recommendation for working for a developer audience is to to think about all of the tangential items related to the actual product; documentation, examples, interactive apps, or code comments. In my experience, developers love an easy to use library, and they also value transparency and good documentation.
The other thing I cannot reiterate enough for developer tooling is the change management aspect. When developers depend on your libraries or APIs, making a change has to be thoughtful. Whether it is promoting a library from Beta to GA, or versioning your library, you have to maintain transparency as well as versioning expectations. Breaking someone else's usage of your tools is no fun at all. This is especially important as you deprecate or end of life a tool, the notice you need to give a developer is much different than making a change to a view in a UI.
Congratulations! I’ll answer your question with a few questions of my own.
I’d recommend starting with 2-3 target KPIs that tie directly to your purpose. From there, make the targets visible through dashboards or reports and constantly revisit them. Ask your colleagues for feedback, and never be afraid to make adjustments!
Also, try to be aware of the impact these measurements are creating. Do you find yourself referring to these targets often, do they impact decision making? One of my colleagues likes to say the best way to know if a report is useful is to stop sending it and see what happens.
The partnership with Product Marketing is one of the most important functions when it comes to rolling out a successful product. Don’t read too much into the last part of that statement though, a Product Marketing Manager (PMM) is a crucial teammate to include from the start, not just at launch time. If I know who I will be working with in advance, I tag them in Product Requirements Documents or other important materials. Sharing context from the beginning is so important!
As far as the KPIs go, we are really talking about how you measure the success of a product, and Product Management and Product Marketing should be aligned on this. If you're the Product Manager, you’re ideally setting the big picture targets and KPIs for the initiative, and working with a cross functional team, such as PMM, Engineering, and Product Ops, to make sure these are shared targets. Part of the product rollout might include working with PMM on a webinar to drive awareness, and the PMM will likely have their own targets for things like webinar attendance, and all of these items build on each other. Ideally the webinar drives awareness, which in turn helps drives adoption.