What do your customers want to know?

Went shopping for a dual port USB charger. Seems simple enough.  I think I want this one.

marketing specs copy.PNG

If you were considering this purchase, what specs would you like to know? 

marketing specs.PNG

And there you have it. The most important spec is "the latest innovated [?] charger created by Motorola. (I was wondering about its SIZE! You know, height, width, maybe something relevant to my purchase.) (Oh, and why is a used one twice the price of a new one?)

I often read FAQs and specs to find some key piece of data but I usually get junk like this. Marketing hype. Nonsense specs.

I actually read this one once: "Q: Can it really be this good?" Yeh, I bet you get asked that one frequently.

Specs should answer the frequently asked questions. Get it? FAQ = frequently asked questions! Now, how many people ask, "Is this one of the latest innovated chargers from Motorola?" I mean, really! 

Product descriptions should answer customer questions, not the questions that you wish people would ask but never do. Help a customer move forward in the buying cycle. 

Great content is the best sales tool in the world

Great content is the best sales tool in the world.—Marcus Sheridan, author, The Sales Lion blog

A marketing director shared a new video series that she had prepared for the sales force. She was proud of the work but annoyed with the sales people. Seconds after publishing the videos, a sales person asked if he could share the internal videos with his clients.

She complained to me, “Every time I create something for internal use, the sales people want to share it with clients!”

She needs to listen to what they’re saying. What they’re saying is they want more sales tools and less sales education. More stuff to share with clients and fewer focused on training the sales people.

A product manager once asked me to authorize five days for sales training. “Surely I heard you wrong,” I said. “You must’ve meant five hours, right?” Nope. The product manager wanted five days. His agenda began with “Day 1: The history of computing.” Clearly he was trying to teach his lifetime of knowledge. But what do the sales people really need to know?

I’ve often remarked that it’s vastly easier to sell products when you understand them deeply.  Everyone needs to know what we do here. And in my experience, the best sales people are ones with domain knowledge… but it’s their ability to apply that knowledge to customer scenarios that creates success. The best sales people are trusted advisors to their clients. And that’s the way it should be.

What do your sales people really need to know about your technology? They need to understand target markets and personas, and the problems your company can solve. Do they need more?

That’s why I emphasize sales tools more than sales education. Create ready-to-share sales tools for everything. Create ROI calculators, ebooks, white papers, slide decks—all ready to use and ready to share. Limit the number of confidential and internal-use documents to roadmaps and competitive battlecards.

The ideal sales tool is a container for your expertise—in business, technology, market, and domain. And then every sales person can distribute your knowledge directly to the client.

Listen to your sales people. If they want to share internal documents, they’re telling you they need more external documents. Respond to their requirements. They’ll be more successful and so will you.

Empowering judgment with context

It is better to train ten people than to do the work of ten people. But it is harder.—Dwight Lyman Moody

The typical product manager's inbox is a mess. Maybe yours is too. But when you're working from your inbox, you're working on someone else's priorities, not your own. The same is true for your calendar. Before you know it, your calendar is filled with appointments that seem really urgent—but are they really important? And are they furthering your agenda or someone else's? Others are determining your priorities, as you go from one urgent meeting to another.

Attending meetings, responding to emails, helping individuals one at a time can't be maintained, at least not for long. We need to find a better way to empower others.

Instead of answering questions, explain the vision. Instead of providing detail, provide context. Tell stories about personas and their problems so development and marketing teams can use their judgment.

After all, what is the goal of product management? We want developers to build the right product and we want sales people to know how to sell it.

We want to build the product right and also build the right product.

In a small company, the executive team manages the product and defines product direction, perhaps with ideas from developers and sales people. But as the company grows larger and the product set more complex, the company leaders are too busy managing the day-to-day of the company to focus on a single product. That's when you need product managers and product marketing managers.

Ideally, product management is making decisions that the leadership would make if only they had the time to do so.

Product management professionals serve as the leadership's eyes and ears, at the product level. Looking at the business aspects of the individual products and spending time in the market to help make product decisions with the right priorities.

Share market information with the company

Every development methodology calls for someone to represent the market to the product team. Developers need to understand the people who use the product and the problems they need to solve. There are two ways to help this effort: either work side-by-side with the product team and answer questions as they arise, or help the team understand the context of the problem so they can answer their own questions using their judgment.

That's the power of product management artifacts: personas, stories about problems, and descriptions of workflows. These help the team understand what they're trying to solve.



General George Patton said, "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." Yet many leadership teams and many product management teams insist on telling the developers both what to do and how to do it. And after a while, the developers learn not to use their judgment and insights and innovations. They say, "Just tell me exactly what you want and I'll do it." But that increases the amount of work dramatically.



Think of the remote control for your television. For some people, choosing inputs and channels is all rather like magic. One solution is to document everything: "to watch a movie, switch to HDMI-1 by pressing the INPUT button up to three times until you see 'DVD' in the upper-right corner of the screen" and so on. Instead, you'll have better luck if you can explain how the input button toggles between the different input sources—cable, internet, Blu-ray player, game device, and so on. Once your family understands what devices are connected where, they can use their common sense to operate the remote control.

The same is true for developers. This is the essence of agile.

And sales people. You could give them a long list of answers to memorize and a Q&A document to reference, or you can help them understand who buys the product, what issues they're facing, and the philosophy of how you solve it.

Help them understand the why, not the what.

Help them help themselves

Telling stories about the work your customers do, explaining personas and their problems—these help the development, marketing, and sales teams learn to help themselves.

Think of a legal document, like a will or an employment contract or an employee handbook. These documents attempt to describe in laborious detail every aspect of the problem to be solved. How much easier would it be if these documents explained the ideas rather than the details?

Nordstrom Rules: Rule #1. Use your good judgment in all situations. There will be no additional rules.

That's it. The Nordstrom Employee Handbook. On a single index card.

This sort of "use your judgment" idea affects the kind of people you hire. And is impacted by the people you have already hired. If you've hired mindless drones, if you think product creation is like factory work, you can't expect them to use their judgment. If you hire people who know nothing about your industry and domain, you'll likely be disappointed if you expect them to answer their own questions. So you need to either hire for expertise or supplement the people you have hired with expertise.

I believe that people can learn. I believe that people want to know more about their products and their customers and their companies. You can help your colleagues learn to use their judgment by sharing your product vision, the kinds of customers who need your products, the problems that those customers are trying to solve, and the tools you're using to connect with those customers.

What's next?

Look for ways to explain and teach and empower those who need product and market information. Instead of responding to each request one at a time, ensure the information is available online or in ready-to-use tools.

I have a personal rule: if one person asks, then most people don't know. So whenever I get a request from a colleague or a customer, I write a comprehensive answer and then publish it. That's the reason for an internal wiki or external blog; you can respond to inquiries, in detail, and never answer the question again. Before you know it, you have a collection of documents and articles and posts that answer almost every question.

Use the artifacts of product management—personas, stories, roadmaps, and plans—to give people the information they need when they need it. Show them where it is so they can answer their own questions and use their own judgment.