Continuous improvement as a product manager

Continuous improvement – it’s the way to develop products. It’s also the way to be a better product manager.

I spend more time recruiting and directing product managers than I do being hands on with products these days. But because I love my trade and want to be the best coach that I can, I am always trying to up my game by learning new things.

Here are three ways I’ve been trying to improve as a product manager recently:

Better the devs you know

I am a product person who appreciates programming.

If I have a better understanding of the developer’s craft then my product vision is optimised, my explanation to the engineering team is more articulate and my appraisal of their efforts is better judged. Surely.

To that end, I’ve been steadily working my way through Codecademy’s courses, and by way of revision I’ve installed some of the Sololearn course apps on my phone, which are a better format for the commute.

Don’t send me your pull requests anytime soon. But it’s definitely broadened my thinking about the art of the possible… and the trade-offs. And it’s good to look at a team I work with everyday and see them in sharper focus.

The Jobs at hand

Ever since I started working in product management, it’s involved user stories.

And that’s been going great because user stories place more importance on the task someone is trying to complete when they are using your product than who they are or what my business’s requirements are.

But I’ve been hearing more and more about Jobs-to-be-Done and its application to product development, and I’m intrigued. It might be that ‘Job stories’ offer an even more relentless focus on what someone is trying to do and what their motivation is than ‘User stories’.

It might be that it’s time to make a switch or maybe there’s room for both in the mix of techniques I can use to make sure we are meeting user needs.

I’ve started asking my product managers to explore the possibilities of Jobs-to-be-Done, and Intercom has recently released a book on how they made the switch from user stories, which reads as a good, thorough introduction.

What a release

I’ve written a lot of release notes but I have started reading a lot as well.

It’s really easy just to hit ‘update’ and ignore the release notes; even easier never to acknowledge that release notes might be a thing produced for the service you use. I suspect that release notes are read only slightly more often than updates to T&Cs.

When you start to study release notes, you see there’s more variation between them than you’d first assume. Technical. Conversational. Brief. Detailed. But you can tell the difference between good and poor, well judged and lazy. Good products ought to have good release notes but not always.

I’m going to keep a book of examples, learn from them and see if we can get more users to take note of our release notes and use them as a means of engaging in a dialogue about what we’re developing and why.

Three improvements on before. But there is so much more to do.