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

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

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.

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?

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:

1. Everyone saying: “I agree that this is the right feature to be working on.”
2. Everyone saying: “I agree that this is the feature that we will be building, whether or not I personally think it is what we should be building.”

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?

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.

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.