Monday, October 15, 2007

Pragmatic Marketing Rule #2

This post is the second in a series inspired by Pragmatic Marketing's 20 Rules of Product Management rules for technology marketing.

RULE #2: An outside-in approach increases the likelihood of product success.

Pragmatic describes this approach as:

...developing solutions in the context of the total customer experience. Product managers, executives, and marketers in technology companies regularly meet with people in the marketplace and observe how they do business in order to understand the full scope of their usage requirements and their most significant obstacles to adoption.

The most important thing they do is to live in the prospect’s world and look at all the touch points that matter.

Can I get an "Amen" here?

Let's face it. However brilliantly, presciently, and uniquely imagined a product is; however seemingly a product idea springs full blown from some Medusa's head, there is no substitute for solving a real problem experienced by real people in a way that will really work for them.

How do you get real?

The key is in those five little words "observe how they do business."

That means looking at the current processes in place, at the input, 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 observe. This is more easily done with a customer (who's already using your product) than it is with a prospect, but some of the most informative hours I've spent in the field have been spent dogging the heels of a customer.

Years ago, when I was product manager on a mainframe financial support and reporting system, I spent the night at AT&T in New York City when they closed their books for the month to see how they used the system. And I do mean spent the night. I started hanging up with them sometime in mid-morning on a Friday, and parted company at 4 a.m. on Saturday.

Boy, was I exhausted.

And, boy, did I see some areas where that system could be improved.

I've done this a few times since, and it's been a very effective way to figure out where your product needs to go. (I've never done it for a from the ground up, from scratch product, but I can certainly see where knowing the actual process people go through beats your imagination, common sense, limited knowledge, and intuition - no matter how wonderful they all are.)

Another technique I've used pretty effectively - again, with existing products, not newbies - is open-ended interviews with customers/prospects, in which you get them to talk about "things": business, processes, behaviors, wish list, druthers, etc. When I've used this method - based on Voice of the Customer - I've employed both detailed note taking and recordings. (Voice of the Customer was quite in vogue at one point. I'm not sure if it's still au courant. When I was using it, they suggested having two people on every interview, one to ask the open-ended questions, another to take notes. It also called for the interviews to be transcribed, and reviewed looking for key themes and ideas. I'll have to check and see if V of the C is still around and about.) 

A third approach I've taken is coming up with "A Day in the Life" scenarios, in which you construct the hour-by-hour activities your target 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. (And, no, you don't have to include bio-breaks and lunch - unless you're product solves the need for either.)

The bottom line is that the product has to "fit" the customers needs and desires. Your products should always solve a true problem and provide a true benefit - not just benefits-on-paper that may be sold to the economic buyer, but that never materialize for the actual users. You never want your customers to be stuck with exchanging an existing problem for a new one - using your product. This won't happen if you build a product outside-in.

No comments: