If you want to be a bad product manager, try to get everyone to agree on features. It should be easy to get all of your various stakeholders to agree on what features the product should have. If you can’t get them to agree, how are you going to have their support for anything you do? Sure, everyone has wildly different ideas about what the product should include, but it shouldn’t be too hard to come to agreement in a meeting or two. It’s your job as a product manager to make sure everyone is okay with the things that you’re adding in to your product.
If you want to be a good product manager, get everyone to agree on goals. Even with just a few different people involved in the creation of a product, there will be divergent views as to what the product should include. Each person will likely have their own “pet” feature that they would like to see included. Their desire may be for a legitimate reason, like a customer support representative lobbying for a change that would reduce unnecessary support calls or a business development manager asking for features to help get certain partner agreements finalized. However, often features are requested for less legitimate reasons, such as a developer wanting to try an implementation of some cool new technology or a marketer demanding a certain feature just because a competitor has it.
It will almost never be possible to include every request in the final product because of time and resource constraints. Even if it was, this would likely cause the product to become overwhelmed with unnecessary features and complexity and lose focus.
Similarly, getting all of your stakeholders to agree on the features is virtually impossible, and even if it was, it would require an unwieldy amount of effort. Product managers — not a committee of dozens — are responsible for defining what goes in to the product. If a product manager is just tallying votes from others, then what value are they adding?
These problems can be avoided by getting agreement around the vision, strategy, and goals for your product. This may be challenging, as stakeholders who are familiar with just submitting feature requests may resist this change. One way to make the transition is for product managers to spend time with others to understand the underlying goals behind their requests.
For example, a salesperson who keeps asking for 802.11g support is not mentioning this because it is her own personal desire to have 802.11g support in the product. Likely, it is because she is getting requests from customers for this technology or potentially has lots sales because it is offered by competitive products. Instead of just adding this feature to the list of future enhancements, use this as an opportunity to clarify the goals — whether they be around market share, revenue, number of customers, type of customers, or even broad areas of functionality. Maybe she is losing out on sales because she is targeting customers that are outside of your core market, and those in the core market do not desire 802.11g support. Maybe your goal for the next year is to improve battery life and adding 802.11g would hurt battery life. Ensuring that you and she and all of your other stakeholders are in agreement on the goals will make it easier for you to make the decision as to whether 802.11g support will best help meet that goal or whether your efforts should be put elsewhere.
An added benefit of focusing on goals rather than features is that it will show your stakeholders that you have a strong command of the product’s direction and that the product is in capable hands. Stakeholders are more likely to strongly demand specific features when they are not confident in the management of the product. Showing that you can manage the product well by defining and aligning the vision and strategy will increase others’ confidence in you and your ability to be a successful product manager, allowing you to spend more time collecting ideas from others than trying to get everyone to agree on them.
Translations available:
Hi Jeff – along this line of thought, what do you think about having releases around a particular theme. We face many of the issues you talk about above where every stakeholder has a set of features they think are high priority. We do a pretty good job of triaging these and coming to some level of agreement, but it still makes for a very reactive type of release. We are constantly struggling to keep up with the requests for any new releases.
I’m thinking about going to themes. For example, the next release will have the theme of usability, where we take our usability/UI studies and information and tackle all or most of them in this next release. The release after that might be around security where we focus on that. Obviously, other P1 things can go in, but the bulk of the new enhancements are around the theme of the release.
I’m not sure I agree with this, but that might be a misunderstanding…!
I struggle to accept the “If you want to be a bad product manager, try to get everyone to agree on features.”
If you haven’t got an agreed feature level statement of requirements when you start, your project is liable to be interpreted differently by the development teams. Everyone has to be on the same page or each department will add in their pet projects to the work they do. Working at a goal level leaves too much wriggle room – and in a project that means downstream scope creep.
If you mean (as you perhaps imply later) that you shouldn’t just collect everyone features and stuff them all, then I do agree. Whittling down feature requests into confirmed features for development is where this issue needs to be tackled – upo front and head on, explaining to those doing the requesting that they can’t have it (or it must be modified) because of x, y or z.
I also disagree that “It should be easy to get all of your various stakeholders to agree on what features the product should have… it shouldn’t be too hard to come to agreement in a meeting or two”.
This is the hard part of the project that takes time to get right, but also the part of the project that makes the rest follow.
Kent — Grouping releases around certain themes is a great approach. It helps define the scope for your internal team — so you don’t get scope creep — and is good for marketing purposes to communicate to your customers.
Jeremy — Good point, and this is where the “bad/good” format sometimes doesn’t let me be as clear as I should be. “Agreeing” on features can be interpreted two ways:
I was writing that you shouldn’t “try to get everyone to agree on features” and thinking of 1, and I can see how you were reading it and interpreting it as 2.
My point was that the product manager is ultimately in charge of what goes in the product. You’re never going to get 100% agreement from every stakeholder (which is different than team member) on every single feature. So, product managers should focus on getting the stakeholders to agree on goals, giving the product manager leeway to determine what features best meet those goals.
Also, when I wrote “It should be easy to get all of your various stakeholders to agree on what features the product should have… it shouldn’t be too hard to come to agreement in a meeting or two,” that was the bad product manager writing. The first paragraph is always what a bad PM would do, and the rest is what a good PM would do. I can see how it’s confusing, though, especially for newer readers. I’ll see if there’s a way to make it more clear what is “bad” and what is “good.”
Does that clear things up?
Hi!
this is very intersting reading and hitting right on the sweet spot for my team…
All this is sensible, and particularly the get stakeholders to agree on goals part. Also I believe in the release by theme kind of approach, I would like to test this approach within my team.
However, how do you handle revenue conflict there? I mean often times what you put in your product should somehow generate direct or indirect revenues. So how do you get your teams and marketing to focus on the goals and theme of the release when the feature they push, which usually requires a lot of effort and resources is:
1) either totally out of the scope but can generate important revenues, as it’s been sold already to the client?
2) it is very desired as it can improve efficiency (read save operating costs) and it improves the scalability of your growing business, but you know it will not generate any directly visible revenues, so it will constantly pushed back in low priority because of items of point 1 above?
Great comments and questions, Chiara. I’ll try my best to answer, though you’ve raised two issues that are bigger than just trying to get people to agree on goals and could easily be fodder for future topics here:
1) The question I would ask is why these features have already been sold to the client? This is probably enough to be covered in several different separate posts, but if sales is dictating what should go into the product because they promised things to customers that they shouldn’t have, “focusing on the theme” is not going to solve that problem.
2) I would question who is causing it to be “constantly pushed back in low priority”? Is it you as the product manager? Is it engineering? Sales? Marketing? If the “theme” of a release is “saving operating costs,” how are these features being pushed back? Or is the problem that you can’t get agreement on the fact that the theme should be “saving operating costs”? Again, this may be a symptom of a bigger issue, which gets in to organizational dynamics and culture and a number of other issues.
Without knowing more about your specific situation, I can’t give any more specific recommendations, only that it sounds like the product manager is not really making the final decisions about what goes in the product. Sales is promising clients features and then telling the product manager to deliver (1), or the product manager wants to include features to improve efficiency but someone else is putting pressure on him/her to focus instead on features that will directly drive revenue (2).
The solution to both of these is to clarify the role of product management, come to an agreement about who makes the decisions about what goes in to the product, and establish the product manager as the true “president of the product” — which is all of course much easier said than done.
Jeff – I think an article on developing “special products” for individual customers would be very interesting. I’m a consultant now “on the outside looking in”, but what I was on the inside this was a common theme for the B2B sales teams.
What we tried to do was evolve a process of “standard specials”, whereby the common themes in a number of special products could be drawn together into a standard framework. At the same time we ran a special sales request much like a streamlined PD project and prioritised it alongside the other ideas it competed with for resource-time.
The trick we found was to make the fully developed product flexible enough to cope with customisation, while at the same time educating the sales force on how to align a set of customer requirements with those flexible deliverables.
When we (PM) were dragged into meetings with customers, it was relatively easy to move the customer to align with what we offered. Often though, when salespeople went in by themselves they would come back with just the customer’s strawman and we would all be on the back foot. What we had to do was educate so that sales would actually sell what we had rather than acting as a conveyor belt for what we did not, so to speak…
I think clarifying the role of PM as the president is political dynamite and can probably be more effectively achieved by exhibiting expertise than by asserting it 😉
Hi Jeff,
A lot of interesting points – both from your article and the comments – I think a lot depends on type of
organisation the Product Manager is operating in and the stakeholders s/he has to work with. After agreeing
on goals it may be good practise to get agreement on the features that will support those goals – failure to
do so may result in sales and/or business development not being committed to sell the product. It would not
be the first time a good product failed beacuse the sales team didn’t understand – agree – or like the
product or feature set 🙁 I think one way to approach the situation is to ensure that the product
managers get the right balance of activities (strategic and tactical) on a day by day basis. Read
What is the job of a typical on-line Product Manager? . for more deatils on getting the right balance .
Derek
From a practical, in-the-trenches perspective, I strongly agree with the thesis in this post. I might throw in the importance of fulfilling use cases as part of the goals, but that’s just a quibble.