Back at the end of 2021, I put out a Tweet offering mentorship to the product management community. I expected a handful of replies. I got 76.

This taught me two things:

I should set my Calendly settings better next time (I use SavvyCal now btw).
Product Managers really need mentorship.

No product manager should feel alone in their career

I enjoyed the mentoring, and have been doing it on a smaller scale since. But, I clearly can’t support the wonderful product management community purely through my own efforts. But, hey, I’m a product guy! So, I’m delighted to announce the launch of My Mentor Path, a FREE mentoring platform dedicated to getting you the support you need. Why not check it out or, better still, sign up as a mentor, a mentee, or both?

New podcast episode: Getting the GIST of Evidence-Guided Product Development

I recently had a sit-down with Itamar Gilad. Itamar’s a former Microsoft and Google PM turned product management coach and consultant. He’s a prolific writer of articles and ebooks and has been refining his GIST framework to help organisations step away from delivery-focused roadmaps. He’s also got a lot to say about numeric prioritisation frameworks, which I’m traditionally not a fan of, but he makes a strong case that they some use in your product prioritisation process.

Check out the interview on your podcast app or right here.

Itamar Gilad and me before the recording

Prioritisation frameworks have a place but aren't going to create your roadmap
The numbers are guesses but are useful to start conversations & make sure you're asking the right questions. It's important to revisit scores over time to see what's changing as you learn new things.

A word from the sponsor

Do you struggle with communicating with dev teams and understanding technical terminology and concepts? On episode 98 of this podcast, I hosted Irene Yu, founder of Skiplevel, an on-demand training program that helps professionals and teams become more technical in just 5 weeks... all without learning to code. You can learn the knowledge and skills you need to better communicate with developers and become more confident in your day-to-day role with the Skiplevel program. You can use referral code OKIP to support this podcast!

The Ambiguity of “Outcomes over Outputs”

I was chatting to Jeff Gothelf for the podcast recently (episode coming soon!) and we had a little aside that has been preying on my mind a little bit since. It’s about the common product manager’s war cry of “Outcomes over Outputs”.

Braveheart shouting "Outcomes! Over Outputs!"

“Outcomes over Outputs” is typically a rallying cry when confronted with another product management standard, the Feature Factory; the dreaded, smoky industrial building where downtrodden production line workers toil thanklessly to produce feature after feature on a strict schedule. The kind of place that older product managers tell their grandchildren about to scare them. No one wants to work in the Feature Factory.

“Outcomes over Outputs” gives us a new way. Rather than obsessing over specific, often valueless deliverables, we concentrate on the results that we drive. This speaks to another truth… there’s no point in efficiently delivering garbage that no one wants. We’re holding ourselves to a higher standard. We are aiming for changes in user behaviour that benefit our company. How we get there is flexible, and might not involve any features at all.

“Outcomes over Outputs” makes sense. If you explained it to non-believers, they might even say they want to work like that. There’s a little ambiguity there though, that needs to be addressed. This is primarily around the words “outcomes” and “outputs”.

Anyone involved at the sharp end of product development (developers, designers, product managers) will probably think of it like this:

Outcomes - the specific things we want to happen
Outputs - the features we build

However, someone working with a commercial mindset (sales, marketing, some exec leaders) might well consider it more like:

Outcomes - the features we can try to sell people
Outputs - developers typing/designers drawing/PMs writing tickets

Both sets of people will be quite convinced that they’re driving for outcomes, they just both think outcomes are different things. This can lead to confusion and cross-talk (and is why just saying product management phrases at leaders results in, at best, a polite nod).

But how does this work in the commercial parts of the organisation? What about Sales? Sales teams do not have easy jobs. They’re paid, at least in part, based on the amount of revenue they bring in. They get fired if they don’t bring in enough. What does “Outcomes over Outputs” look like for them?

Outcomes - the amount of revenue booked per quarter
Outputs - the number of meetings they have, what they move through the pipeline, the deals they close

From a commercial perspective, doing the operational work (their equivalent, in their eyes, of writing code) leads to revenue. Sales teams are constantly being hounded to get stuff through the pipeline, get deals closed, get that next meeting in the diary or get some more outbound leads. The more that they do, the more chances they have to hit their quota for the quarter. And the result of that? Revenue for the business. The ultimate goal of any CEO that wants to keep the lights on.

The most interesting part of all of this, though, is that salespeople do not (in general) get more points for closing Prospect X vs Prospect Y. It’s the revenue that counts! Marketing may well want Prospect X to turn into Customer X because they’re well-known, are a good logo for the website or maybe they can get a case study out of them. But, on a quarter-by-quarter basis, £250K is £250K. In many ways, the Sales team are the most “Outcomes over Outputs” team in the company!

OK, but so what?

I’m not really going to give you a magic solution, because mindset shifts are hard (and, in some cases, impossible). One of the things that I’ve been pondering is whether this invites a different approach with non-product stakeholders, or some different language to try to frame what (to us) seems obvious and get them to appreciate why we’re doing (or trying to do) what we’re doing. Trying to use analogies, and translate what we do into what other parts of the business do could be one way to try to bridge that gap.

I’d be interested in your thoughts and experiences!

That’s a wrap for now, but I’ll be back soon. Hopefully, some of this content was interesting - I’d love any feedback, and it’d obviously be great if you could share this with your friends.

Writing this newsletter is fun, and I love to give stuff away for free. But, if you want to buy me a coffee, you can always buy me a coffee.

One Knight in Product newsletter

Evidence-Guided Product Development and The…