Users, buyers, not picking favourites & noodling on North Star Metrics

In B2B product management, the topic of users vs buyers often comes up. Who do you do discovery with? Who do you have to keep happy? Who do you optimise for?

The answer is, of course, both. You need to keep buyers onside otherwise you won’t make any new sales. But you need to keep the users onside otherwise you may not get that year 2 renewal.

Another interesting dynamic can be what I call the “two drunks fighting” dynamic. If you’ve ever been out after the pubs kick out you’ll likely have seen 2 friends having a drunken tussle over something. Maybe you step in to try to defuse the situation, only to find that both of the friends are now fighting you. The moral of this story? No matter how much people seem to be at odds with each other, don’t pick favourites!

Since I’ve been delayed in getting this issue out, I’ve actually got two episodes to tell you about.

First off, I spoke with Princess Akari, product manager at Brass, a Nigerian fintech. We spoke about PeopleInProduct, the community she founded to help support local product managers and give them somewhere to vent but also share successes, advice & tips. She also spoke about the struggles to prove the value of product management in Nigeria, and some of the barriers she’s faced. Give it a listen here.

Second up, I spoke with Matt Arbesfeld, founder of LogRocket. We talked about data-driven product decisions, pivoting your company when you find a new market & finding product/market fit for the second time. We also talk about his time with the Thiel Fellowship and whether it’s a positive or negative force in this day and age when we’re rightly worried about stepping outside of the same old institutions when hiring people. Check the episode out here.

This weekend, I have a great episode coming out with Holly Schroeder, talking about the importance of accessible design. Coming soon!

If you’re interested in the craft of podcasting and how it might help you as a product manager, I appeared (literally, it’s on YouTube!) on the Product for Product podcast. I spoke about a variety of podcasting topics with Tracy Laranjo of Experiment Nation and Aram Melkoumov of Product Innovation Series, as well as hosts Moshe Mikanovsky & Matt Green.

Ah, North Star Metrics. An important concept that you’ll see a lot written about in product management circles. There are lots of well-written definitions but here’s Mixpanel’s, not least because it’s the first one that came up on Google. To paraphrase, it’s an overall metric you can align the company around to prove that your decisions are helping the company achieve its goals.

There’s a joy in the simplicity of this concept, and in many cases it might seem simple. That’s not to diminish the effort it takes to choose a good North Star Metric and steer clear of vanity metrics of course. But it feels like many of the North Star Metric examples you see out there are… kind of simpler than others.

I posted a question to Twitter to see what people would do in a more complicated situation than some of the B2C examples you normally see out there. There were some fantastic responses, many of which were thought-provoking and some of which I disagreed with. I posted a follow up with some thoughts of my own. There’s also an entertaining, if slightly punchy, write up by Ibrahim Bashir of Amplitude.

To summarise my position, I don’t believe that performance related metrics are good North Star Metrics for API / platform type products. Whilst it’s fair to say that only an Evil Product Manager™ would deliberately game metrics, you want to avoid unintended effects. There are plenty of dark patterns out there that we might reasonably blame bad metric goals for (e.g. if your priority is to make a number go up, you may employ subterfuge to make it… go up). This is worse still if (god forbid) your North Star Metric is tied to compensation or bonus somehow.

There’s a simple example of this for API products. It’s pretty common for API products to mirror the structure of the database that sits behind them, and this can lead to relatively simple requests being split across numerous endpoints. This is bad UX, but if you’re judging yourself on the number of API calls you won’t want to streamline that experience. If you’re benchmarking yourself on “number go up” then you have no motivation to improve the API UX. If you’re an Evil Product Manager™ then you might even consider splitting perfectly good endpoints up to make your numbers go up.

That’s perhaps a dumb example but I can’t say it’s never happened anywhere! And it speaks to a greater truth… any metric can be abused, we just need to (a) be thoughtful about our metrics (b) change tack if we realise they’re driving bad behaviours.

Leaving aside discussions about whether one North Star Metric is a good idea (it probably isn’t), there’s probably not one answer to the API metric conundrum. For me, I always like to try to boil it down to the Fundamental Unit of Value. I’ve almost certainly stolen that phrase from somewhere, but the basic idea is to try to work out what a successful “transaction” looks like.

This could be an actual transaction, or it could be a lookup of some type of entity that you hold, or some other unit of value that can be delivered to a user. Remember, in many cases your user may not be at all visible to you; we’re talking about a platform product after all. You’re providing value to another platform which is providing it to the user, and you may never see what happens or whether the transaction completes from their end. So you need to think about proxy metrics, and find something good enough.

As usual, the most important thing isn’t to find a perfect anything, but to do your best, keep an eye on it and change it if it’s not working for you. Agile AF!

I’m definitely going to try to keep to one newsletter a week, but life is pretty hectic right now. I’ll be a good boy, I promise!

In the meantime, please share this if you think it’ll be helpful to anyone, and I’m always happy to get feedback via email or Twitter if there’s anything you’d like me to cover or you’d like to shout at me 🙂