ProductMarketing.com

Robin meets Kevin, the order taker

"There will always, one can assume, be need for some selling. But the aim of marketing is to make selling superfluous."--Peter Drucker

Kevin is the world's worst sales person and he's the bane of Robin's existence. It seems he calls her every day with a new request: a new feature, a new piece of collateral, a new sales tool, new demo. Can you call my customer? Can you check on this feature? Can you tell me when the next version will ship? Can you show me the roadmap? Can you drop whatever you're doing to support me?

Robin thinks that Kevin is an idiot. He doesn't know the product or the market; how can he be an effective sales person?

Robin should think of Kevin as a distributor rather than a fellow employee.

Assume sales people have little or no product knowledge. If you do, you'll create different kinds of sales tools, tools that do more of the heavy lifting so that the sales people don't have to know everything about the product. Sales tools such as ebooks and white papers can educate the buyer on market problems; technology briefs can explain the product and its technology underpinnings; case studies and application notes explain how the product is used.

Honestly, many product managers expect too much from sales people. They expect sales guys to have deep product knowledge, great people skills, and a repeatable process for selling. That's asking an awful lot from one person, don't you think?

For most complex products, a better approach is a team of sales people: a negotiation expert and a configuration expert. The configuration expert, often called a sales engineer, determines the right product combinations to address the customer's unique needs. This often involves extensive requirements gathering beyond the skills of a typical sales person. What options are required? What installation "gotchas" exist? Being technical, the sales engineer can often learn more from the customer than a regular sales person ever could.

While the sales engineer defines the technical configuration, the business-oriented sales person can focus on the financial configuration. Understanding the purchasing process. Navigating the legal issues of both customer and vendor. Working out a pricing plan that works for the client.

Assume that your sales teams don't know the product as intimately as you do. It's true; they don't! Create sales tools that explain the product and its options so the sales team can focus on configuration and negotiation rather than product education.

If you build a product that sells itself, you can hire order takers. And if you create the right sales tools and have the right sales teams, you'll sell even more.

Robin leverages synergy

"She analyzes synergies, or synergizes analogies... or some such thing."--Father Brian Finn (Edward Norton) in "Keeping the Faith"

Peter the CEO just returned from a corporate funfest with a new partnership. "This puts us in the sweet spot of the market by leveraging our mutual synergies in a going-forward approach." Now he wants Robin to work out the details. "Just put out a FAQ, brief the sales force, and start inviting the new team to your product planning meetings."

Right.

Nothing seems difficult for the people who don't have to do the work!

Poor Robin. As a product manager, Robin already has plenty on her plate and now this! What to do? A good partnership solves a problem for a market segment. First, find a problem, determine the optimal solution, and then explore partnership opportunities. Before doing anything public, Robin needs to understand the reason for the partnership--visualize the results of the partnership from the customer's point of view.

Is this a technology partnership? Is this about creating a new or improved product? If so, Robin should plan a few "getting to know you" meetings and get clarity on exactly what the output will be and who will be responsible for what. Ideally, the team should produce some work product before announcing the partnership. What if Robin can't work with the team? What if their architecture is incompatible with hers? What if the team cares more about quick-and-dirty and Robin cares more about elegant usability? Are the partners compatible?

Is this a marketing partnership? If so, Robin needs to discuss promotional opportunities with the partner company and then align them with her own marketing plan. The partner hosts a significant user conference; is speaking at events a key element of Robin's marketing plan? If so, sign on up. If not, why support the partner conference?

Is this a sales partnership? Here's one way to know: a successful sales partnership presents one sales person, not two, to the customer. I know I know. It sounds great--internally--to say "our two sales people will go to the customer arm-in-arm to present a single solution." Alas, that always seems to fail in the real world. One solution = one sales rep. Actually, sales partnerships are rather fun. Since Robin knows the partner sales people don't know her products, she won't assume that they do and will create better sales tools and training as a result. [Hey! Maybe you should assume your own sales people don't know the market or the products. Wouldn't you create different sales tools and training?]

Partnerships are a great way to expand your expertise, your product set, your exposure to the market, and your sales reach. Both partners should benefit from the relationship. And your mutual customers should get a better single solution than the parts created by the two of you individually. But you better label your stuff. The average partnership in technology business lasts about four years. Be clear what is owned by whom for when the inevitable separation occurs.

