How To Be A Good Product Manager

Tips on product management and product marketing for product managers. By Jeff Lash

Product development is not a democracy

Posted on August 22, 2007 by Jeff Lash · 14 Comments

Like this post? Help to spread the word...

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:

How To Be A Good Product Manager features tips on product management and product marketing, written by Jeff Lash (@jefflash on Twitter), Vice President and Group Director for the Product Management and Portfolio Marketing research and advisory services at SiriusDecisions.

Like this post? Help to spread the word...

14 responses so far ↓

  • Paul Young // Aug 22, 2007 at 9:06 pm

    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!

  • John Doe // Aug 29, 2007 at 1:44 am

    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.

  • Steve Cerqua // Sep 10, 2007 at 9:46 am

    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.

  • ’s blog » 9 11/26/2007 // Nov 26, 2007 at 3:41 am

    […] Product development is not a democracy: How To Be A Good Product Manager: Product management tips  Annotated […]

  • ’s blog » Unnamed 11/27/2007 // Nov 27, 2007 at 2:49 am

    […] Product development is not a democracy: How To Be A Good Product Manager: Product management tips  Annotated If you want to be a good product manager, rely on leadership rather than voting to drive product development. Good product managers are able to get input from all of the relevant players and use that information as basis for decisions […]

  • ’s blog » diigo 11/27/2007 // Nov 27, 2007 at 3:00 am

    […] Product development is not a democracy: How To Be A Good Product Manager: Product management tips  Annotated […]

  • Derek Britton // Dec 19, 2007 at 1:57 am

    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.

  • How do product managers prioritize requirements?: Ask A Good Product Manager: Your product management questions answered // Jan 21, 2008 at 5:39 pm

    […] I’ve known people who have tried scorecards, ranking systems, voting (see Product Development is not a democracy), but ultimately these are just ways to avoid the responsibility that product managers have to ultimately make the important decisions. […]

  • 产品经理们,遇到Bug请别十万火急 -- 三秒改变世界 // Aug 4, 2008 at 10:45 pm

    […] 如果迅速解决了问题,你可能会忽略问题的根本原因。在大多数时候,每个问题都有其根本诱因。在问题刚暴露的时候,诱因一般深藏不露,有很多的可能性。笔者认为,根本诱因最可能来自于需求确认阶段。多篇文章都探讨了这方面的问题,比如: Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems.If you fix the problem right away, you may not be addressing the underlying issue that caused the problem in the first place. In fact, in most cases, there is a root cause which is likely not visible on first glance. This applies to many areas in product management, most notably in addressing requests from customers. This has been discussed here in several different posts, including Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems. 同样,在产品管理的其他阶段,这个理论也适用。有些问题可以很容易就找到根本诱因,但产品开发的真正挑战来自各种不稳定的因素。例如,有时候一款漏洞百出的产品在上线之初,只暴露了冰山一角:一个很小的Bug,似乎十分容易解决。另一个例子,开发过程中,团队成员对各项功能的优先级有争议时,靠“民主投票”来做决策,而忘了引发争议的源头:对产品远景、战略及计划缺乏共识。 […]

  • 赢在产品 » Blog Archive » 产品经理们,遇到Bug请别十万火急 // Aug 5, 2008 at 2:13 am

    […] 同样,在产品管理的其他阶段,这个理论也适用。有些问题可以很容易就找到根本诱因,但产品开发的真正挑战来自各种不稳定的因素。例如,有时候一款漏洞百出的产品在上线之初,只暴露了冰山一角:一个很小的Bug,似乎十分容易解决。另一个例子,开发过程中,团队成员对各项功能的优先级有争议时,靠“民主投票”来做决策,而忘了引发争议的源头:对产品远景、战略及计划缺乏共识。 […]

  • David Locke // Aug 7, 2008 at 11:56 am

    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.

  • Gregory Talon // Dec 4, 2008 at 8:14 am

    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.

    Note that I’m french so there might be some spelling and grammar mistakes 🙂

  • David Locke // Dec 6, 2008 at 8:31 pm

    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.

  • David Locke // Dec 6, 2008 at 8:34 pm

    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.

Leave a Comment