10. Adam Nash:
Be a great product leader
• 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
http://blog.adamnash.com/2011/12/16/be-a-great-product-leader/
There's no university class called "product management".
What Product Management is varies greatly from industry to industry and company to company. Even from team to team.
I will talk about it in the context of a tech company. Software developers, writing code.
Even in that context, what a product manager does can vary from day to day. Everything from Sales. Marketing, User Research, Design, Analytic, QA, Architecture, Project Management.
Core to the role is that you manage a backlog. Meaning that you decide the priority of the tasks that a team of developers are working on.
You don't have to come up with all the tasks yourself. In fact, the more they originate from others the better. But you are the final arbiter of which sequence they will be worked on.
Why does it even exist? It's a common question.
Everyone understands why we need developers. And sales people. And support. But why PM's?
A bridging function. A necessity of scaling.
The Product Management position is rarely found in a small start-up. The tasks of product management are just as relevant, but the responsibility is shared. Everyone feels the pulse of the market, and every function talks to every other. Sales, Marketing and Development all sit in the same room. The Founder herself is usually the owner of the backlog.
But when the company grows these people get organized into functional silos. And they stop talking to each other. Furthermore, with a running business with demanding customers and legacy code, the complexity increases. There are so many more things that require attention within the functional silo.
This is when the Product Management position becomes valuable. When a company scales, the "Why" behind the things we do can get lost and writing code turns into a purpose in itself. And multi-disciplenery deliverables like a product launch can break down without someone to fascilitate communication and coordination between functions.
Product Management done well has a multiplier effect on the organization. With it, the contribution of everyone else is more likely to create real value for customers.
There are hundreds and thousands of articles out there about product management. And they are all slightly different ;-)
Especially if you are new to the field, that doesn't help. When learning anything new: the first year you don't need a hundred books, it's better to focus on just one good one.
Of all the ones I have read, "Be a great product leader" by Adam Nash is the one I think summarizes it best. He says product management is doing these three things: #1, #2, #3
I could spend hours on this list. But frankly, Adam describes it better than I ever could. If you are new to product management, go read the article. Then read it again. And again ;-)
These tasks may seem basic, but don't mistake them for easy. If you can do these things well, you will be a good PM.
But I would like to add some personal reflections. If this is a list of what to do, I will try to say a few words about how to do the, to them well.
Execution is important, but it's easy to prioritize. Every minute of your day, there is somone or something 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 on the other hand is something you have to force yourself to block out time for.
Adam Nash listed them in this order for a reason.
Good execution can’t fix poor strategy.
To solve a problem you have to understand the problem.
And the first step to understanding gaining an understanding is to admit you probably don't already.
You, me, Jon Snow. We know nothing.
Many of you are probably calling BS on this. You know lots of things. That's what makes you good at your job in the first place.
True. But the rub is that while preexistent knowledge can be valuable, it can also be a hamstring. Many of the things you know will be right. 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 and start with a blank slate.
Once you have emptied your mind, fill it up again.
Here's the next iteration of Einstein's quote. From thinking about the problem, to asking the right questions about the problem.
Learn how to ask questions.
Ask everyone. In the organization, ask Developers, Designers, Sales, Support.
More importantly, ask Users, ask Customers. NIHITO. Get out there.
In tech we talk a lot about experimentation. You define a hypothesis and a way to test it. An experiment is in effect a method of asking questions. Experiment often.
Asking questions is a skill in itself. Ask often. Iterate. Get good at it.
And listen… Truly listen.
Should be obvious, but like many obvious things, it isn't.
Once you understand the problem, you will (according to Einstein) know what to do.
But the most important thing you can communicate to everyone else is not what, but the Why behind the What. Not just what problem are we solving, but why are we solving it.
This has two powerful impacts:
1. Motivation
Without understanding why, the how and the what can appear meaningless. The task itself is rarely a powerful motivator. Making an impact is. An organization that understands the why behind the what will be much more energized.
2. Direction and context
Understanding the Why helps 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. Most people don't need you to tell them what to do. What they really need to you is to explain the Why.
Realise how you add value. In most cases, a product manager does not create value directly, but via others.
In a pure tech company, customer value manifests itself through code. Without developers, a PM is nothing.
But even great code is worthless if it doesn't solve a problem.
As a PM, you can have great influence on what is built. And with that comes great responsibility, not to waste everyones time. It is up to you to ensure that efforts of everyone else creates as much market impact as possible.
Your role is not to create value directly, but to enable everyone else to.
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 it the way you say without endless arguments.
The designer who spends days in a seemingly futile search of perfection in stead of just making those damn icons you need a week ago.
The sales person who just won’t take no for an answer.
Imagine how easy life would be if they all just reported to you? If you could just tell them what to do and get it over with.
Easier, yes. Better, no.
If it is easy, you take shortcuts. And that leads to crappy solutions.
It’s the people and the situations that demand the most of you that make you better. Them who just go along with everything you say might make you feel good about yourself, but neither you nor your users and customers will be the better for it.
Product management is hard, by design.
So my final advice to you is learn to love the hard parts. Know that they make you better. And in the end, 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 be thankful that you – yes you – have the best job there is!