What Techniques Do You Use to Deal With Other Managers Who Try to Change Your Product Vision?

Question

You're a product manager in charge of developing a new product, and you've done months of research to determine a direction and a vision for the product. The product development is going well, and now you've involved other departments, like marketing, graphics design, sales, and operations in order to create a support chain for the product.

As more managers of these areas get involved, many of them will have their own views regarding how things should function. For instance, you, as a technical person, may picture the development team implementing a new architecture that uses web services to bring custom API's to your clients and internal developers, which will help the other developers extend your product by using the services it provides. However, the marketing and operations personnel may view the architecture change as unimportant as they don't have the technical knowledge to understand how the new architecture could power other products built using that technology.

What you want is similar to what marketing and operations wants, but since they don't understand software engineering, they may not understand what the developers are working on. They then use their influence to convince others in the organization to skip the architecture development.

While it may be beneficial to include department managers in meetings -- instead of just the resources they've allocated to your team -- sometimes it's more difficult to control the direction of your product in these cases.

What tips or suggestions are out there for gaining support from other managers without necessarily having them take over the project with their influence?

Answer 1

I would answer your question as it was about "dealing with other managers" because "preventing others" would mean you do not want to hear other's oppinions and maybe lost some flexibility.

1. Sell the idea. It usually means you need to deal with each of the managers separately as each of them works in different area of expertise and is trying to achieve different goals. It also means you must find the time for proper explanation of concepts and planned functionalities. Making a big presentation of your strategy will be tempting as it saves some time (you don't need to explain all the details to each of them separately and it gives good impression when it's well done) but such "big bang" usually changes a lot less than expected. Consider selling the idea, piece by piece, by asking the questions: i.e.: "As regards the costs, do you think it is a good idea to let client's internal developers extend our product?" Find some interesting part for each of the managers and make them sell your idea. CEO might be interested in lower costs while the marketing manager may be interested in knowing that better architecture design and exposing it to client usually means less bugs and better quality.
2. Hear them. Whether you ask the questions or not, you will hear other's oppinions. It should remain clear for the disputant what your area of the expertise is and that it is your responsibility to make decisions, nevertheless the disputant should also feel she was heard, understanded and her input will be remembered and taken into consideration before making the final decision. Putting such feedback as the backlog items (as Rain suggested) is good idea because of visibility and it also assures you will...
3. ...Rethink your ideas. I find it not so rare to improve the initial idea after receiving some feedback. Other managers work with different clients so they can share their points of view for free (which you probably couldn't imagine even if you tried). If you improve your idea that way, take some time to thank the originator and inform you did a bit better thanks to her feedback. It's a win-win situation.

Answer 2

A huge part of a product manager's role is exactly what you describe. Sometimes the new suggestions or ideas are great, but sometimes you need to preserve the initial idea both to prevent delays and also to ensure the final product makes sense.

Depending on where the suggestions or new requirements are, I use different tactics, but here are some (Each with their own pluses and minuses):

• Put your foot down and be obstinate. Basically just have a stronger, louder opinion than the other person. (Not my favorite, but sometimes necessary. Don't overuse it)
• Keep people who will only meddle out of the loop (Sometimes dangerous, as people may realize what you're doing and take offense)
• Defer the discussion and the feature by agreeing that the new idea is a good one, and put it on the roadmap for a future release.
• As a variation on deferring the suggestion, point out that there is a deadline and that with the time and resource pressures adding things isn't an option.
• Explain why that idea doesn't fit in with the current product direction. If you can, use specific customer feedback to back up why you're right. (When you have the time, and the person is willing to have a real conversation this is almost always the best solution.)
• Build social capital in the organization. You can't do this overnight, but if you've been right before about other things and you are a trusted leader, you'll find far fewer suggested tweaks.

While not exhaustive, the above ideas are the main tactics I've found helpful in the past for fending off unworkable suggestions. In general, I find I have much better results with the "soft sell" and try to be agreeable and approachable by explaining my reasoning and deferring rather than rejecting ideas.

Answer 3

I came up with more strict answer to your question. I would treat it as "what not to do" answer but if you wish to get rid of the disputants you can try:

• Use Wally reflector. If somebody gives you an advice or suggesting a change ask him to write detailed document covering the subject
• Say "It's a good idea, in fact, it's a GREAT idea worth remembering". Forget about all of it after 10 seconds (my favourite CEO's answer)
• Switch the train to the secondary rails. Find some minor flaw in your opponents argument, stick to it and discuss only about it. After each slight change of the subject pick another minor element and stick to it...
• Say you already disscussed that (a couple of times) and came conclusion it's worthless. You do not remember the details but it doesn't change the situation, right?
• Buy a book on Eristics by Artur Schopenhauer. You will find some more examples there. "You do not have sufficient backgroud for conducting disscussions on such subjects." - is the universal one.

Answer 4

This is the challenge when you are running your own projects. Because you have a vision and you know your product inside out, it's harder to translate the vision you have into terms other people can understand. My suggestion is to take the time to translate what the developers are building into terms that describe the end result. That way Marketing and Operations can align their efforts with what will become reality.

Answer 5

The key is separating the user requirements from the technical delivery. You state that what you want is similar to what marketing and operations want, so it seems that the user requirements side is not an issue for you - you all want the same thing, more or less.

So, the real challenge is keeping the marketing and operations managers focused on the "what", rather than the "how". You have the technical ownership: they have some business influence. An approach that I have used successfully in the past is something like: "Let's not get into the technicalities of how this will be developed. I will deliver the capability to do what you want, and I will also give you some flexibility to add or change functionality in the future. Surely you don't want me to compromise on future capability just to save a few days just now, do you?" You may have to think of a couple of areas where they may want future changes, just to put this into context, but it does work.

Answer 6

Personally, first, I would prioritize what are the real needs that enable the customer to succeed vs what is the product vision enclosed in the company strategy.

Maybe indeed an API would help and is a superb technological advance, but does it really provide value today?.

There are many "frameworks" of prioritization or filtering, like WSJF proposed in SAFe. Moscow is another.

If you want to gain "approval" to do the technical functionalities, embed that into the "functional". Make sure that the functional is the goal, where the technical is the means to it.