Don't announce a partnership until you're clear on team roles and deliverables. The best partnership creates better experiences for your customers.

Robin’s Inner Circle

"Telephone call? Telephone call? That’s communication with the outside world. Doctor’s discretion. If all of these nuts could just make phone calls, they could spread insanity."--Jeffrey Goines (played by Brad Pitt) in the film "Twelve Monkeys"

Robin got a call from Brian, her lead developer. "We're looking at your security requirements and want to know if you want FIPS-140-1, -2, or -3." Robin's mental response was "huh?" but she recovered and said, "Let me get back to you." She's not sure what the market requires in terms of this security specification but she doesn't want to do a protracted research project.

Solution: call a friend.

Robin has an inner circle of a few product "friends" who represent her personas. The inner circle is outside of the "official" company relationships with sales and support. Because it's unofficial, the relationship lets her elicit requirements off the record without looking foolish. Because she's not selling but asking for advice, she can get an answer quickly.

An inner circle is a little bit focus group and a little bit customer advisory board. It's a small group of coaches--advisors--who will give her the straight scoop without involving or affecting the rest of the company. This group represents a market and persona that is core to your product strategy.

How do you pick advisors? Be on the lookout for those customers who are the perfect personas in your mind's eye; those who put the product's long-term health ahead of their short-term gain; those and those who you really connect with and can trust.

Always have a small group of advisors. Company presidents do it; so should you. When you need outside perspective, call a friend in your inner circle. Everything is off the record so you'll get an answer that you unlikely to get through an official channel. Not sure what to do? Call a friend.

Robin the product manager

Personas rapidly gained popularity in the software industry due to their unusual power and effectiveness.—Alan Cooper

I need a protagonist for many of the stories below. Since these are stories related to product management, let me introduce you to Robin the product manager. We use this persona at Pragmatic Marketing for developing new content and promotions to product managers.

Last year, Robin, age 32, was the company’s best sales engineer and was recruited by the VP of Marketing to take on product management for the company’s flagship product. The sales force is happy that “one of their own” is now driving strategy for the product and is in the inner circle of product information. However, they continue to call her for product demos and roadmap information about future releases of the product. She’d like to help sales people even more than she does now but her schedule is a mess: she has 15 to 20 meetings this week, she has over 100 emails still requiring some action on her part, and she has a dozen phone calls that she needs to return.

Her desk is covered with stacks and stacks of documents related to the next release of the product: hundreds of enhancement requests, notes from sales people about a “special” capability that will ensure a deal, and the defect tracking report with almost a thousand features with problems, either features not working correctly (defects) or requested features (enhancements). To add insult to injury, her company is transitioning development to an agile method and she doesn’t know how that will impact her new role. She has to make some sense of all of this data in order to create a Market Requirements Document (MRD) for the next release. 

Robin has no formal product management training beyond marketing courses she took in college as part of her MBA but she really knows the product and has extensive customer experience.

Does Robin sound familiar? She’s the prototypical product manager: she’s technical, enthusiastic, frustrated. She wants to do a good job if only she can figure out how. Do you want to help Robin in her job? I do.

Personas give us a development and marketing target. A phone designed for “anyone” meets the needs of no one. A remote control for one type of person may not meet the needs of another.

Use personas as a shorthand way to define whom we want to delight and remarkable products will result.

Robin and the confidential document

"Three may keep a secret… if two of them are dead."--Benjamin Franklin

Poor Robin! Kevin, the world's worst sales rep, convinced Robin to go on a sales call to a government agency. Kevin filled a three-ring binder with product literature for the client. Included in the binder were a number of confidential documents including the product roadmap, a competitive assessment, and the beta plan for the next release.

Kevin handed the binder to the CIO of the agency who looked at it briefly and promptly returned it. "I can't see these documents," said the buyer. "They are marked confidential."

Quite the clever one, Kevin said, "Oh, you don't know what confidential means. It just means you cannot show it to people."

"Actually," said the buyer, "I work for the government; I know what confidential means. Confidential means that you can't show it to people."

Afterward, Kevin complained to Robin, "Why do you distribute documents to me that I cannot use for selling." And there's the disconnect. Robin thought that the sales people should know the product strategy, the competition, and the next release so that they would understand it. But Kevin doesn't want to understand; he wants to sell. To Kevin, any document is product collateral.

