THE TABER REPORT
The Voice of Effective Marketing

"New Shimmer is a Dessert Topping! 
No, new Shimmer is a Floor Wax! 
Hold on:  
New Shimmer is a dessert topping 
and a floor wax.
 
New Shimmer ... 
for  the greatest shine 
you've ever tasted."

Although the details from this Saturday Night Live skit are preposterous, too many companies have product strategies with strange value propositions -- yielding erratic lead generation and few customers.  A broken product strategy can kill your sales for a year or more, so it pays to get this one right.

Product Strategy

Do you have a problem here?  It is very rare that you'll perceive product strategy as the critical issue from within your company.  The symptoms you'll notice are unfocused value propositions, poor press and analyst reviews, difficulty getting leads, no repeatability in sales cycles, endless pricing debates, poor sales volume, and a high degree of shelfware.  You are likely to believe you have a "target market problem" or a need to "rework the go to market plan," when the problem is the product itself.   For lots of psychological reasons, people outside your company will see a product issue much more clearly than you. 

Product strategy is tough because you have to think of your features, your customer, and your channel all at the same time.  Change just one, and the other two go out of balance.  Most companies define this triad serially -- and it's really tough to fix if you guess wrong on any of them (which is almost always the case).

Product strategy is not just for big companies and evolving product lines.  In fact, it's most dearly needed when you start a new company or business unit.  Poorly conceived products -- particularly when not identified and fixed -- can overwhelm a company. 

So the first diagnostic is to talk to your customers and to prospects you lost:   understand what they think your product is.  What do they compare it to?   What about it is great, and what is so-so.  Do they use your internal product categorization, or do they put it in a different product area?  If they think of your product differently than you do, or they disagree radically among themselves about where your product is valuable, you have some work to do.

Let's start from the beginning, assuming you can work with a clean slate.

The Big Secret

Product strategy is a simultaneous equation, to be worked iteratively: focus your customer definition and your product's commercial attributes.  You aren't done until you have something that a bunch of real people are willing to spend real money on.  The Big Secret:  too many companies ignore this.

Before you design your product, design your customer

At the root of many flawed products is a simple problem: there is no customer.  While the product was being conceived and designed, everyone jumped to the conclusion that there would be customers.  But if you look hard at the features and limitations of what you built, it may be hard to imagine who the user really would be.  Take a look at one example here (click on the image on the left to get a bigger view).  This product hybrid was conceived as Something Neat that would Sell.  Engineering solved all the problems, but for $6 the customer gets a product that is neither a good pen nor a good radio.  Yes, pens and radios are sold by the millions each year...but that doesn't mean there are customers for a pen-radio.   Under what circumstances does someone who needs to do some writing at that same instant also want to listen to an inconvenient radio in the same package?  Don't laugh-- there are plenty of examples where radios have been jammed into cameras, TVs into Ghetto Blasters, and databases into word processors.

So when you are conceiving a product, the first things to think through are the customer, the use case, and the purchase cycle.  Exactly who is the customer?   If you think "everyone," think again:  if you don't have a specific customer in mind, you won't have any customers.  Where, when, and how often does s/he use your product?  What other products are in use at the same time?  What are their commercial and technical expectations?  How do they evaluate this type of product (e.g., do they read literature vs analyst reviews vs downloads vs pilot usage vs full proof of concept)? How do they compare your products to others, and how do they make their personal decision to buy?  Whom else do they need to convince in order to get purchase authorization?  How will you economically find these users, influencers and buyers so that you can make a sales cycle can happen?

Ready to hit the drawing board?  Not yet.  Think about the product's ecosystem before you design the specific product.  How does the product get delivered, installed, and configured?   How does it get populated with data?  How did it move from being evaluated (via a download or hosted trial) to full production usage (e.g., upgrade-in-place vs full reinstall).  Will partners need to be involved in the sale, installation and setup?  How will they get incented and trained to do this for you?  How will you recruit, motivate, and grow those partners?  These business basics are painfully, pitifully overlooked in too many product strategies.

Design your Product to Win

Loser products are unfocused, yet often involve more technology, features, and sweat than the winners do.  But they're losers nonetheless because they don't achieve excellence in any specific area, so they don't never really have a compelling value proposition.  Loser products are usually incomplete in a noticeable way, and completing the product concept would often require more new engineering than the company could ever afford.  In other words, most loser products are ill-conceived and cannot be converted to winners.

