One Year a Product Manager

2022 was a complex year for me. In some senses, being another pandemic year, it was remarkably similar to 2021 and 2020, but there were some marked differences. For a start, I went more than 10km away from my house for the first time in more than two years, when I visited my parents for dad’s 80th birthday in August 2022. That’s something I’m profoundly grateful for, given he passed at the end of the year.

I also discovered people think I’m resilient. This was quite a surprising thing for me. But, apparently being willing and able to get up at 2am or earlier for meetings strikes most people as either crazy or dedicated, or perhaps a little of both. (Personally, I’d take a week of 2am calls over a single 11.30pm call, so sometimes I think this is just a night-owl vs early morning person thing.)

Last week marked my first year as a product manager, and I thought it worthwhile reflecting on some of the things I’ve observed about product management over those twelve months. So here we go, in no particular order.

It’s like Tetris

I kind of grew up on Tetris (OK, Tetris and Bards Tale III). The weird thing about spending a lot of time playing Tetris as a kid is that it gets in your head. You’ll be sitting down somewhere and see a bunch of multi-coloured tiles on a floor or wall and you’ll start to group them into Tetris block patterns.

The funny thing is, once you get into product management, everything becomes a Tetris block. Or rather, every new thing you buy or get, you start looking at with a product management lens. You find yourself looking at almost anything you buy and asking questions like:

That’s not necessarily a bad thing. It keeps you on your toes. But it does sometimes mean you have to exert a little more effort to switch off. Or, maybe you don’t bother to switch off. It’s actually quite interesting looking at new things with those perspectives in mind.

Note the notes

To be honest, I’ve said this for every job I’ve been in, so product management is technically no different:

1. Take notes.
2. Brevity is the enemy of future understanding. (You need to include enough context in your notes that they make sense later.)
3. Make sure they’re searchable. (I.e., electronic notes will give you the best return.)
4. If you’re in a meeting and you’re not speaking, you should be taking notes. (Within the bounds of being able to follow conversations while taking notes.)

I’ll admit I have an advantage here – I touch type at high speed and can generally get enough notes taken by typing during the meeting. If you’re going to be in a meeting where you’ll do a lot of talking but you still want to take good notes, see if you can record the meeting and take notes later by listening to the recording. (I personally do my best to avoid this, because I cringe when I hear my voice in a recording.)

I’ll add a recommendation here, although I can’t use it in my own job. Check out Notion. Notion is, without a doubt, the best note-taking system I’ve ever used. Unfortunately for work I’m reliant on OneNote and I make that work as best I can – but if you’ve got flexibility in your options, check out Notion.

Focus on user outcomes

Someone uses your product. (I’ll get to who in the next point.)

The implication of this is that products aren’t for product managers or engineers: they’re for users. That creates a significant imperative – everything you do should consider the user understanding and outcome.

(Automation is a good example of this – when you automate something, you should automate with an understanding of what the user wants to achieve, not some preconceived notion of a step-by-step process that might be followed in the GUI to get to that outcome. )

Understand the personas

If you’re going to focus on user outcomes, you must understand the personas – the types of users – who will be making use of whatever product or feature you’re designing. This is much more than just saying “a primary persona is a backup administrator”. You have to think about what drives that persona. This includes having answers to at least all of the following questions:

1. What are they looking for?
2. What irks them?
3. What helps them work better?
4. Who do they influence?
5. How deep can they learn what you’re producing for them?
6. Are they actually interested (passionate) about what you’re producing for them, or is it just something they have to do?
7. How much will they get involved in what you’re producing for them?
8. What are their responsibilities?
9. To whom are they accountable?
10. What else do they do, when they’re not working with what you’re producing for them?

All of these questions are important in terms of framing how a persona (or personas) will interact with what you help to create.

Remember too, there will be more than one persona involved. In fact, you’ll possibly have to consider multiple primary personas and multiple secondary personas. That means consideration of persona requirements and outcomes is multidimensional.

Find your Passion

You might say this about any job — if you’re passionate about what you do, it makes it easier. But it’s not just about making it easier, it’s about bringing everyone along with you for the ride, too.

I’ve been a big believer in Simon Sinek’s Start With Why since I first heard of it around 2010:

Now it’s common to think of the why work as being outward facing … how do we better engage with customers and the market? We do it by articulating our why. That’s true. But the other truth here that can be missed is that why is also something you have to direct inwards to the people you work with, too. Have a passion for what you’re doing, articulate that passion and people will join you on the journey.

Bigger is better

I’m not talking about products here.

I’m not talking scope.

What I am talking about is your monitor. The smartest decision I made mid-year was to replace my current monitor setup with a 49″ Ultra-wide monitor. Why? Jira. Fantastic tool, but best viewed in a very wide browser window.

The devil is in the detail

Product management is a surprisingly quirky mix of broad brush/big picture perspectives and quite detailed considerations. You don’t get the luxury of concentrating on just one.

You know the saying “You can’t see the forest for the trees”? Product management is definitely about making sure you can simultaneously see both the forest and the trees.