Robin's new rule is "don't give it to a sales person unless you want it to go to a customer."

This came to light when Robin's company was bought by their arch-rival competitor. As part of the product integration team, she met her product management counterpart who said, "It's a pleasure to finally meet you. I have been reading your work for years." Robin learned that her competitor possessed a folder filled with confidential documents--every document that Robin had distributed to her sales force. The most common scenario is that the sales person used the confidential document after the sale was lost but before the contract was signed. Kevin uses confidential documents in desperation. And the lost customer forwarded the documents to their preferred sales person.

What's Robin to do? If she really understands her sales people she will see that some can be trusted and some cannot. Assume that sales people will distribute confidential documents and write accordingly.

Robin is from Mars

"Never tell people how to do things. Tell them what to do and they will amaze you with their ingenuity." –George Patton.

Robin bought Dr. John Gray’s book Men are from Mars, Women are from Venus to learn techniques for communicating better with the men and women on her product team. She learned that men are problem-solvers while women emote. She learned that men who are frustrated want to be left alone while frustrated women want to share with the others. (And of course, she realized that these are archetypes that don't necessarily fit everyone.)

Robin got some helpful tips for work and she shared the book with her mom. “Maybe you can use this to communicate with Dad better,” she said. A month later, her mom called and said, “I liked the book. It made some good points. But what I still don’t understand is this: how do I get your father to do what I want him to do when I want him to do it and how I want him to do it.”

Uh-oh. Mom doesn’t care about communicating; she cares about mandating. Dad isn’t a partner; he’s a factory worker.

Are you leading a team of partners or are you managing a project with factory workers. Most development projects require committed, informed, enthusiastic people. They don’t need to be told what to do and how to do it; they need to understand the problems to be solved. Give them a problem and get out of the way.

Robin and the whitewater raft

There go my people. I must find out where they are going so I can lead them. --Alexandre Ledru-Rollin

 

photo courtesy Nantahala Outdoor Center.

Have you ever gone whitewater rafting? You get a raft and you and four or five pals pile in; if you’re smart, you’ll also get a river guide who knows where to find the hidden rocks and great swirls.

Robin’s family goes whitewater rafting every couple of years. They sometimes go on the “family friendly” Nantahala river (no helmets required) and sometimes on the more aggressive Upper Ocoee which boasts some intense whitewater and was used in the 1996 Olympics (helmets definitely required).

Here’s the important part of the mechanics of rafting: the people on the sides provide velocity but not direction. The guide in the back provides direction, using his oar as a rudder. He controls the raft’s direction with minimal effort but has little impact on the velocity. And as hard as the rowers may try, those on the side cannot change the direction. It’s particularly funny to watch another raft and see the folks on the side paddling furiously—attempting to change direction—while the guide calmly keeps the raft pointed forward.

It doesn’t matter how hard you try; only the guide can change the raft’s direction.

The raft is your company. The president is the rudder; the workers are the paddles. Which are you? Only the guide can change the raft’s direction, no matter how hard the paddlers try. Instead of trying to change the raft’s course by paddling furiously, look at what the rudder is doing. If you don’t have confidence, jump! If you have confidence in the guide, paddle.

(Thanks to my friend Jim who gave me this analogy originally.)

Look in your hands. Do you have an oar or a rudder? If you have an oar, you cannot change the raft’s direction, as hard as you may try. Paddle! Or look for a new raft.

Robin and the car that wouldn't start

"We all see what we want to see. You have to look with better eyes than that." --"Lindsey Brigman" in The Abyss.

Robin the product manager appeared distracted in the weekly development meeting. Finally she sighed and said to the team, “I left for work this morning at the regular time. Just a few blocks from my house, the car stalled and died. I tried to start it again. It would turn over but it wouldn’t start. So, I walked back to my house. But when I got there, I found my husband passionately kissing my best friend. What should I do?”

Wanting to be helpful, a developer said, “You know, I had that problem once. It’s usually a problem in the fuel line. You want to remove the fuel line and clean it out really well. Then I bet your car will start the first time.”

Have you noticed that some people focus on the right answer to the wrong problem? When listening to a customer or a colleague, try to find the root problem in the discussion. It requires better listening skills than many sales people or developers (or product managers) seem to possess.