In contrast, winning products do a few things very well, and have a coherency of value that makes them unbeatable even though they may have fewer features.  A winning product must have a thesis, a theory about what the customer values most.  Evaluate only one product thesis as a time -- you'll confuse yourself if you don't.  Your product thesis will evolve over time, but it must stay on a coherent track. 

So design your product around a proposition:  our product is best in the world at doing X for customers who need Y in order to save them $Z.  Typically, version 1.0 products have to be narrow in platform support and Spartan in GUI (or hardware control panel / adjustments), but the "feature narrowness" is carefully designed so that the product can be practically applied and easily used.  Lack of features is transformed into elegant simplicity.

One of the best examples of this customer-focused product design was the original ZIP drive.  It did one thing extremely well, and was designed with a specific type of user in mind.   It had very few features, but it was very easy to set up and use.  It was not a general purpose storage device -- in fact, it wasn't very good or economical as storage devices go.  But because it was designed with a tightly focused conception of user, problem, and use-case, when it was introduced no other product was even close.  ZIPs sold like crazy.

Don't overdo it asking the customer about features.  You may not like Henry Ford, but you have to admire his straightforwardness:  "If I'd asked my customers what they wanted, I would've had to go breeding faster horses."

As you're conceiving and designing your product, not every feature has to be there from the beginning.  In fact, you want to avoid the profusion of "me too" features that leads to mediocrity.  It's a good thing to add features incrementally, following customer input.  Have a clear understanding of what the defining requirements for version 1.0 are, and guide the evolution of features after that to maximize the coherency of your value proposition and the strength of your advantage.  The product roadmap will evolve quarterly as competitive conditions change, but it is a key tool to keeping your engineers and sales reps focused.

Reality Check

Product strategy must satisfy the basics of a business case:  there's no point in building a product unless you can make a profit.  So, don't drill down exploring a lot of details about product design or channel SPIFs until you have the basics nailed.  Here are the four killer questions you must answer for yourself:

1. Are there enough customers, really?

2. Are they willing to pay enough for you to make money?

3. Can you get to them, and will they buy from you?

4. Have you fallen prey to any marketing fallacies?

The way to answer these questions is to talk to your target customers.  Talk to the users, their boss, their purchasing department.  Talk to them to the point you have real empathy for them.  Spend your time listening, not selling your idea.

Details, Details

Here are some issues of product strategy that seem trivial at first, but actually have broad impact. 

Product naming is worth getting right because it's your opening line in the ongoing flirtation with the customer's mind.  You want to get the name right the first time -- it's surprisingly expensive to rename products, and the new name is always undermined by the previous one.  Unfortunately, naming is often an emotional issue within companies, requiring clever political maneuvering.

Product pricing is what will drive your bottom line, but it too is an emotional and political football.  This topic could be its own newsletter, but the key is to realize that nobody can really know what the pricing should be until customers have the product in front of them.  During product design, focus your attention on the pricing objectives (e.g., market share vs time to profit) and the pricing model (e.g., perpetual license vs pay per use), which will allow for a rational conversation about specific price points or discounting programs once the product is ready.

