Things a Good Product Manager Should Think About
jpuopolo.com
jpuopolo.com
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.
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.
But what do you do when you're a software developer who sees these problems but have your hands tied by 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.
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.
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.
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.
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.
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.
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.
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.
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
Frankenproducts are a sign of a bloated middle management that isn't willing to make a stand on win-lose tradeoffs.