In order to know how to do something it is important to understand why that something exists in the first place. It is not hard to understand why we need developers. Nor sales, marketing, customer support and so on. But why do we need product managers?
“Why” does the role of product manager exist?
In a small startup you will normally not find a dedicated product manager (PM) position. The tasks of product management are just as important, but the responsibility is shared and distributed across the other roles. Everyone is sitting in the same room and communication flows easily. Everyone is closely attuned to the market. Prioritization is determined by the founder herself.
But when an organization scales, the people who could all fit around a single table for lunch, they drift apart. They are organized into functional silos. They communicate less. And that is when the product management function becomes critical. The role counteracts many of the drawbacks of scale and specialization.
A PM exists to:
Connect the Why with the What
When an organization grows into functional silos, the function can take on a purpose in itself. Well written code is a badge of honor. Design is appreciated for its beauty. But are we solving the right problem? It is all to easy to loose track of why we do what we do. The product management function acts as a bridge between the market and the functional development.
Facilitate communication between the functional silos
In an organizational hierarchy, communication flows easily within a branch, less so across branches. But for a company to succeed, all functions must work together towards a common goal with a coordinated effort. The product manager channels information to the different functions, or simply ensures that the relevant people communicate directly.
Fill in the gaps
When the functional silos are formed, inevitably, there will be gaps. The gaps will usually be at the fringes of the key functions, but that doesn’t mean they are unimportant. The product manager is held responsible for the whole, and will do whatever it takes to make the product succeed. Including filling in the gaps.
“What” should a product manager do?
Of all the material I have devoured, “Be a great product leader” by Adam Nash is the one I think summarizes it best:
Responsibility #1: Product Strategy
- What game are we playing?
- How do we keep score?
Responsibility #2: Prioritization
- Next three things to nail
Responsibility #3: Execution
- Product specification
- Edge case decisions
- Project management
- Analytics
Each of these bullets is worth a book of its own. And Nash describes them better than I ever could. If you are new to product management, go read the article.
These tasks may seem basic, but should not be mistaken for easy. If you can do these things well, you will be a good PM.
But while this is a great list of What to do, I will add five personal reflections on How to go about them:
“How” to go about it
1) Don’t get sucked into execution only
Adam Nash listed the responsibilities in an order for a reason. Execution is important, but also easy to prioritize. Every minute of your day, someone or something will be demanding your attention. You come into the office with a plan to do some long term thinking, but then the demands of daily execution take over. You tell yourself that one day doesn’t matter, you can always work on strategy tomorrow. And before you know it, six months have passed.
Strategy is something you have to force yourself to block out time for. Make sure you do. Because even the best execution can’t fix poor strategy.
2) Understand the problem
Albert Einstein supposedly once said that
If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.
To solve a problem you have to understand the problem, and the first step to understanding a problem is admitting that you don’t, yet! Many will probably take issue with this. After all, you know lots of things. Without that knowledge, you wouldn’t be any good at the job in the first place.
True. But the rub is that while pre-existent knowledge can be valuable, it can also hamstring you. Many of the things you know will be correct. But some will be wrong. And you won’t know which is which.
So the first step is to set aside everything you think you know, start with a blank slate, and be ready to rebuild your understanding of the problem. This is a lot harder than it sounds, as we instinctively work to retain our assumptions, so your challenge is to recognize and acknowledge them. And once you have emptied your mind, it’s time to fill it up again.
Einstein iterated on his quote to:
If I had an hour to solve a problem and my life depended on it, I would use the first fifty-five minutes to formulate the right question. Once I’ve identified the right question I can solve the problem in less than five minutes.
He went from thinking about the problem, to asking the right questions about the problem.
2b) Learn how to ask questions.
Ask everyone. In the organization, ask developers, designers, sales, support. More importantly, ask users, ask customers. Understand their needs.
In the tech world we talk a lot about experimentation. You define a hypothesis and a way to verify it. An experiment is simply a very effective method of asking questions, so experiment often.
And listen… Truly listen. This should be obvious, but like many obvious things, it actually isn’t. It’s all too easy for your biases to take over and make you hear what you want or expect to hear, rather than the true meaning of the answer.
3) Preach the ‘Why’
Once you understand the problem, you will (at least according to Einstein) know what to do. But the most important thing you can communicate to everyone else is not what do to, but the Why behind the What. Not just what problem are we solving, but why we are solving it.
Communicating ‘Why’ has two powerful impacts:
Motivation
Without understanding why, the How and What can appear meaningless. A task is in itself rarely a powerful motivator, but making an impact is. An individual, group or organization that understands the Why behind the What will be much more energized.
Direction and context
Understanding the Why lets people figure out the What themselves.
Have you ever felt stuck in endless disagreements over prioritization? Spent meeting after meeting working through iteration after iteration of design sketches that somehow always seem to be slightly off the mark When people understand the Why behind the What, most of this evaporates. People don’t need you to tell them what to do – they need you to clearly express the Why.
4) Understand how you add value
In most cases, a product manager does not create value directly. In a pure tech company, customer value manifests itself through code. Without developers, a PM is nothing, but even the greatest code ever written is worthless if it doesn’t solve a problem!
As a PM, you can have great influence on what is built, and with that, of course, comes great responsibility. If you are wrong you are potentially wasting everyone’s time. It is up to you to ensure that everyone’s efforts are directed at creating as much market impact as possible, and then simply get out of the way.
Help clear away roadblocks, give support and Bring the Donuts. But other than that, just let people do what they do best. Your role is not to create value directly, but to enable everyone else to.
5) Learn to love the hard parts
One of the challenges with being a PM is that you are supposedly responsible for so many things, yet you are not the boss of anyone.
There’s the developer who just won’t build what you say without endless discussion. The designer who spends days in a seemingly futile search of perfection instead of just making those wretched icons you needed a week ago. And the sales rep who just won’t take no for an answer. Imagine how easy life would be if they all reported to you. If you could just tell them what to do and get it over with.
Easier, yes. Better, no.
If something is easy, you do it the easy way, and shortcuts lead to crappy products.
When someone gives you resistance there is always a reason for it, and most of the time the reason is a good one. Strive to understand what is behind the resistance. What is the other person seeing that you are not? Is there something to learn that can make the solution even better?
It is the people and the situations that demand the most of you that make you better. The people who just go along with everything you say might make you feel good about yourself, but neither you nor your customers will be the better for it.
Product management is hard, by design
Learn to love the hard parts. Know that they make you better.
And when you ship, when you hear the user testimonials, when you see the numbers move – then grab a beer, lean back, close your eyes and enjoy that feeling you only get from the most challenging and fulfilling job there is!
Comments 3