Lessons from Product Management

Introduction

It occurred to me earlier this week that I’ve passed the six month anniversary of my transition from presales to product management. And if you’ll indulge me, I thought it might be worthwhile sharing some lessons I’ve learned over those six months. Perhaps if you’re currently in another role or even a pre-sales role (like I had been) and you’re interested in product management you may find these thoughts helpful.

So what have the first six months of product management taught me?

There is a difference between speed and velocity

If you don’t know where you are going any road can take you there.

Cheshire Cat, “Alice’s Adventures in Wonderland” (Lewis Carroll)

When you’re in an account-related role (e.g., pre-sales), you usually start the journey without knowing where you’re going to end up. In that case it’s OK to go fast because any outcome is useful. You might go into a customer meeting thinking it’ll be about cyber resilience, but come out realising there’s a better relationship to be had in say, cloud data protection. Or you might come out knowing there’s no opportunity at all, for the time being at least.

One of the chats I had in my first week in the job highlighted the difference between moving at speed and moving at velocity; i.e., actually having a defined direction (the latter). This has stuck with me — part of the job of a product manager is to help set direction, so that speed can be used effectively.

Be a philosopher

In this, I don’t really mean to question whether you exist, or whether you should follow utilitarianism, stoicism or some other particular approach towards achieving happiness and a moral outlook on life. That’s something you should do personally, of course, but I have a particular focus when I say it in the context of product management.

You might say that core aspects of philosophy can be boiled down to:

• Challenge assumptions
• Expect to have your ideas/assumptions challenged
• Be prepared to show your working

All of these apply to product management, too. Assumptions should be challenged. Not endlessly, of course. There reaches a point where you have to set a direction and maintain it (see above point). But every voice is important, and every opinion is important, even if those voices or opinions don’t agree with you. Especially if those voices or opinions don’t agree with you, in fact.

We say that political and business leaders fail by surrounding themselves with yes-men. Product management is about surrounding yourself with what-if people.

You have biases. Know them.

This is a direct instance of the above piece of advice, but it’s worth calling out on its own. Recognise where your prior experiences may influence what you think. Learn to recognise when that’s leading you to a gut decision that isn’t sufficiently informed or nuanced. Learn to unlearn. Another product manager imparted this wisdom to me when I was just getting started in the role.

I can’t talk about what I’m working on, so I’ll give a high level example, if you’ll bear with me.

I was in a meeting in my first month and someone said, “People ask to do X.”

Me, having always thought I’d like to do X: “Well yes, of course they should be able to! If they want to do X 100 times we should let them!”

A little while later I was afforded access to some research that articulated why people were asking to do X. And then it occurred to me. Asking for X and needing X are two different things. Just because I’d always thought X was good didn’t mean it was — it just meant I was approaching the problem with the same legacy baggage as others.

In short, X was a statement of a how (the steps you take), not a what (the outcome you need to get to). Being prepared to rethink the what allowed me to throw out those biases and look at the problem statement with a fresh lens.

Research

If you do a product management course, here’s one thing that will be hammered home to you: research, research, research. (Quantitative and qualitative.)

Gut feeling will only get you so far. Product management is very much a data-led discipline.

Be passionate

You can do some jobs by rote.

Product management is not one of those jobs. You need to be passionate about what you’re doing. And what’s not to be passionate about it? You’re helping to craft the future.

If you can find that passion you can bring it to every conversation you have, every user story you create, every feature you try to introduce.

Always ask yourself, “What is the customer perspective?”

We like to think in account-facing roles (sales, pre-sales, etc.) that we’re highly focused on the customer perspective. And we are. But product management takes it to the next level. The product is important, but if your product doesn’t take into account the customer perspective, you’re designing it for yourself, not other people.

What user personas/buyers will find this interesting? What value will they get out of it? How will it delight them? What problem does it solve? You have to be prepared to ask all these questions. More importantly, you have to be committed to finding out the answers to those questions.

What, not How

I alluded to this in “You have biases. Know them”, above. It’s an important shift in perspective when you’re coming from a technical role. In technical roles (pre or post-sales engineering, support, implementation, etc.), your focus is on how. There may be some what involved, but your focus needs to be on the iterative steps that will get you there.

Yes, how is important in product development. But if you, as a product manager, get hung up on how, you’ll lose sight of your goal: to define the what. And with the what comes the why (that customer perspective, again). Rely on technical experts (architects and engineers) to explore and establish the how. That’s their job, after all.

Develop an Ideation Discipline

Opening up a word-processing document, empty Jira epic or plain text file and just jotting ideas down will only work in the simplest of circumstances. Product management is about exploring ideas, and to do that properly, you need to develop some rigour in how you do it.

Maybe for you it’ll be brainstorming on a white board, or building word-clouds, or writing every point you can think of down in a notepad. The medium doesn’t matter so much as making sure you develop the patience and skill to explore a concept.

For me, that came down to finally realising the utility of mind mapping, and subsequently learning how to use mind-mapping software. (I’m using XMind and I thoroughly recommend it.)

World Time Buddy is your Friend

OK, this might be more to do with the fact that I have team members across all US time zones, India and Israel — just to name a few. But World Time Buddy has been invaluable to me in my role, since Outlook isn’t useful enough to present a multitude of time zones simultaneously while planning meetings.

In that, I don’t even need to (or use) the hooks for calendar integration. But when I’m trying to setup a multi-time zone meeting, World Time Buddy saves me a tonne of headache.

(And yes, 3am is a reasonably common meeting time for me.)

You’re a filter, not a conductor

When I went for the product management role, I kind of naively likened it to being the conductor of an orchestra — getting all the different parts to move together in harmony. It was suggested instead to me that the role of a product manager, more than anything, is to be a filter.

Six months in, I really do get that. There are a lot of ideas, but no matter where you are, resources will have finite constraints, as will time. So product management is about filtering down to what needs to be done, and what can be done.

Wrapping Up

I could probably note another dozen or so things that have struck me in the first six months of my role, but the ones above have resonated to most with me during that time.

I’ve been asked a few times if I’m happy with the decision I’ve made. (Especially in the context of mentioning I had to set my alarm for 00.30 for a 01.00 meeting.) The answer? Hell yes. What an exciting and joyous ride.