Things a Good Product Manager Should Think About(jpuopolo.com)
jpuopolo.com
Things a Good Product Manager Should Think About
http://www.jpuopolo.com/2011/09/5-things-a-good-product-manager-should-think-about/
24 comments
I agree with almost everything except point 1. A Minimum Viable Product is exactly that-- the smallest possible product that will be viable in the marketplace. Some startups and developers may take this thinking overboard and put products on the market that are so stripped down as to not be viable, but I think that the concept of a true MVP sums up the entire purpose and challenge of Product Management.
A true MVP must strike the balance between feature bloat and watered down junk, driven by a vision of what users need as opposed to what they think they need. Such vision requires a lot of insight and a lot of courage. Imagine being the PM that decided the iPhone was ready to ship without support for copy and paste. Is copy and paste an important feature for a mobile phone? Obviously. Was it necessary for the product to be viable in the marketplace? Clearly, it wasn't, and that is why determining a feature set for and MVP is such a challenge.
A true MVP must strike the balance between feature bloat and watered down junk, driven by a vision of what users need as opposed to what they think they need. Such vision requires a lot of insight and a lot of courage. Imagine being the PM that decided the iPhone was ready to ship without support for copy and paste. Is copy and paste an important feature for a mobile phone? Obviously. Was it necessary for the product to be viable in the marketplace? Clearly, it wasn't, and that is why determining a feature set for and MVP is such a challenge.
From a Product Management standpoint, this is good advice.
But what do you do when you're a software developer who sees these problems but have your hands tied by management?
But what do you do when you're a software developer who sees these problems but have your hands tied by management?
It depends. I found myself in that situation and just started doing the job, but this requires your boss' approval, since it will take time away from coding and cost money. To do this, you have to have a current gap in product management (as opposed to PMs making bad decisions). This was my path into product management.
If you can't get your boss' approval or there is existing product management, you can try sitting down informally with them. Explain your concerns, but be tactful (this part is hard for many engineers who are completely data driven). You have to be careful not to get people defensive. Go in with an attitude of "I see this as suboptimal, teach me why I'm wrong" instead of "You're an idiot, you should be doing this thing instead". Make sure you are being objective, though. I've had engineers fight me on what "should" be done because they were only looking at technology instead of the whole business.
If neither of those work, you are probably going to get frustrated quickly. Few things did more damage to my team's morale than feeling like they were working on something useless.
If you can't get your boss' approval or there is existing product management, you can try sitting down informally with them. Explain your concerns, but be tactful (this part is hard for many engineers who are completely data driven). You have to be careful not to get people defensive. Go in with an attitude of "I see this as suboptimal, teach me why I'm wrong" instead of "You're an idiot, you should be doing this thing instead". Make sure you are being objective, though. I've had engineers fight me on what "should" be done because they were only looking at technology instead of the whole business.
If neither of those work, you are probably going to get frustrated quickly. Few things did more damage to my team's morale than feeling like they were working on something useless.
Step 1: Ask your product management folks: "What's the thinking behind X?"
Step 2: If you know a better way, propose it to them and build consensus to make your idea happen.
Step 3: If the company is on a bad trajectory and step 1 or 2 don't make you feel better, find somewhere where that isn't the case.
I've been a product manager for 5 years or so now. It amazes me how many devs have bad product manager experiences. Because of mismanagement, you're probably spending 30 - 100% of your time doing wasted work. Im sorry.
Step 2: If you know a better way, propose it to them and build consensus to make your idea happen.
Step 3: If the company is on a bad trajectory and step 1 or 2 don't make you feel better, find somewhere where that isn't the case.
I've been a product manager for 5 years or so now. It amazes me how many devs have bad product manager experiences. Because of mismanagement, you're probably spending 30 - 100% of your time doing wasted work. Im sorry.
"Well thought out features that deliver value, even if they take a bit longer to come to market, will (in my opinion) deliver more ultimate value to the product and to the user experience."
The important thing to notice there in the quote is that there are two steps to "delivering more ultimate value".
The first step is more thought. Well obviously. No-one is saying slap any load of crap down and expect someone to pay for it.
The second is "that deliver value". This appears to be the one most missed by people, in my experience, and is the raison d'etre of MVP. If the market doesn't exist and if you aren't solving a genuine problem that you can both communicate and be delivered economically then it doesn't matter how much you "think".
This is why MVPs are important: an empirical guide to work out what should be done, not sitting at your desk pontificating with your wise-ass rationalisations, abstractions and reductions of human behaviour and reality.
The important thing to notice there in the quote is that there are two steps to "delivering more ultimate value".
The first step is more thought. Well obviously. No-one is saying slap any load of crap down and expect someone to pay for it.
The second is "that deliver value". This appears to be the one most missed by people, in my experience, and is the raison d'etre of MVP. If the market doesn't exist and if you aren't solving a genuine problem that you can both communicate and be delivered economically then it doesn't matter how much you "think".
This is why MVPs are important: an empirical guide to work out what should be done, not sitting at your desk pontificating with your wise-ass rationalisations, abstractions and reductions of human behaviour and reality.
Do startups actually need product managers? A few months back, a job posting for a designer at inDinero included a sidebar that asked this question. Jessica suggested that the answer was "No".
It seems that product managers are not required when a company is relatively small, and a co-founder has the bulk of his/her time to dedicate to product development. In such a case, a team need be made up of only engineers and designers.
Even when teams are larger, new-ish web application frameworks like Rails make deployment incredibly easy/fast and all of the "strategic thinking" that a PM might ordinarily contribute is done with live product. In these situations, all of the activities listed in Joseph's blog post - focus, vision, avoiding frankensteinism, customer-centricity - could be handled by a product designer or product-minded engineer.
Are product managers a thing of the past? Seems increasingly likely.
It seems that product managers are not required when a company is relatively small, and a co-founder has the bulk of his/her time to dedicate to product development. In such a case, a team need be made up of only engineers and designers.
Even when teams are larger, new-ish web application frameworks like Rails make deployment incredibly easy/fast and all of the "strategic thinking" that a PM might ordinarily contribute is done with live product. In these situations, all of the activities listed in Joseph's blog post - focus, vision, avoiding frankensteinism, customer-centricity - could be handled by a product designer or product-minded engineer.
Are product managers a thing of the past? Seems increasingly likely.
inDinero has what, five employees?
As teams grow and the scope of what they do grows, the need for specialization also grows.
Let's assume a wonderful team of world-class engineers who all happen to have the same skills as a world-class product manager, and who all like product management work. (If you like, they can all also be world-class designers.)
In my experience, pure product management work grows pretty linearly with the number of developers. (Providing they're organized, more developers means more projects or increased velocity on existing projects. Either means more product work.)
In this situation, each developer could spend X% of his time on product management work. (Let's say X% = 10%, since in my experience one product manager can keep ten developers busy.)
Great, you might think. Since every one of these developers can do and likes to do product management work, they'll each devote 10% of their time to it, and everything will work out fine.
There's only one problem with that - great products aren't built in small isolated portions. In order to be an effective product manager, you've got to know the whole product - so everyone doing any sort of product work has to coordinate with each other. As the team grows, so does the coordination overhead.
Even assuming a perfect central repository of knowledge (an uber-wiki?), so each developer only has to do a knowledge dump once, just consuming and synthesizing all the information created by all other people takes an increasing amount of time. And then there's the need to reach consensus when people's syntheses disagree, as they invariably do.
In these situations, as the team grows and/or the product gets more complex, someone inevitably ends up spending an increasing amount of their time on product, while others stop spending any. Someone becomes the guy who makes product decisions, while others defer to that guy.
Perhaps, when the dev team is ten people or so, that product-focused person's still spending a bit of time coding, and still calls himself a developer. But as the team grows, it's inevitable - you will either hire external dedicated product managers or you will grow them yourself from the inside.
As teams grow and the scope of what they do grows, the need for specialization also grows.
Let's assume a wonderful team of world-class engineers who all happen to have the same skills as a world-class product manager, and who all like product management work. (If you like, they can all also be world-class designers.)
In my experience, pure product management work grows pretty linearly with the number of developers. (Providing they're organized, more developers means more projects or increased velocity on existing projects. Either means more product work.)
In this situation, each developer could spend X% of his time on product management work. (Let's say X% = 10%, since in my experience one product manager can keep ten developers busy.)
Great, you might think. Since every one of these developers can do and likes to do product management work, they'll each devote 10% of their time to it, and everything will work out fine.
There's only one problem with that - great products aren't built in small isolated portions. In order to be an effective product manager, you've got to know the whole product - so everyone doing any sort of product work has to coordinate with each other. As the team grows, so does the coordination overhead.
Even assuming a perfect central repository of knowledge (an uber-wiki?), so each developer only has to do a knowledge dump once, just consuming and synthesizing all the information created by all other people takes an increasing amount of time. And then there's the need to reach consensus when people's syntheses disagree, as they invariably do.
In these situations, as the team grows and/or the product gets more complex, someone inevitably ends up spending an increasing amount of their time on product, while others stop spending any. Someone becomes the guy who makes product decisions, while others defer to that guy.
Perhaps, when the dev team is ten people or so, that product-focused person's still spending a bit of time coding, and still calls himself a developer. But as the team grows, it's inevitable - you will either hire external dedicated product managers or you will grow them yourself from the inside.
Startups absolutely need product managers if the founders don't have that skill. PMs have spent years learning how to understand the market and find where a product fits. Most founders don't have that experience so a lot gets built by hunch and (expensive) on-the-job PM training. I've worked at quite a few startups, but I have yet to find founders who understand the things PMs print to the table. Instead, they muddle through it.
You have to be careful, though. A startup PM is different than a Fortune 500 PM. One understands how to build new markets, the other how to tap into existing markets.
You have to be careful, though. A startup PM is different than a Fortune 500 PM. One understands how to build new markets, the other how to tap into existing markets.
If the CEO can do double duty as the PM, then the startup does not need a PM. But I've seen startups where the CEO is constitutionally not a product person and the team was in dire need of a good PM to whip things into shape.
[deleted]
Product managers, not necessarily. Product owners, absolutely.
A small, product minded team can definitely handle many of the activities associated with product management. So can the CEOs of early stage startups. Dropbox, facebook, and twitter all had founders focused on the vision, avoiding frankensteinism, customer development etc.
But this all changes as a company matures and as the product becomes increasingly more complex and multi-faceted. Larger development teams (~15-20+) often start working on specific product features. The company may have numerous external partners, customers, and users that influence the direction of the product. The CEO's time may shift from promoting/enforcing product vision to more 'CEO' type activities (e.g fundraising, PR work, analyst briefing). A product manager can be empowered to align the company's resources with the product vision.
A small, product minded team can definitely handle many of the activities associated with product management. So can the CEOs of early stage startups. Dropbox, facebook, and twitter all had founders focused on the vision, avoiding frankensteinism, customer development etc.
But this all changes as a company matures and as the product becomes increasingly more complex and multi-faceted. Larger development teams (~15-20+) often start working on specific product features. The company may have numerous external partners, customers, and users that influence the direction of the product. The CEO's time may shift from promoting/enforcing product vision to more 'CEO' type activities (e.g fundraising, PR work, analyst briefing). A product manager can be empowered to align the company's resources with the product vision.
Well I have come across really good UX folks that encompass both traits. I think it is less a question about job, but the role they play and skillset. A product needs a sherpa, no matter who plays the part.
Grammatical errors aside, I like the ideas represented here.
However I think the post would have more impact if it was followed up with concrete examples. Take MVP for instance, are there any known failure cases that would demonstrate why it's important not to rush half-baked ideas out the door? I certainly can understand how shipping bad functionality can create a huge negative opinion of a company and it's products. However, how do you convince others, especially your boss, that it's a bad idea? Explaining what might happen usually gets you nowhere, pointing out other disasters sometimes gets their attention.
This type of analysis could be performed on each of the 5 things and in doing so would make for a far more interesting read. As previously said, I like the ideas it just seems to be missing information that would make it feel complete.
However I think the post would have more impact if it was followed up with concrete examples. Take MVP for instance, are there any known failure cases that would demonstrate why it's important not to rush half-baked ideas out the door? I certainly can understand how shipping bad functionality can create a huge negative opinion of a company and it's products. However, how do you convince others, especially your boss, that it's a bad idea? Explaining what might happen usually gets you nowhere, pointing out other disasters sometimes gets their attention.
This type of analysis could be performed on each of the 5 things and in doing so would make for a far more interesting read. As previously said, I like the ideas it just seems to be missing information that would make it feel complete.
Thanks for reminding me about the grammar, constant challenge :)
I have lots of examples, perhaps I will do a follow up on that. I will have to talk about most of those examples with a beer in hand, that is a prerequisite.
Joseph
I have lots of examples, perhaps I will do a follow up on that. I will have to talk about most of those examples with a beer in hand, that is a prerequisite.
Joseph
It's super difficult to find a startup PM at the beginning, partially because it's super difficult to find another person who has the same product vision. It's much easier for the founder with strong conviction to see the product through, at least to a stage where it's been proven by the market.
I think a lot of these points can apply to founders, too, and not just product managers. Especially in regard to the MVP concept, I think a great point is made here a lot of people mistake an MVP for an incomplete/half-working thing. This isn't always the case, though, it's more common to see that than it is to see fairly polished work being released. One of my all time favorite companies, Metalab, hosts a series of products that look and function like apps that have gone through rigorous iteration but in reality are on their first (sometimes beta) release.
Founders are, by definition, product managers, at least until they can hire a dedicated one.
I wish someone at Cisco systems would religiously enforces some of these standards. They consistently approach products at a minimally viable level and they almost always become frankensteins because of it. Just one of many reasons they've been in some financial hot water in the past few years.
The Frankenstein problem is huge. Look at the clutter on Yahoo versus Google. Absolutely captures the difference in focus and culture.
Frankenproducts are a sign of a bloated middle management that isn't willing to make a stand on win-lose tradeoffs.
Frankenproducts are a sign of a bloated middle management that isn't willing to make a stand on win-lose tradeoffs.
great post joseph, nice to get some perspective from the others side on the huge MVP trend.
I've had considerable difficulty with PMs in the past regarding the paradox between a&b. Lots of "wouldn’t it be cool if it could do this?" questions are answered by b, but an overzealous PM might say no, justifying against a...and it's easier to build justifications around feature bloat and that seems to be where lots of dev cycles are spent in most companies.
Ref: see Microsoft vs. Apple's approaches.