Chapter 18
IN THIS CHAPTER
Setting a foundation of persuasion strategies
Selling executives on your ideas
Working more effectively with engineers
Arming and leveraging your sales team
Persuasion and influencing are the skills where the rubber meets the road as a product manager. You can do all the excellent work to create a great product strategy and a credible plan, but if you can’t get others to support your efforts, you won’t succeed. Because virtually all product managers are individual contributors and the people they depend on to deliver products don’t report to them, being able to influence without authority is a critical link to your success.
This chapter gives you solid tips on how to be your best persuasive self as well as how to specifically influence the executive board, your development team, and the sales force.
The foundation of persuasion as a skill is knowing what outcome you want to achieve and then putting together your best arguments and communicating them as effectively as possible. In this section, we cover three core basics of effective persuasion: active listening, convincing, and asking for what you want. Master these tools, and you’re well on your way to getting the end result you want.
Before you can find a solution, you first need to have a deep understanding of the situation. Active listening is a very popular and highly effective technique that helps you get a handle on another person’s point of view. When you’re trying to influence a team member regarding a new product, you need to be able to listen first and speak second. Also, using active listening can diffuse challenging situations where others are insistent or argumentative. Many times conflict arises simply because the other party doesn’t feel heard and doesn’t believe that you deeply understand its point of view and opinions.
To practice active listening, do the following:
Allow the other person to talk and state his complete case.
Don’t cut him off or try to respond. Let him speak his piece so that he has been able to voice everything he needs to. If he talks a long time, give him verbal cues like “uh huh” so he knows you’re still listening.
When he’s finished, say, “It seems that…” or “What I heard you say is…”, and then repeat back what you think you heard.
If you got it right, he’ll automatically respond with “yes.” If you didn’t get it right, he’ll correct the part you missed or even say “no.” If you’re the least bit unsure about whether your understanding is correct, ask him whether he feels you have an understanding of his point of view. If you don’t feel comfortable paraphrasing what he just said, simply repeat the last three words.
Deep down, the need for active listening is only partly in making sure that you understand the facts. Acknowledging the feelings behind the argument is equally or maybe more important. Here’s the difference: “I hear that you want to go to the store.” Fact, no feeling. “I hear that you’re frustrated because you want to go to the store and can’t figure out how to get there.” Practice the second kind of response.
Repeat Steps 1 and 2 as necessary until both parties are convinced that you thoroughly understand the other’s point of view.
If you hit a wall in this process, you may need to ask open-ended questions to get more insight from the other person about what you’re misunderstanding. Try starting your open-ended questions with “what” and “how” for more informative answers.
The interesting thing about active listening is that after going through this process, you often don’t need to explain your point of view to the other person. When he feels heard and knows that you understand (but don’t necessarily agree), he may drop the subject altogether. And sometimes when the other person believes he’s been heard, you can let him know that you now understand and will factor his opinion into the decisions you make about the product.
After doing some active listening to get the other party’s point of view (see the preceding section), you may still need to do some convincing to sway him to agree with you. One of the simplest and most effective methods is the three reasons method.
Here’s how it works for a conversation that you plan in advance:
State what you believe should happen and that you have three reasons.
Plan out your three reasons.
Provide your first reason, using any data or real-world examples you have.
Use as many facts as you can because facts and data are difficult to argue with.
Repeat Step 2 with your second reason.
Again, use facts and examples wherever possible.
So why does this method work so well? Regardless of whether you have a well-thought-out argument upfront, using this approach gives the other person the impression that you’re confident about what you’re saying. Anyone who claims three good reasons for an opinion most likely has a reasonable stance to argue, so declaring you do puts you in a strong position right out of the gate. Does it work every time? No, but if you aren’t able to come up with three reasons your opinion and argument are right, you may need to rethink your position in the first place.
One of the keys to getting people to listen to you (or read what you have sent) and then do what you ask is to keep things as brief as possible. For example, if you need to influence your team to change the schedule to add a crucial new feature, having a long conversation or writing a three-page email stating every reason you can think of simply won’t work. Chances are that your audience will tune out after the first minute or no one will read the entire email. Instead, your information will simply be ignored or dismissed.
In all your communications, be as short and to the point as possible. In emails, use bullet points if possible. Many times, your response to an email can simply be one or a few words, such as “Agreed” or “Approved.” In fact, short communications can, in many cases, be more effective than longer ones. Product managers who go on and on endlessly, whether via email or in conversation, tend to be far less effective than those who can get their points across rapidly and efficiently.
Figure 18-1 outlines a good method for concisely presenting your case to get what you want. You sketch out the situation in a few sentences, give a few pieces of vital information to make your argument, and then clearly tell the other party what you want and why giving it to you is good for both sides. The key to this method is to not try to present a long, drawn-out case. Make any communication short and compelling.
As a product manager, your ability to influence executives, sell them your ideas, and get them to back you up is critical. Often, executives don’t know the ins and outs of the market or the intricacies of a product. It’s then your job to build their confidence that you’re a product and market leader, and that your understanding of the right strategy and execution is going to help them succeed.
One tool to use when influencing executives (and other stakeholders) is an influence map, as shown in Figure 18-2. An influence map helps you determine who is on your side and how much they can help or hinder your efforts. An influence map can also give you a sense of what kind of politics may be going on behind the scenes so that you can build the relationships and have the conversations you need to ahead of time to get support for your efforts.
To create your influence map, list all the executives who have any influence on your work. Map them into how supportive they are for your product efforts and then how influential they are in the organization. You are looking for those who have a lot of influence and are very supportive. Target your key influencers with more information and ask them to support your cause with other executives. For executives with lots of influence who don’t support your product efforts, list issues they consider to be more important and then how you can link your product to their key interests and goals. Enlist executives who are on your side to take up your cause with the others who don’t support your cause. Use the relationship building techniques in the next section to explore resistance to your product ideas and build as much positive perception of your product at the executive level as possible.
In rare cases, every (or almost every) executive is mapped as not supporting your product efforts. If you don’t have the support you need and you don’t believe you’ll be able to change the situation, your best bet may be to move on to a situation where you’ll have a better chance of success. For example, if the CEO or several senior-level executives don’t believe in your product or strategy and aren’t willing to fund it, you’ll have an uphill battle as the product manager. The alternative is to remain on the job and become frustrated and negative, and that is truly career limiting.
One helpful technique for influencing executives within the organization is to determine the top five key players that you’ll need support from. Fostering relationships with these people early on, without any agenda, is important. By getting to know them on a personal level while showing them that you’re the market and product expert, you’ll be setting yourself up so that when you do need support in a critical situation, they have confidence in you.
Building these personal relationships is also a great way to help move your career along. Find out what the executives are interested in and what motivates them. Take them to lunch or stop them in the halls to ask their advice. If you can, get them to agree to be your mentor. These steps all seem like common sense, but the product managers who succeed actually follow through with doing this stuff.
Here are a few ways to build rapport:
In order to influence executives, you have to learn how they think and speak their language. For example, product managers are often very interested in the minute details of how their products work. They have to be in order to make sure they deliver a polished product that delights customers.
Executives, however, don’t generally know or care about the in-depth details of product features. They’re much more concerned with the big picture and things like how to accelerate the growth of the business and whether they’re allocating resources the right way to maximize the company’s return on investment. Thus, presentations for executives that have 20 (or more!) slides about the details of the product will lose their interest (and hurt your credibility). Keep things short, sweet, and focused on what they care about.
Being able to influence and work effectively with the development team and individual engineers is a huge part of whether you’ll be successful as a product manager and satisfied with your job. Your success depends on your ability to get your engineers to build the product that you believe meets customer needs and moves forward on your vision.
Credibility in product management is everything. Your challenge is going to be to build credibility despite what development considers your role to be or not be. You need to show engineers what you’re doing and why you’re doing it and make sure they view you as an expert in a range of areas. Areas to show your credibility in include the following:
Technical: Establishing yourself as a technical expert with your development team members is absolutely critical. Otherwise, they simply may not respect or work with you. Your ability to influence them will be negligible. Follow the trends in your area of technology and know the acronyms and terminology. You don’t necessarily have to be a complete expert and understand all of the underpinnings of the technology, but you do have to prove to your team that you have the ability to understand. Check out Chapter 2 for more details.
If you don’t have technical expertise in your new area of responsibility, ask a lead engineer to brief you on the product. It is common to have an engineer brief a product manager on technology topics, so don’t be shy. At each stage, remember to look for the customer significance of each of the technologies or features that developers are telling you about. Take good notes because you need to get up to speed quickly.
Product management: Everyone in your company — not just your engineering team — needs to view you as someone who understands product management inside and out. You wouldn’t want to hire a chief financial officer or an accountant if you didn’t know the candidate knew finance inside and out, and product management is no different.
Certainly, any training you can go through and any certifications you can get increase your credibility. If you become a certified product manager through the AIPMM (Association of International Product Marketing and Management), for instance, and you hang your certification in your office cube, your team will see it and understand that you truly have studied this discipline and are excellent at what you do.
Customer: You want to be viewed as the person who is the true voice of the customer. You’ll know you’ve established yourself as the real expert who has a finger on the pulse of the customer when your development team proactively comes to you to ask, “We can solve this issue this way or that way; which way do you think the customers will want it?”
To attune yourself to the customer’s needs, make lots of customer visits. Write up a summary of what you found at each visit. Include stories about what happened and information about the customer environment. Then share your report or email with your development team. Do this for each and every visit summarizing information into bullet points where possible. Continually bring up the customer in your conversations to remind engineers that you’ve spent significant time with them.
Another good tactic is to occasionally bring your engineers along on customer visits. Taking them out in the field and having them observe what kinds of questions you ask and what environment your customers work in is always extremely valuable. For example, one engineer saw a customer actually cry when faced with a difficult-to-use test interface and adapted it overnight for the next round of customer feedback. When engineers meet real customers, they share their experiences with their development team back at the ranch, and it becomes a lot easier to get the team to adopt your ideas later on.
You need to analyze the development team you’re dealing with and then adjust accordingly. You may have a great team or a difficult team that may or may not respect you (or anyone else who is a product manager).
In some cases, you’ll have a great team where you can easily establish yourself as a leader. When you’re in the upper-right quadrant of Figure 18-3 is when your job in product management is really, really fun.
If you’re in either of the check-marked quadrants, you can definitely make it work and can move toward the upper-right quadrant. In most situations, that’s where you’ll be as a product manager. Brainstorm with the team or your manager about how to move toward the upper-right quadrant by building teamwork and increasing your respect within the team.
In the worst case, there’s nothing you can do with some teams and situations. You may be in that bottom-left quadrant, and you may seriously need to think about whether you want to move on to a different product or move to work with a different team. Before you utterly give up hope, talk to the team’s manager (or HR, if the manager is part of the problem). See whether a coach can be brought in or whether HR can facilitate an intervention with the team to its improve relationships and internal workings. In some situations, there is simply no way to win. Don’t let yourself get stuck for a long time in one of these — it’s a career-limiting move.
Understanding the personalities of the individual developers and how to deal with each personality type is just as important as working with the development team as a collective unit. The following sections break down common developer personality types and give you tips on working with each.
There are three major types of developer personalities (see Figure 18-4):
Each developer personality outlined in the preceding section requires a different approach to achieve your desired result. Follow these tips to get the most out of each relationship:
Be less specific with prima donnas. For instance, when you deliver a market requirements or product requirements document or specify some features, suggest possible solutions instead of handing down the solution. Put a recommendation in that says “Customers need to be able to do the following. Here’s one way you can do it, but this is just an idea.” Let the prima donna solve it; in fact, challenge him to come up with a great solution. Ask prima donnas for their opinions and justifications. “Is this really the best way to solve the problem?” Play to their egos.
Your job in working with prima donnas is to make them hungry for real-world data only you can provide about customers and the market. And if you can present arguments such that they draw logical conclusions that they believe they’ve come to on their own, so much the better.
Be more precise with coders. Tell coders exactly what you need: “The following feature needs to be implemented this way. Come back with a design, and I’ll approve it.” Keep in close communication as they’re creating the solution and reassure them that they’re on track in delivering what you want.
The challenge here is that if you aren’t specific, you may end up with something very different from what you originally envisioned. You often find coders among remote development teams. Because distance increases their uncertainty, they’re afraid to make mistakes, and then work progresses very slowly. A great approach with coders is to write more specific requirements and then work very closely with coders to execute them so the coders don’t get too far down the wrong path. In an ideal world, coders grow up to be more experienced developers. In reality, they often move onto another job before they can build confidence in bringing their ideas to the team.
Building good rapport with your team is a critical component of winning over your development team. Otherwise, you can’t count on team members’ support when you need a favor in a difficult situation.
The key to creating real rapport is sincerity. You can sincerely develop connections in a variety of ways, both subtly and overtly:
When you really build rapport and get to know your team, you then have the ability to occasionally play a chip and ask for a change that may otherwise seem unreasonable. Done correctly and sparingly, using this leverage can be very effective.
A product manager’s sales team can be his best ally or worst nightmare. When armed properly, rewarded correctly, and enthused about your products, sales can make the difference between failure and massive success. In the following sections, we discuss many tactics for getting your salespeople on your side and enlisting their help.
Following are a few tactics that help make a salesperson’s job much easier. And if sales is happier, your job becomes that much easier. Keep these factors in mind as you work through how to structure your product for sales success.
The first tactic is to make sure you understand the motivation of a salesperson. Money and being successful in their position are key motivators for salespeople. Here are a couple of others:
Another tactic for leveraging your sales team is to be incredibly crisp and clear about “What’s in it for me?” or WIIFM. Make sure you can tell team members in less than one minute why focusing on your product is worth their while and why you’re making it easy to sell. Include info on how they can easily cross-sell and upsell customers with other products. Create opportunities to add on consulting, support, and other ongoing revenue streams. Convince salespeople that the solution is ideal for their customers. Then, when it’s sold, they don’t have to spend time fixing problems and instead can focus on closing new deals.
Make sure your salespeople understand who the target is and that they’re selling to the right customer. You want to paint them a picture about the size of the market and its potential for them so that they’re excited. Teach them about the buyers and the buying process so that they can be as effective as possible.
Give them the persona for the user, decision maker, and purchaser and tell them what the motivation is for each and why your product is a perfect fit. This information lets them understand the customer pain points and the motivation for purchasing. (Flip to Chapter 5 for more on personas.)
All your messages should be right on target. You have to have a compelling elevator pitch (that is, be able to explain the product in an elevator in ten floors or fewer). You need to nail your product positioning. You should be able to get it all across in literally 30 seconds — and teach sales how to do it in less than 2 minutes. Salespeople won’t be as concise as you are, and they also add in sales related language on top of your key selling points. Check out Chapters 10 and 15 for the best way to create these impactful statements.
Your sales tools (or the ones that product marketing creates for you) have to be simple and effective, and they have to make it incredibly easy for the rep to make the sale. If sales constantly asks you to be involved with customer visits or to provide additional information, you probably don’t have good sales tools in place. If you did, the sales reps would be able to tell the whole story without having to get you involved. For particularly complex sales scenarios, sales engineers get involved to bring in technical expertise. Your sales tools may never be technical enough for these folks, so plan specific technical training sessions for them.
Check out Chapter 15 for a complete list of sales tools.
One of the big challenges that product managers face is that sales reps generally have far too many feature requests that they consider urgent. They may have fallen into the habit of coming back from a customer site convinced that they could close the sale if the product just had features A, B, and C. You could simply ignore the request, but then sales may not work hard to sell your product.
Proactively share your process for capturing feature requests so that salespeople feel like their feedback is being taken into account and being put into the product planning process. Ideally, you’d set up a web form to get the details and the justification for the request, as well as the associated revenue and customer name.