Product channels and Target markets are completely intertwined with the choice of product features.  Each of these topics deserves its own books (wouldn't fit into a newsletter ;-), and they are the toughest part of product definition.  Spend serious time and effort defining and describing the companies (not users, but commercial entities) you will be trying to break in to.  Identify common company characteristics that define your product's market segments (e.g., industry type, size of company, business process, etc.).  Figure out how to make contact with those companies and be appropriately visible to them (is marketing for this product category normally done at tradeshows or on the golf course?)

It's time for eXtreme Marketing

Most marketing groups handle product strategy the wrong way:  with "MRDs" or "PRDs" -- big documents that don't evolve, and are written in a commercial vacuum (read: without direct sales input).  In continuing to make these errors, marketing is actually years behind software engineering.

The most aggressive software engineering style has been dubbed eXtreme Programming, following these principles:

• Assume that requirements aren't truly known until somebody starts using the software
• Involve the user early and often
• Create tests before you write code
• Develop features iteratively, and don't try to optimize until the end
• Deliver small things of value to users often
• Continuously root out unused features and unnecessary complexity.

The engineers figured out that the "big bang" method of delivering software creates clumsy, monolithic, and expensive products that miss market windows.  And the user hates them. 

It's time for marketers to stop writing the big dusty MRDs that nobody will read.  If product development cycles are measured in months rather than quarters, product definitions should be following eXtreme Marketing rules:

• Don't try to state detailed requirements at the beginning.  Instead, focus on what everyone needs to know: precisely who is the customer, what is the use-case, and what is the environment of the product usage.
• Talk to the user (i.e., outside the company) about how they'd use a feature before you specify it.
• Test whether requirements are real:  will the customer's purchase decision actually be effected?  Will they buy one month sooner, or one more unit, or at a price that's one penny higher?
• Develop requirements iteratively, with more precision as you get further along.
• Deliver requirements in installments, not as a big document.
• Avoid over-specifying requirements, and focus on the meaning of the feature to the user instead of minute details.
  

The Product Documents

eXtreme Marketers spend time brainstorming and boiling down your thoughts and conclusions, instead of writing giant tomes.  The documents should be short enough that you can read one and revise it in 30 minutes, as you discover more from customer and product developments.  The documents should be quickly reviewed every 3 months to make sure everyone on the product team is still going the same direction.

For a host of reasons (mainly psychological), I recommend that you not call these documents "MRDs."  Naming it "customer requirements" is more representative, and carries less baggage.  Keep these documents small and modular, so they can be easily updated and reused:

• User definition.  Describe who the users are, what their job is, what their tastes and preferences are, and what their perceived problems are.  1 page total.

• Buyer (customer) definition.  Describe who the decision-maker and budget-holder are.   Describe their link to the buyer, and what is required for them to make a purchase decision.  1 page total.

• Personas.   What are the different kinds of people who touch your product, either in evaluation/purchase or in usage?  What is their business card title?  Describe their roles and needs, and if you can, guess their prejudices or beliefs.  1/2 page per persona.  Ironically, the most important persona to write about is the person you're intending not to satisfy.  Make sure everyone on the team has a coherent definition of this "negative persona."

• Use cases.  Describe the ways in which each persona uses the product.  What problem do they think they are solving, and what do they experience in using your product?  This is the first place where you can talk at a very high level about product capabilities, performance, or characteristics.  <1 page per use case, if you can.

• Target market and expected go-to-market strategy.  Describe the kind of companies or users that will be your beachhead market, and summarize who or what you will face as competition.  Describe how you will become commercially visible to your target market, and who will sell to them.  <2 pages.

• The Product Announcement press release.  Early on, before product design work is even started, write the press release you'd like to publish when the product is done. This forces you to think about the buyers and users, the value proposition, what you will be compared to or competing with, what your compelling difference will be, and what kinds of quotes people would be willing to give you.  This is an amazingly difficult and telling exercise, and it is very useful to engineering in making daily value judgments as the product progresses.  Must be revised at least every 6 months.  2-3 pages.

• Product environmental overview.   What is the technical environment into which the product is installed?  What interfaces does it depend on and need to be compatible with?  What international, documentation, and help features are needed?   How is the product packaged and delivered?  Does it have an auto-update system, or a feedback loop to your company's servers?  Does it use a license-enforcement system?  1 page.

• Product business context.  Describe how the product is sold.  Who sells it, and how many partners are involved?  What's the price point and the sales cycle?   Are there warehousing or distribution issues to consider (e.g., carton must withstand shipping from China)?  What are the warranty, returns, and upgrade features?  1 page

• Product functional overview.  OK, OK, you finally get to describe some features.  You already know how to do this...but write it from a "top down" in perspective, explaining the benefits achieved rather than the bells-and-whistles details.  It's far more important to talk about the motivation and meaning of features than exactly how the product will be built.  <3 pages per major functional area (e.g., "server," "GUI," "utilities").

The Urge to Merge -- coming in February

Contents copyright 2005 by DOTnet Consulting, Inc, all rights reserved.
Feel free to forward this report, but you must include this copyright notice.
All trademarks and graphics are the property of their respective owners.
This newsletter was mailed to you because our records show you asked to receive it. 
Click here to opt-out of future newsletters, although that will make us feel very sad.

David Taber
   www.taberconsulting.com