RULE1 ：If product managers don’t do their jobs, the other departments will fill the void
When I first worked as a product manager, I wasn’t all that sure what I was supposed to do. So I waited for everyone else—Engineering, QA, Tech Writing, Marketing, Sales Support, Customer Service—to stake their claims; then I ran around filling in the gaps. At the time, this struck me as a quite handy and pragmatic way to define my job. But it was a bad idea—and not just because I got stuck with all the stuff no one else wanted to do. As it turns out, products end up being better if someone truly owns the entire thing.
As so often happened during the course of my long career, I learned the hard way that good product managers aren’t just pragmatic, they’re proactive. They don’t just sit around waiting to see what everyone else does; they make it clear up front what their role is. And then they fill that role, rather than the gaps.
Here are just a few of the things that can happen when product managers don’t fill their roles:
If you don’t provide clear and supported input to the process, the engineers will develop what they please. It’s your responsibility to talk to your customers (and your prospects), check out the competition, listen to the analysts, learn about your industry, learn about your customers’ industries, find out what your sales engineers and customer support reps are encountering, look at those RFPs, and glean market intelligence. And it’s your responsibility to translate all this “stuff” into product requirements that you communicate to your engineers.
Yes, there will be things that your developers come up with on their own—and a lot of it will be great. But you need to be the driving force behind what goes into that product, or you could end up with a magnificently engineered product that nobody wants or needs.
If you don’t provide clear direction about your target customers, Sales will go wherever they please. Your products should be built with some particular use and customer in mind…shouldn’t they? Please let Sales know.
Even if your products are entirely horizontal— every company can use a database and a word processor—products need to be targeted to specific customers and/or buyers. You may also have a product that’s better suited for certainsized companies or specific geographies. There may be good reasons to target industries as well. (If you’re selling to later adopters, for example, Get-a-Life Insurance is more apt to buy if One Life-to-Live Insurance is on your customer list.)
The point is, you need to send Sales where they stand the best chance of winning. Even if you have the most generic product, you have to start somewhere. Pick that somewhere wisely, or Sales will pick it for you. And, in the short run, they’re not necessarily going to choose wisely (i.e. in support of your long-run strategy). Sure, they may make a sale or two, but it may not end up being a good thing for your product or your company.
While we’re on the subject of sales, if you don’t establish pricing, Sales will make it up. You absolutely need to listen to what Sales has to say on the matter. But it’s up to you to determine pricing that will work, that’s commensurate with the value provided, that’s not out-of-whack with the competition, and that is what the market can bear. If not, you’ll be in the wonderful world of having your sales team cannily figuring out what the prospects have in their wallets, and then establishing that as the price du jour—or just low-balling and overpromising to get the deal. (Just watch out when customers get together and compare notes.)
If you don’t provide clear direction about target customers and the right message for them, Marcom will go wherever they please and say whatever they want. Like Sales, if you’re not providing guidance to Marcom about target customers, they will come up with it on their own. Their programs may make spectacular sense; they may not. It’s best not to leave things to chance.
Similarly, if Marcom doesn’t know what the product is and does, they will come up with their own story. Again, their story may make spectacular sense; it may not. Again, it’s best not to leave things to chance. I worked for a company that was teetering, very publicly, on the brink of bankruptcy. One day, I saw a banner ad for one of our services. The ad touted our financial stability. I immediately called the ad person in Marcom and pointed out that this wasn’t exactly our strong suit. “But that’s what our buyers are most interested in,” she told me.
I could go on about how important this rule is, but by now you get it. And you were likely well ahead of me in getting it.
Of all of the Pragmatic Marketing rules, I find this the most important. And that’s not because those who will be filling whatever void you leave are evil and must be stopped. (Hey, you may even want, need, appreciate their suggestions and advice.) But, if engineers are figuring out what’s in the product all on their lonesome… if Sales is pulling prices out of their ear on the way to a call…if Marketing is claiming that your product solves world peace when it’s really designed for warmongers—they’re all trying to do something that is neither their expertise nor their responsibility. That responsibility is yours. Take it and use it.
RULE 2：An outside-in approach increases the likelihood of product success
However brilliantly, presciently, and uniquely imagined a product is; however a product idea seemingly springs fullblown from some Medusa’s head, there is no substitute for solving a real problem experienced by real people in a way that will work for them.
How do you get real?
I’ve found the key is in five simple words: See how your customer works.
That means looking at the current processes they have in place, at the inputs, the outputs, the end results. Who does what to whom? How do they do it? Where do they hit roadblocks? Little snags? Where does the ball drop? What happens when that happens?
There are a number of ways you can do this.
One is to actually go in and watch. Some of my most valuable hours in the field have been spent observing how my customers get their jobs done—with or without my product.
In days of yore, as the product manager for a mainframe financial reporting system, I spent the night at AT&T while they closed their books, just to see how they used our product.
（老汤注：closed the books，会计用的一个说法，也就是每年年底把公司的帐目结算好，做到收支平衡，从而结束一年的帐务。）
Boy, was I exhausted after 20 hours. And, boy, did I see some areas where our product could be improved.
I’ve done this a few times since. And, to me, it’s the most effective way to figure out where your product needs to go. Knowing what people go through trumps your imagination, common sense, and intuition—no matter how wonderful they all are.
Another good technique is open-ended interviews that get your customers and prospects to talk about “things”: business, processes, behaviors, wish lists, druthers, etc. When I’ve used this method, I’ve taken notes and, where possible, made recordings.
A third technique I’ve used is creating “A Day in the Life” scenarios, where you lay out the hour-by-hour activities your customer goes through and figure out where your product can be inserted to relieve some of the pain that invariably occurs in even the happiest work day. Obviously, it helps if you’ve observed and/ or spoken with customers to ensure you have the right idea about how they spend their days.
The bottom line: Your product has to “fit” the customers’ needs and desires, solving a true problem. You never want your customers to be stuck exchanging an existing problem for a new one—using your product. This won’t happen if you build a product outside-in.
RULE 3：Time spent on the strategic reduces time wasted on the tactical
Simply defined, strategic is where you want to go; tactical is how to get there. It’s pretty easy to see that you’d better have the strategic figured out first.
While there are many different areas in which the “strategy vs. tactics” debate can occur, I’ll frame it here in terms of trying to market a product absent a strategy. (Which also translates into trying to market a product for which the product manager hasn’t followed Rule #1, and the product has just sort of happened—generally at the hands of the engineers, I’m afraid.)
My personal favorite is the “if we build it, they will come” approach, in which a product is built, then tossed over the transom into Marketing, who are presumably waiting with open arms and closed mouths for the product toss.
No, no, a thousand times no!
You need to have a product strategy in mind that spells out positioning basics (who’s going to use the product and why), establishes the pricing rationale, provides at least a rudimentary guidepost for where the product is going, etc., etc., etc.
Another thing we’ve all faced as marketers is the situation in which we’ve been goaded (forced?) to just do something, do anything. “Something” must be done! This usually comes down on the head of Marcom and usually means helping fill the big, gaping maw at the beginning of the sales pipeline.
Do something. Do anything. Let’s get going.
Banner ads…webinars…email blasts…spiffs…promotional deals… guys with sandwich boards trolling the streets.
Thus, the campaign to nowhere begins.
You may get somewhere, but even that somewhere is going to feel like nowhere, absent a strategy. Never confuse activity with action.
There’s a corollary to this rule: In the absence of a strategy, people will go ahead and do what they think is best.
So the marketers will look at the product they’ve been given and hazard a guess on where they can market it. They may do a bangup job of it. (Great! Two hundred tuna fishermen attended our webinar. Too bad our product doesn’t really do anything for them. Not to mention that we really should be selling to tuba players. Tuna? Tuba? Close enough.)
Strategy’s hard. It means really thinking through things. It means taking a risk by declaring where it is you want to go. It means having the discipline and strength to give it time enough to succeed.
Tactics absent strategy? You might think you’re getting somewhere, but you’re really on the night train to nowhere.
RULE 4：In the absence of market facts, he who owns the compiler wins
I’ve lived through this nightmare more than once, and all I can say is, even in the presence of market facts, it’s plenty easy for the guy with the compiler to win. But when you’re working with the engineers, it is always best to have the following:
- Win-loss analysis. If 19 out of 20 times, you hear that a key factor in a loss was ease of use, your developers may respond that “the customers don’t know what they’re talking about,” “we’re selling to the wrong people,” and “our sales folks don’t know how to sell.” But you will have market facts to support your argument that the UI needs work.
- Competitive information. The last thing you want to find yourself doing is playing competitive catch-up. It is always useful to know what you’re up against. And, if you can anticipate moves that your competition is going to make— by watching what they’re saying publicly, whom they’re partnering with, where they’re selling, etc. —so much the better.
- Market trends. What’s going on in your industry or the industry into which you sell? What’s being said about technology trends? No, you don’t have to listen to every pronouncement from on high, but it helps not to operate in a complete vacuum. So dig up whatever data you can find on SOA, SaaS, MDM, or whatever acronym your product needs to accommodate. (Years ago, I worked for a software company that was wedded to OS/2. I came to a development meeting with a copy of InfoWeek magazine sporting a cover showing OS/2 in a coffin with a lily on it. That display definitely helped us move along on our decision to convert to NT.)
- Customer input. The customer is not always right, and sometimes, they will ask for stupid or irrelevant things. But your trusted customers— not your developers—are the ones actually using your product, so their ideas matter.
- Sales engineering and customer service input. Better than anyone else, your sales engineers tend to know the technical obstacles to selling and implementing your product. You need a forum for capturing their ideas. Better than anyone else, your customer service folks tend to know the technical obstacles to ongoing, day-to-day success with your products. You need a forum for capturing their ideas, as well.
When you, as a product manager, start talking product with the engineers, you need to be armed with the richest set of market facts you can find. The preceding suggestions are useful sources of those facts. It’s then up to you to put the market facts into a digestible, sensible format for presentation to engineering.
There is still no guarantee that a really stubborn guy with a compiler won’t balk at product ideas that aren’t invented in his brain. But, if you’ve got the facts, ma’am, it’s far more likely that resistance will fade away.