RULE 17：You need a positioning document for each type of buyer
In the dawn of technology marketing, we spoke “techinese,” emphasizing features and often forgetting the benefits.
Then someone uttered those immortal words, “People don’t buy features; they buy benefits.” So we were off to the races with benefits statements.
Unfortunately, all benefits statements started to sound alike: Use our product to save time and money, increase productivity, and grow your revenues. You could read these benefits statements and come away with no idea whatsoever whether someone was trying to sell you a mainframe or a spreadsheet.
This all came about because, as marketers, we often fail to think through exactly who our buyers are—especially in terms of all the various constituencies who might be involved in a purchase decision.
We jumped from thinking only about the techies and their need to know the gritty product details, to thinking only about the illustrious “C-level” exec who just wants to know the ROI.
With individual positioning work, you’ll have the essential messages you need to communicate about your product and its value to all of your audiences.
- For the technology buyer, go heavy on the features and technical details. By the time they’re looking at your product, these buyers have often already made the decision to buy something. They need to know what differentiates your product from the pack. Sure, they want to know how your features translate into benefits, but mostly, they want to know how it works, what it’s made of, and what it’s going to take to implement and support. When they’re thinking benefits, they’re probably looking for what they need in order to sell up the chain in their organization.
- End users mostly want to know what your product does for them, how it’s going to change the way they work, and how easy it’s going to be for them to learn to use. And just like misery, end users love company: They want to know who else is using your product.
- Managers may not need all the details that the tech buyer and end user do, but they still need info on how your product is going to make life better for their people and for them. It’s at this level that the positioning starts shifting gears from being predominantly feature-oriented to a bit more benefits-oriented.
- For the executive/economic buyer, your positioning moves squarely into the benefits camp. But you still need to ensure that the positioning communicates what the product is and does, since even the most hands-off execs need to know whether they’re okaying the purchase of accounting software or a storage drive.
- Don’t forget vertical positioning, either. Most industries have their own peculiarities and lingo.
Having these positioning documents on hand saves you a lot of effort when you’re creating sales tools, collateral, and program material. You’ll know what to say, and you’ll make sure you’re saying the right thing to the right people.
RULE 18：Name the product after positioning is finished
Given that you want your product name to resonate in some way, this is a good rule of thumb.
With your positioning complete, you realize which attributes of your product are the most compelling, so you can craft a product name that speaks to those attributes. Is your product all things to all people? Are you most psyched about how environmentally friendly it is? How about “Green Thang”? (Okay, that’s terrible, but you get the point.)
Whatever product name you choose, keep in mind product naming isn’t nearly as important or essential for technology products as it is for consumer products. You brush with Crest toothpaste, not P&G.
Many B2B technology products are referred to by the company name, not by the specific product name (for example, many people say “Oracle” when asked what database they use). So you don’t always have to spend a lot of money and effort coming up with perfect names, when what you really want to do is promote your company name as your brand. Sure, there are exceptions— Microsoft Office, Outlook, Word, Excel, and PowerPoint come to mind—but what matters most is your company name.
Another thing to consider—and I’d recommend this for anybody who thinks they’re ever going to have more than one product to name: Create an overall naming architecture and set of guidelines. Maybe all products will start with the Company Name, followed by a straightforward expression of what the product is or does:
- Acme Accounting Software
- Acme HR Software
Maybe it’s Company Name, followed by something that combines an element of what the product is, as well as an associated attribute.
- Acme Accounting Excellence
- Acme HR Excellence
Or vice versa:
- Acme Excellence for Accounting
- Acme Excellence for HR
While you’re at it, figure out how you’re going to handle versioning, “special editions,” and any other rules you want observed (for example, don’t use two of the same vooweels together in the same word).
If you’ve got all this codified ahead of time, people will spend a lot less time agonizing over names.
RULE 19：Provide collateral, tools, and programs to support each step in the sales cycle
Early in the sales cycle, a prospect needs to know the basics about your product and company— enough to help establish interest (theirs) and credibility (yours). Period. Dangle a case study in front of them. If they bite, great! You’ve moved them a little further along.
Thinly veiled sales pitches can go out in the second wave. But you might want to reserve a really meaty whitepaper—one that digs into industry and/or technology trends and downplays the product stuff—for someone who’s demonstrated serious interest. (If you have such a whitepaper, you probably paid plenty for it and should use it judiciously—this goodie is worth something)
Nitty-gritty product info should be available to the serious tech buyer. Within reason, you’ll have a lot of this material on your website as downloads, but you might want to reserve highly detailed information for prospects that are fairly far along in the sales cycle—and have the salesperson send it, or make it available via special download.
As you move forward in the sales cycle, you’ll want to introduce tools and collateral that help the ROI cause, provide customer testimonials, explain implementation, etc. At this point, prospects have a need to know and need to use.
For heaven’s sake, don’t send out the whizbang PowerPoint until you’re scheduled to walk through it in a virtual meeting (maybe not even then). You can always email the file to the prospect after the presentation.
When meeting in person, some people like to distribute presentation copies beforehand; others like to distribute them after the fact. I’m for giving them out after the fact, preferring to turn a presentation, wherever possible, into a two-way conversation, rather than a slide read-along. And make sure that the slides are annotated, so that someone who wasn’t at the presentation is not reading a page that says only:
- It’s big. • It’s wonderful. • You’ll like it.
With notes, they can read the fine print and understand what point you’re trying to make.
Whether you work at a small or large company, there’s always the temptation to shoot out all the collateral at once. Take one of everything! Don’t we have a lot of neat stuff for you? And now, of course, we have a tendency to put all that stuff up on the website and let prospects download whatever they want. Unfortunately, those prospects could get overwhelmed and/or not read much of anything. So, it’s really best to reserve some bits of information that your salespeople can send out at different points in the cycle (following a roadmap for what-goes-where-when that you provided).
Similarly, your marketing programs—tradeshows, seminars, webinars, direct marketing, blogs— should be used for different purposes and at different times in the cycle. But don’t forget, many programs can serve multiple purposes: If you’re going to a tradeshow, you’re probably trolling for leads, but don’t forget that it’s a good opportunity to set up face-time with customers who’ll also be attending.
B2B technology sales don’t tend to occur as one-shot events. They take time. And during that time, you want to make sure that you have something more to say or do than have your sales folks on the phone asking, “Have you made your decision yet?”
RULE 20：The market-driven product manager should be the final authority on what goes into the product
While this should be the most obvious of rules—after all, someone has to be the final authority on product requirements—the operative term here is market-driven.
Take it from someone who’s been both a product manager and a marketdriven product manager, there’s a world of difference between the two.
The plain-old product manager serves a very valuable function, making sure that the requirements are nailed down; keeping a product release on track; knowing at any given time just where things stand with development, QA, documentation, packaging, manufacturing, production, training, marketing, support, sales, etc. The product manager knows who the customers are—and who they aren’t. The product manager gets to buy all those bubblegum cigars for launch date—“It’s a product!”
Sounds pretty good, no?
But here’s where life is not so good for the non-marketdriven product manager: He or she may have made sure the requirements were nailed down, but they’re not likely the one who actually did the nailing.
Absent strong awareness of the market—the kind that comes from knowing your customers, industry, product domain, competition, and business and technology environments—a product manager will almost invariably give in to the loud-mouth/know-it-all brigade—developer, salesperson, or anyone else who is willing to voice a strong opinion .
The product manager in this scenario is really a glorified project manager—the keeper of the Gantt charts, spreadsheets, and schedules—but not the person who truly “owns” the product. That is, until the product meets with some market resistance. Then, you can best believe heads will swivel toward the product manager, eyes will turn, fingers will point. “How did we let the product go out the door without X, which everybody seems to want? Why did we waste all that time and money on making sure the product did Y, which nobody seems to want?”
Sure, this can happen even when the product manager is market-driven. Anyone can make a mistake.
But that scenario is far less likely for the market-driven product manager, who will have either made sure the product does X or understand why it doesn’t; who will know why Y went into the product and what you need to do to ensure it’s not a waste of time.
The product manager should be the final authority—but that will happen only when he or she has earned the authority by being able to show the world—especially those loud-mouths/know-italls—what being market-driven is all about.