JUN 6, 2017
"Product Manager? What is that?"
Let’s start with a confession — I never quite know how to explain to people what I do as a software Product Manager. Well, don’t get me wrong, I can babble buzzwords and jargon from job descriptions until the other person gets bored. I know how to give that answer.
But in terms of thoughtfully explaining it to someone if they’ve never worked for a technology company and had a chance to see someone in the role day to day then it can be hard to think of an appropriate analogy. Especially if you’re also trying to provide insight into what’s required to do the job well.
The analogy I’m most fond of relies on setting up a slightly absurd premise around a hypothetical road trip. It seemed like it was time to flesh it out fully and see if other people found it helpful. So without further ado…
Imagine you’re in a car with a few friends — Doug the Designer and Erin the Engineer — and you know you need to head from the East Coast to the West Coast. Except you have little money, no GPS, do not know the exact destination, and there is no specific deadline for your arrival but you know it’d benefit you to get there in an expedient manner. Finally, let’s assume the car runs okay but it could use a fair bit of work. How do you get started?
Well, Erin is focused on evaluating improvements or making repairs to the car. Doug has thrown himself into iterating on possible routes, talking to people every time we stop to get feedback, and generally trying to help find clarity on where you need to go. It looks like you’re the driver of this grand adventure. Congratulations — you’re going to learn what it is like to be a PM.
Now, don’t get too excited. You’re not in charge. This simply means there are going to be a lot of inputs on this trip and someone needs to be responsible for making decisions.
I realize those statements seem to contradict one another. I’ll try to explain. You’re empowered to make decisions because people are letting you make decisions. This road trip is a team endeavor and everyone has a job. You’re job happens to be “make decisions” but don’t start thinking it’s more important than the other jobs. All of the jobs need to be done well for this trip to be successful.
But how do you know if you’re doing your job well? For starters, you don’t have to worry about making the “correct” decision every time. Remember, this is a world of imperfect information informing a near infinite set of options — there won’t be an objectively “correct” decision in that atmosphere. This isn’t a math problem set.
But you will need to exhibit “effective” decision making. I’ll explain what I mean but, first, let’s look at some of the types of decisions you might be faced with on this road trip.
The windshield wipers have broken unexpectedly but there is no rain in the forecast and there is no traffic on an oft congested road. When do you pull over to have them repaired?
(aka unexpected bugs in your software that are not yet affecting the business)
The person who gave you the last set of directions said it was “definitely Exit 22… or 23” that you needed to take. Do you stop to find someone else to ask to for confirmation or do you keep going with your best guess since both exits are going in the right ultimate direction?
(aka the team has come up with two interesting concepts to solve a problem for users)
Half way across the country, you come across a great deal for a used trailer, which would allow you to haul more supplies and be more comfortable in the car, but to use it you’d have to completely replace the rear bumper and install a trailer hitch over the course of a few days. Is this a good time for the investment or do you press on without it?
(aka the product has matured but you’re starting to feel the pain of earlier tech debt)
So what constitutes “effective” decision making in these examples? Erin thinks the windshield wipers need to be fixed asap and Doug is indifferent and so on. On an individual basis, it might seem difficult to evaluate each decision and it is! How are you supposed to know how you’re doing as the driver?
Simple, you don’t have to evaluate each decision. You need to periodically answer two broader questions.
Are we still heading the in the right general direction at a rate that is faster than our comfort level?
Are people still excited about this journey and motivated to continue?
That’s what I do as a Product Manager and what you’re doing as the driver on a fictitious road trip — find ways to keep moving quickly in the right direction with a motivated team. That’s the crux of it.
It’s not easy but it’s straightforward.
These two questions happen to be easier to measure across a collection of decisions than they are on individual decisions. That’s okay. In fact, this is a good thing as measuring every single decision is exhausting and time consuming. Don’t bother.
Further complicating the evaluation of individual decisions is the fact some “effective” decisions will inevitably put the group’s success above a particular team member’s point of view or interests. If you’re doing your job well then this won’t be a surprise. You’ll know when making the decision that it’s going to bother Doug, so getting immediate feedback from Doug on that specific decision isn’t adding a lot of value in the moment (though speaking with him 1 on 1 to explain your rationale is valuable). Instead, having Doug reflect on how things have been going in 2–3 weeks when there are more decisions and data points for him to consider will yield a much sharper perspective on how you’re doing.
But you don’t have to worry about these complexities.
Simply asking a team to report how happy they are with the progress made over some recent time period and how motivated they are at the moment and you’ll get a quick and reliable assessment of your decision making.
This is why a successful PM needs to be an “effective” decision maker (going in the right direction) and skilled at team management (keeping people motivated).
Those are the two most important aspects of the job in my opinion. It happens those two things are a bit nebulous and highly contextual hence why I contrived this whole example. To put it in road trip terms — are you making good time on the trip and does everyone still want to be in the car?
Now, don’t get me wrong. A successful PM will have a well rounded skill set outside of these two attributes. Relevant domain expertise is a huge advantage (i.e. knowing how to drive a car). Some level of proficiency within design and technical areas will make you more flexible in how you can help the team (i.e. being able to change a tire or read a map). Strong relationships will all parts of your organization will allow you to connect dots you might otherwise miss (i.e. getting honest input from people outside the car). Attention to detail, good communication skills, etc. — the list is long.
Anyways, enjoy your respective road trips and I hope you trust your driver.
P.S. — This analogy is a work in progress. Let me know what you think! I’d also be curious how people might extend it to further capture other aspects of being a PM for a software company.