If you want to be a bad product manager, treat product development as a democracy. Give everyone an equal vote in all decisions. You are part of a team after all, right? What kind of team would it be if people were excluded from certain decisions? When considering new features for your product, let all of the engineers and marketers and salespeople vote, and start working on the feature with the most votes. Let customers vote, too — you’re building the product for them so they deserve this opportunity.
If you want to be a good product manager, rely on leadership rather than voting to drive product development. Of course, product managers can not and should not be dictators, and there are many things product managers must do to engage and utilize the entire product development team, like selling requirements to development and involving others in creating product plans.
However, product development is not a democracy. There is no voting, and if there was, not everyone would get a vote, and not all votes would be equal. While it may be tempting to structure an open process by which stakeholders have the opportunity to provide input and are given a level playing field, this is really an illusion and a disservice to the product manager. If everyone gets an equal vote, then why have a product manager at all? All you would need is someone to tally the votes.
The product manager role is especially crucial when there is differences of opinion about aspects of the product. The product manager must step in to make decisions and lead the product development team in the right direction, whether it is setting the long-term strategy for the product or resolving an implementation detail.
This is not to say that the product manager has ultimate authority over everything in the product — quite the contrary. In most aspects of product development, while most people should have the opportunity to provide input, ultimately there is a person or group responsible for the decision and execution. You would not let an engineer vote on the name of the product any more than you would let a product manager vote on what database software the product should use.
Product managers are responsible for what the product should do; do not attempt to absolve yourself from that responsibility by pushing decision-making back on to the product development team or a wider group. Good product managers are able to get input from all of the relevant players and use that information as basis for decisions. Not everyone will agree with your decisions all of the time, but if you do your job well, your decisions should be understood and respected.
Translations available:
Great post. This is one of my biggest challenges when putting Product Management in place where it has never existed before. In a startup, you deal with 1) Founders, who have been de facto PM’s and making all the decisions, 2) Engineers/Developers, who have been working on the features they deemed important, 3) Marketing, who is demanding features because “the competition has it!”
If you’re introducing Product Management in place at a company for the first time, you have to walk a fine line. Even with great market data, you can’t appear to come in and dictate or remove people from the decision making process.
I’ve found that the best strategy to success is by putting the stakeholders in a room and using a guiding hand approach to drive consensus. You can break ties with market data, but the best trick is to use careful facilitation to lead the discussion in the direction you want it to go and make the stakeholders believe that they originated the “right” ideas.
I do this a lot, and if I had a bigger ego probably would be bothered by the co-opting of “my” market data, but if the right product gets built – who cares!
This post makes a lot more sense than the other one. Unfortunately there are many companies who prefer to give the authority of product decisions to others because they were ‘burnt too many times’ by product managers whose only crime was to drive the development of a marketable solution.
As I stated in another post, I recently left an organization — but neglected to mention that the CEO told me before I joined that the company had issues with their previous product managers – from what I see now, the only issues they had were based on the fact that these managers wanted a viable solution and wanted to develop a comprehensive application which engineering did not have the ability nor desire to build.
Given 20/20 hindsight, I would probably not have went to work there, but you live and learn — all I know is that if you give engineering that much power regarding development, you know that your product will not survive…
Sometimes companies tend to survive in spite of themselves… this was one of them – hope that no one has the misfortune of having to deal with this sort of chaos… but I am sure people will.
I was sent this post by a team member, who is a Product manager. We do a lot of voting here, and our team is constantly debating on what features to implement, and what fixes are the highest priority.
At first when I was reading this, I though that we were violating some golden rule or Product Development, but there is a huge element that should be highlighted.
In a start-up environment, when you have no customers, a collaborative effort is best, since you are relying on talented, educated professionals and their opinions to get your product to market.
When you have customers, they are KING and there should be no voting at all. You are only in this business to attract and retain customers, and everything else on the fringe will only distract you. So never let a team vote on a feature that looks cool, but no customer will ever use nor have they ever requested. Give them what they want!
Now, when your a start-up and you have no customers, there is no single point of reference that you have to determine if your on the right path, so you should rely on the team of professionals and their opinions to make a good judgment. Thats why you hired them in the first place, right?
I also do agree that the Development and Engineering teams often have too much power and start to direct what they will build and when, instead of being focused on the right plan. But in all apsects, Testing, Sales, Development and Service, – keep a mindful eye on what the customer’s needs are – since a great product that nobody will buy is actually a piece of crap.
And if you don’t have any customers yet? Well, I would say that you need to rely on the team that has given up a significant portion of their careers and lives to keep the vision on this product going, since they have the most vested in it’s success.
There are good and bad times to allow a ‘vote’ on anything. When the feature team is sat around together considering possible implementation options, which themselves all fall inside the original requirement (use case), then its not unreasonable to ask for a show of hands for a particular widget and how its put together.
But generally, the Product Manager must wear the hat of the “Customer Representative” and therefore must also have the ultimate say on key decisions in terms of the what (though the ‘how’ they should try to stay out of unless they want to act as some sort of uber development manager).
More recently, with the uptake of Agile methodologies (e.g. Scrum), we find ourselves faced with this very task much more explicitly. There is a role called the Product Owner, which is seen as part of the development framework, but where the custodian has to have enough customer / market / requirement savvy to make key decisons on each iteration (read: devt period) and set of “stories” (read: small requirement)…. what’s really interesting about this is that the new “Product Owner” role inherits a lot of the responsibilities of the product manager (in reality), but there’s a PO for each scrum making the need for this skill much more widespread in the dev organization than ever before. Whereas a ratio of 1:20 or 1:50 even 1:100 might be acceptable from a PM:DevHead beforehand, this pulls right back in to the lower end, you need one PO for each 5-9 person scrum; not necessarily full-time, but pretty regular.
Interesting that even the latest methodologies are making a tacit admission that the PM function (irrespective of the term they use themselves) is pivotal and possibly more important than ever before.
Slight digression I realise, but it suggests to me that even enlightened corporates are not looking at a democracy here, they are looking for leadership.
Yes, product management usually is introduced after version 1.0 is shipped. Yes, version 1.0 was created by developers without any input from customers. But, thinking that developers considered customers is long on odds.
The initial desktop publishing applications positioned text in inches and centimeters, not points. It was somewhere beyond version 3.0 before printers became the customers. The original customers were geeks, who of course, don’t have money and won’t pay for applications. So marketing had to point the software at a market with money.
When I was in the framework business, the developers thought that their customers were programmers like themselves. They thought that their customers could write their own framework. Maybe, so why would they buy ours and take the time to learn it. If they developed their own, they wouldn’t have to learn it, they would already know it.
When I worked for a code generation business, customers that called technical support to report bugs were called liars by the developers.
The technology adoption lifecycle says that you shouldn’t code without a client. A client isn’t a customer. A client is an intimate relationship that creates a lot more value than customers.
When you code for a client, you code the client’s product visualization, not your own. That client is your gateway to a market. If that client is a member of a vertical industry that has enough seats, and enough dollars, then your success is assured, provided you can meet that client’s needs.
Some things we are taught in school run contrary to meeting the needs of a large collection of customers. Requirements elicitation will lead you to functionality that can only meet the needs of the statistically artificial average customer. That functionality will be good enough, but not particularly outstanding or fit. Later in the product lifecycle this lack of fitness becomes a larger issue. But, the developers will not see the need. They will not see that users work in a meaningful world, and that meaning is messed up by software. Users are members of a subculture, not a statistical market segment.
I’ll take my best practices from my best employer. We didn’t vote. The product manager wrote the spec. The spec was turned into product. The product manager made timely decisions, so we could turn the spec into product. The VP of Dev ran dev. The product manager held a teamwide meeting each week. Then, he went and dealt with product aspects beyond dev. He wasn’t the boss. We were all operating in a matrix organization. The spec was sacrosinct. He controlled the spec.
You need not be a democracy, but then you need not be a totalitarian form either. The best bosses enable their people to make them into a hero. Enablement beats control in either its democratic or totalitarian forms.
The best bosses make their people into heros as well, and this without necessarily guessing about what customers want.
I wanted to go a bit deeper on this subject, so i wrote an article about this as product manager at Yahoo! I would love to share it with you.
http://gregorytalon.blogspot.com/2008/12/product-development-is-not-democracy.html
Note that I’m french so there might be some spelling and grammar mistakes 🙂
The population of a given country has a preference for difference to hierarchy, so employees from different countries expect different degrees of top down direction.
n the U.S., project managers do not have authority over the people working on their projects. They may have a feed into evaluations, and they can get people off their teams if need be. But, they can’t get people on their team if those people don’t want to work with him.
The same is true of product managers. The people that work with a product manager answer to a functional unit manager, not the product manager. They tell you their dependencies, they ask you questions, they ask you what you want, and if they are voting yes, they try to get it for you. But, even if they don’t, you are still responsible for the product. They are not. You are the middle of the oreo.
At some level, every employee votes every single day. Being a charismatic leader that pays attention to those dependencies, and enables their people will get that product manager what they ask for. Being a dictator will get you next to nothing.
The reason product managers tend to be technologists, is because development expects the technical product manager to be aware of their point of view and to stay out of their way. They voted even before you showed up. Get in their way, and they will vote again and again. You will end up going to the ops committee about slips and quality problems again and again.
Lead, enable, or get out of the way. I can vote. I can find the door after one phone call. I definately vote.
Actually, if you do what an uninformed project or product manager asks for, you functional manager may fire you, because you look incompetent even if you bent over backwards to give the uninformed what they imagined. Sometimes, I can’t do what you ask. You’re a generalist, and I’m the expert. That is where this particular problem starts. It ends with me voting with my feet.