Back to my point about taking notes: you can’t remember everything. This means you have to become a top-notch planner.

At any one time you’ll probably a couple of dozen pans in the fire and you need to make sure you can keep track of them all. (Or, if you’ve ever watched Survivor, it’s like one of those end-of-season challenges where players have to keep adding balls to a rolling circuit and be constantly aware of where the balls are, ready to catch them as they get spat out and put them back into play.)

Explore your ideas

It doesn’t matter how you do it, but you need to make sure you can take the time out of your day periodically to explore ideas you may have about items you’re either currently working on or want to work on.

It’s more than just having the time available though. It’s also finding the exploration method that works for you. Is it whiteboarding? It is post-it notes on a wall? Maybe it’s mind-mapping. For me, surprisingly, it turned out to be mind-mapping, and I stand by my previous thoughts about how awesome the Xmind tool is.

Data, data, data

Gut feelings will only get you so far.

When you’re planning new products or features, you need data. You need to talk with people. You might start with your own idea about what should be done next, but you should then qualify that with people who have direct experience, too.

The focus here is to be open to alternate perspectives and different experiences. Talk to the market, or people who regularly interface with the market, and get an understanding from them. Or in other words, don’t silo yourself.

Listen to the experts…

When you’re in product management, you’ll end up spending a lot of time talking to people who have deep, deep subject matter knowledge. I’ve gained more insights in a half hour meeting with some people than I had dozens of training courses at times.

And that means when an expert starts highlighting considerations, listen. Listen really carefully.

One important note here: experts come in all forms. It’s easy to think “expert” and assume I’m talking about engineers and architects. But I’m also talking about designers, marketers and a host of other specialised professions, too.

…but be prepared to challenge them

This isn’t a Dunning-Kruger thing, of course. Don’t assume you have deeper technical knowledge than the experts in your team. But your job is to bring a business/user perspective to what you’re doing. So that means being prepared to dive deep on things experts are saying, and counter with known business/user imperatives to make sure you still end up with the right thing.

If nothing else, familiarise yourself with The Five Whys and get to the heart of the matter whenever you need to.

UX ≠ UI

The user experience (UX) is not the same as the user interface (UI). Now, that’s not to say there isn’t a lot of overlap at times. But while UX should go into any UI design, UX is a superset that encompasses more than just the UI. Remember my earlier point, “Focus on User Outcomes”? That’s UX.

If you want to do UX right, you have to consider a full lifecycle approach. If someone is going to buy some widget X, the UX starts at (at least) the moment they’ve committed to buying it and they’re waiting for it to arrive. And the UX continues through to just a little bit beyond when they’re no longer using it, encompassing everything in-between. And even when they’re actively using your product, it’s not just the UI they’re using.

Say no – but don’t forget

At any given point you’ll have requests or suggestions coming in from all directions. Many of them will be great requests. But based on the resources available, you won’t be able to get to them all.

So you need to be prepared to say no from time to time. Arguably you might even say no more than you say yes. Steve Jobs once opined, “Focus is about saying no”. And that’s a tough lesson because many of us are hardwired to want to be helpful, to do things. But in some walks of life, being helpful and doing things is best accomplished by making sure you’re focusing, focusing on doing just the things that need to be done, and doing them well. Doing them great, in fact.

But that focus doesn’t mean throwing everything out that you can’t get to today or tomorrow. Make sure you save those ideas for later. What you can’t do now might be something you can do later once you’ve got other things done.

It’s all about the process

This is something I talk a lot about in my backup books. Process is everything. You can have the best technology in the world, but if you don’t actually organise and run it with processes, you’re just doing random stuff and hoping it sticks.

There’s a flip-side to that statement though: processes can be, and processes ought to be improved. Never assume that a process is perfect. Always be prepared to ask yourself, “could this be done more efficiently?” or “could we get a better outcome?” This is, in fact, applying kaizen to everything you do or get involved in.

I’ll give you an example of how you approach this. Imagine you come across someone who is trying to dig a hole using a teaspoon. You ask them if they need help and they say that if there were a couple of more people with teaspoons available, the hole would be dug sooner.

That’s true. Five people digging at the same hole, each armed with a teaspoon will deliver a hole sooner than one person digging at the hole with a teaspoon.

But one person digging at the hole with a shovel will deliver the hole faster than five people with a teaspoon will.

Every time you encounter a process, don’t just learn the process, but be open to the idea that you might think of a way to improve it.

Wrapping up

I can’t say how happy I am having made the transition into product management. And I say that with the fact that I went from having fairly predictable 9–5 style hours to somewhat topsy-turvy hours. Even with that, this is the coolest and most exciting job I’ve ever done. (That experience won’t be the same for everyone, of course. For me, that’s driven by being part of a global team. And for sure, there are some days that leaves me pretty tired. But it’s still been thoroughly worthwhile.)

I actually think product management is a natural career extension from presales engineering. There are a lot of overlaps in detail and discipline between identifying potential solutions for customers and helping to create those solutions.

And it’s a whole lot of fun.