Product Bugle - Product lessons-learned special!
Slightly different newsletter this week: An essay on lessons learned from the real world of product management.
I’ll put it up as an article on either LinkedIn or Medium next week. TV stuff; and other links of interest will be back shortly.
PM Notes: Lessons-learned in the real world
One of the reasons I started writing this newsletter was to start to start to crystallise a lot of what I’ve learned over the last decade or so.
Some weeks it’s just a screed of links to other people’s stuff with a bit of commentary; some weeks I find I have something to say.
This week is definitely more of the latter. It’s basically a wrap-up of a number of points I’ve been making, and ideas that have been forming while I’ve been doing this. It’s also the a slightly random selection of things from an eBook that I’m not making anywhere enough progress on.
Customer experience > Your experience
First, a note of caution. I write a lot here about ways of working: tools; frameworks and how careers as a Product Manager are structured.
I find this interesting, and important. If you get these things right and the experience of being a Product manager is so much better. Get them wrong, and it can be pretty grim. But it’s worth stating up front that none of it is as important as the experience we give our customers.
This isn’t a platitude. It needs to be litmus test for everything we do.
As our products, technologies and organisations get more complex, so, yes, we need to be more sophisticated in the processes and tools we use.
But, great ways of working aren’t actually great if they’re not improving our customer’s experience of our products. How something ‘feels’ isn’t the same as how it delivers. And with that…
Product management in two words: ‘reducing ambiguity’
Your job: Eat. Sleep. Reduce Ambiguity. Repeat. Every activity product mangers undertake - if done well - is an exercise in reducing ambiguity about one of the following: the direction of your product (vision, strategy, OKRs, roadmapping); the details of what you’re going to be building next (discovery/ prioritisation/ sequencing and definition); and whether or not the products you have in the market as working (insight and analytics).
Less ambiguity = less wasted effort = more attention paid to the right things = better products and experiences for our customers.
Remember that this what the email you’re about to send, the meeting you’re about to organise, or the doc/ deck you’re about to write is there for.
One top tip: on any initiative keep a list of ‘open issues’. Even writing the list is a big step forward. Then take enormous delight in progressively closing them down, one by one.
Decision making is a muscle you build over time: start working out, now.
Good products are fuelled by good decisions. At the heart of every product process lie dozens decisions. It’s not a co-incidence that good decision-making is something Jeff Bezos talked about often (including in his letters Amazon shareholders): because the quality of decision making in an organisation has a massive impact on the quality of the company as a whole.
As a PM sometimes you will be making decisions yourself - but more often, your job is to bring together the right people and the right information to ensure that decision gets made.
We all get better at this with experience. Partly because we understand the dynamics of how decisions get made where we work; and partly because experience gives us context (including lessons learned from bad decisions we’ve made in the past!).
That said there’s a load of tips; hacks and thought exercises you can use. Some of which I covered last week. But a few more:
1) Don’t burn calories over decisions that are mostly subjective; have marginal impact; and are ultimately reversible. Ask ‘what’s the worst that can happen if we get this wrong?’
2) Always look for the decision(s) that you or the team made that were closest to this one - how did it go? what did you learn?
3) Seek guidance from your peers. Sometimes even just by explaining the situation to others, the right path becomes much more obvious. Similarly, make time for those who are stuck on something. Even just listening can help. Which brings me to..
Good communication makes a good PM. Good listening makes a great one.
Every product job description and ad I’ve ever seen - or written - calls for people to ‘have excellent written and verbal communication skills’. I don’t remember a single one that ever called for people to be a good listener - even though it’s just as important.
Similarly, when people ask for training, it’s often introverts asking about how to present; it should really be the extroverts asking about how to listen.
Listening matters. But listening isn’t the same as just being quiet for a bit while you wait for the moment to spout your words of wisdom. It means absorbing what someone is saying - and sometimes not saying; asking questions to get clarity; and then really listening to their answers.
For a PM to do well, you need to genuinely listen to your customers; to your stakeholders; to your boss; to your team; to your peers.
(And yes, if you’ve worked with me in the past, you’ll know I wasn’t always great at this!)
There is no one ‘right way’ to do Product Management - that doesn’t mean there are no bad ways.
Product management doesn’t happen in a vacuum. As a result you can’t define exactly how a PM or team of PMs will work without the context of either their immediate collaborators (normally the design and engineering teams) and the broader stakeholder environment (especially business teams and key customer groups).
‘Best practice’ in one organisation might result in a toxic mess in another. How product teams work at Facebook is different to how they work at Amazon, or in a newspaper, or a B2B start up.
The multidisciplinary ‘product team/ squad’, for example, is a great model. But lots of great companies have shipped great products without it.
I don’t want to bang on about what ‘bad’ looks like. But it exists. It’s definitely not just about morale. Some of the things I’m most proud of working on in my career were also some of the worst experiences.
If you can work in a way that has impact and keeps everyone happy, great. But if I had to chose between the two - I’d go for impact every time.
Product Ops is a thing, but it can’t be divorced from Design Ops and Dev Ops
It might be a bit of a neologism/ buzzword; but Product Ops - the tools and methods you use to manage the flow of information through the product process - really matters.
Inefficency creates ambiguity. And, as we know - that’s not part of the plan.
Product Ops might mean a small team; or no team at all. What matters is not who does it, but that this gets done.
The good news: there are a ton of incredible tools out there to facilitate this activity. The bad news? there are a ton of incredible tools. More tools, split across more teams doesn’t make you more efficient - which is why this can’t be isolated from your Design Ops; and Dev Ops. You’re trying to manage one well-oiled machine; not create a robot wars of competing web apps.
That elaborate prioritisation scoring system won’t help with the decisions you actually need help with
Who doesn’t love a prioritisation framework? Some nice system with a lovely little acronym and hopefully a chart or diagram that gives you the sense of bringing order to the long long list of things you need and want to build.
In my experience, all of these frameworks tend to be very good at making the prioritisation decisions that you could have made without them; but still leave you scratching your head about the big difficult decisions that made you go to the framework for in the first place.
The reason is that you’ve already done the mental maths on Effort vs Impact vs Urgency etc and you’re stuck. Turning it into actual numbers, no matter how clever the formula doesn’t really help.
So, when I see people saying ‘here are three different prioritisation frameworks you can use’ - what I actually read is: here’s three different ways to keep you busy but avoid a difficult prioritisation call.
This is where you need the right people in a room. But, open discussion among a team is often also difficult. Senior leaders can - often despite their best intentions - anchor everyone else’s thinking. Groupthink takes over. People with relevant dissenting views can stay silent for a whole host of reasons.
FWIW: My preferred approach for difficult decisions is this: Get the right people in the room (real or virtual); present the problem and a set of options; ask if anyone has anything to add - in terms of information (not opinions); do a blind vote on whatever options there might be (using MS or Google Forms or Survey Monkey); when the results are in - then discuss to conclusion.
Push for the right decision, not a compromise. As the old adage goes: if you say the sky is blue, and someone else says it’s yellow - don’t go with a compromise of green!
The things we dislike are the things we need to get good at to be successful
There’s a great bit of research by Product Plan that says the three things PMs like least about their jobs are 1) Internal Politics; 2) Too much tactical work; and 3) A lack of resource.
The irony is that if you want to be good at your job - these are the three things you have to learn how to deal with. They do not go away. As you get more senior, you need to realise that dealing with these three things isn’t getting in the way of your job; dealing with them is your job.
PM careers are still way too haphazard
I’m biased, but I think Product management is an awesome career. However, it’s very tricky for anyone not in it to understand and find a clear path in.
Like many others of my era, I stumbled into it. That’s typical of a nascent job discipline, but it’s not how things need to work.
At the moment, Product Management tends to be something you come into after you’ve done something else. Often (esp in the US) after you’ve done something else and an MBA.
Often though, the careers are much more haphazard - see the two examples I’ve linked to below. Great for those individuals who can hustle their way in, but you don’t have to hustle in this way way to become an accountant..or consultant..or lawyer. So why this?
The point is product management as a career should be a) widely understood; b) desirable; and c) attainable.
It’s great that the Meta RPM (Rotational Product Management) and Google APM program exist. And there’s a load of fuss about how to crack the PM interview at one of the FAANGs. Great, but only for a select few. There are more ways to become a lawyer thank breaking into one of the big city law firms.
The upshot: everyone in PM leadership in their organisations should be making product management a job that graduates can do straight out of University.
At Sky we benefited massively by making Product management part of the core tech graduate rotation program. As I left we had kicked off a program to ignite the ‘Associate Product Lead’ level.
MBAs are great. Joiners from other careers will always be welcome (and often awesome), but unless we get the more obvious and simple route right, we will miss out on talent.
Related links
> Are you doing product management, or bullshit management? A killer question from David Pereira
> How Facebook builds products from Will Lawrence who does the excellent Product Life newsletter. Good because it scratches at the surface of different approaches/ ways of working.
> So you dislike your PM job research from ProductPlan.
> Atlassian’s twin track product career paths making way for people to rise through the ranks as individual contributors. By Sherif Mansour.
> Roles in a Product Engineering Squad Like I said - not the only way to do it; but pretty much the textbook on how to go down this route.
> What is Product Ops? from the nice people at Product Board
> The rise of Product Ops comprehensive eBook from Pendo
> Jeff Bezos on making decisions
> How to become a better listener from Fast Company
> 4 Tips for Product Managers to be better listeners
> Guide to writing a Product Requirement Doc - lots of guides like this around, but this one is pretty good.
> SU RICE: a product prioritisation framework for B2B Saas products
> 3D Prioritisation scoring - by the same author
> My journey into product management: by Kelechi Ejikeme
> Another j0urney into product management by Aatir Abdul Raus
And finally..,
Well done if you made it this far! And sorry there isn’t a sweetener about TV at the end.
As always - feedback on any of the above is much appreciate. Just reply to this and it’ll get through.
Have a great weekend. And if you happen to be free and in Guildford on Saturday, tickets are selling out fast for the musical event of the year!
A weekly round up of Product Management goodies - all very grounded in the real world. Plus: updates what I've been watching and listening to. Every Friday, from deepest Surrey.
In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Every Friday - freshly wrapped in home of Ockham's Razor