Book review - My Product Management Toolkit

I met Marc when we both worked at Headshift, back in 2010. He’s been a friend I’ve been in touch with the last 8 years or so, and when I heard he had been writing a book about Product Management, and was offering copies for feedback, I jumped at the chance. I started reading it last night, and I finished it today - here’s the write up.

TLDR

[caption id="attachment_2967" align="alignnone" width="3072"] A quick snap of Marc's book[/caption]

In short, it’s the kind of book I’d love to have come across a couple of years into product management myself. Although it’s short, and designed to be a fast, easy read, Marc covers a lot of ground in this book, and provides lots of useful leads for further reading in the areas that might be relevant given your specific context. Given how relatively young Product Management as a profession is, and how much the job varies from company to company, I think this is a smart move.

If you’re a senior product manager, you will likely have covered a lot of this ground already, but I learned a few things from reading it, and there a few nice names for patterns or behaviours I’m glad I have a name for now, like the product janitor ( more on that later).

What it covers in more detail

While there are some nice summaries of applying Jobs to Be Done, User Stories, (probably the main day-to-day currency of agile product managers), there’s a substantial amount of space in the book assigned to the actually speaking to customers, and users.

Research and discovery for product managers

In particular, there’s a lot here that you might typically the kind of work you might associate with user researchers more than traditional product managers  - things like contextual inquiry, field studies, how to do interviews, how and when to use prototyping, and continuous discovery.

The political side of product management

As a product manager, you often have to rely on influence over authority when it comes to getting things done, and there’s an entire section on how to go about doing this from trading in different forms of social capital to manage upwards, downwards and horizontally.

There’s a common trope about product manager’s jobs basically being to say NO all the time, and I think my favourite quote in the book refers to this:

Product management is not like Christmas

In many cases, being the person who says NO all the time, can strain working relationships - Marc introduces a few ways to do this in a diplomatic, collaborative way.

I think this may be one of the most valuable parts of the book if you’d ever had to say NO like this, and experience the fallout it can bring.

He does this by showing examples of expanding a conversation, from straight yes/no feature request, to a richer one that lets the requester understand the trade-offs and costs they’re asking someone to incur when they want their pet feature.

He shows how to use cost of delay, opportunity cost, and incurred maintenance costs of building a new feature to help them understand the true cost of their request, along with ways to structure the conversation to give them a way to pursue it further if it’s truly valuable.

One phrase that was new to me, that I’m going to take with me was the idea of a product janitor - given how poorly defined product management can be inside organisations, it’s often the case that all the jobs that aren’t being done end up falling on the lap of the product manager, from scrum mastering, to bits of delivery work, like UX design, and so on.

This can mean that there’s no time for the strategic, customer facing, or commercial aspects of the job. It’s useful to have a name for this concept, as it’s depressingly common.

What it doesn’t cover

While there’s a fair amount about creating product vision, looking at trends and market size, there’s less than you’d expect about creating and sharing roadmaps. That said, this may be a function of this being something a more senior product manager would be expected to be responsible for, and this book feeling like it’s aimed at early to mid career product managers.

Also, while he mentions cost of delay in a number of places, I came away with the impression that if I hadn’t been introduced to it already, I’d want more of an explanation of the concept. Again, I can see why you might shy away from it, as while it’s powerful, it can be counter-intuitive, and confusing.

Also, while this assumes some flavour of agile development is the environment you’re working in, it doesn’t go into too much detail about how to make this fit into scrum, kanban or some variant.

When I read it, I got the impression there was an implicit scrum master, agile coach, delivery manager or similar taking care of process and making sure regular releases happened. This is probably a safe bet, as it’s not typically the product manager’s job (see product janitor), but if you’re in an environment where you’re having to think about process a lot, the book is focused on the why and what of building, but not the how.

Well titled, well structured

It’s hard for me to be objective, given that Marc is a friend, but, if you’re a few years into a product management career, and starting to feel like you know the ropes, I can happily recommend this.

It’s a fast read, you’ll be reassured by the examples of applying what you already know and do in other organisations, and you’ll pick up a few useful techniques to use in your day-to-day, as well as a lot of useful ideas to investigate as you grow.

You can learn more on Marc's own site, or on Amazon directly.