Category Archives: Positioning

“Customers buy 1/4″ holes, not 1/4″ bits.”
— Theodore Levitt, Harvard Business School

At some point in every marketer’s career they produce a data sheet that looks like this:

Our product uses state-of-the-art technology including a MapReduce distributed backend processing engine with predictive analytics including multivariate adaptive regression splines, support vector machine classification, and naive Bayesean machine learning.

When the draft review comes back someone invariably says “Yo! We sell solutions to problems here, not products.”  The author then revises the copy to:

Our solution uses state-of-the-art technology including a MapReduce distributed backend processing engine with predictive analytics including multivariate adaptive regression splines, support vector machine classification, and naive Bayesean machine learning.

And then, in most companies, everyone would be happy.  “Way to sell solutions!”

This, of course, would be called missing the point.  Completely.

Nothing drives me crazier than marketers who “sell solutions” by doing a global replacement of “product” for “solution” in their work.

While I am big believer in Theodore Levitt’s quote, it is not tantamount to saying never discuss product.  If I run a machine shop, while I am indeed “buying holes” at the macro level, I might nevertheless care very much about your drill bits:  are they carbon or titanium?  What is their useful life?  Can they drill into concrete?

Saying don’t lose sight of the fact that customers buy solutions to problems is not equivalent to declaring product a four-letter word.  There are both appropriate and inappropriate times to talk about features or “feeds and speeds” when discussing your product.  The problem in high technology is many marketers are so in love with the technology that all they talk about is features and technology at the cost discussing benefits.

That is, they are so in love with the bit that they forget people are buying it to drill holes.

There are two basic frameworks for doing product marketing:  FFB and FAB.

• Feature/function/benefit (FFB).  Discuss the feature, describe how it works, and the first-order positive result from using it.

• Feature/advantage/benefit (FAB).  Discuss the feature, the first-order positive result from using it, and the second-order results that come from the first-order result.

Here is an example showing elements from both frameworks.

• Feature:  the green spots in Cheer laundry detergent.

• Function:  some amazing chemical process that removes stains

• Benefit 1:  whiter towels (and if you like puffery, towels that are whiter than white.)

• Benefit 2:  you receive compliments on your towels’ whiteness at your pool party.

• Benefit 3:  you receive a kiss from your spouse for getting complimented by the neighbors

You can see that the benefits are in effect a stack that you can climb arbitrarily high.  Here’s a business example:

• New programming tool.
• Makes your programmers more productive.
• Means you output more product than your predecessor.
• Means you get promoted.
• Means you get nicer office.
• Means you get a raise.
• Means you get a bigger house.

Benefit-oriented marketers spend their time talking about this stack.  They talk about positive consequences for both you personally (cited above) and your company (imagine forking a different company benefits stack off more productive programmers).  There’s nothing wrong with this.

Since most tech marketers tend to forget it, a lot of sales and business people spend a lot time telling marketing “stop talking feeds and speeds,” “stop all the bits and bytes,” “don’t forget the benefits,” and “remember, we sell solutions to problems.”

But that is not to say that product is a four-letter word.  There is a time and a place to talk about product and marketers who answer clear product-oriented questions with benefits-stack answers will be seen as stupid and quite possibly evasive.

Think:  “yes, I know if goes faster I can buy fewer computers that will save my company, but what I’m asking is what makes it go faster?”

This means three things for product marketers

• Never, ever do the product/solution global substitution as it accomplishes nothing.
• Always know whether you are working a on primarily feature/benefit piece (e.g., a data sheet) or a feature/function piece (e.g., a white paper)
• Get very, very good at clearly articulating the function of a feature.

Here’s a concrete example from my past of the FFB and the before/after of the “function” description, for a database feature called group commit.

• Feature:  group commit
• Function:  groups the commit records from different users into a single I/O to the transaction log file.
• Benefit:  enables system performance in the 100 TPS range by eliminating a potential logging system bottleneck at around 30 TPS.

I spent hours talking with the engineers trying to understand the function of group commit.  I heard all kinds of stuff that I needed to filter before I finally could distill it:

Well you know when we commit a transaction we have to flush a record to the transaction log file in case the system crashes so we can guarantee the atomicity of transactions, you know so that we can either rollback or commit the transaction to the system and, as you know, those same transactions logs can be used in the roll-forward process in recovery, where we restore the entire database from a checkpoint and then systematically roll-forward the transactions applied to it up to some point in time.

Well in order to make all that stuff happen we need to flush records at commit time into the transaction logs and — this is important — it’s not enough to write them to some cache because if there’s a power failure and we lose that cache then we’ll lose the commit records and particularly because we now also have fast commit, we are not guaranteed to write all the database changes to the database at commit time, so it’s absolutely critical that we write the log records and then flush them to the disk.

Now the trick with flushing log records is that there is only current one logfile in the system and that can live on only 1 disk at a time.  And since then-current technology mean the most I/Os per second you could do to a disk, then you’ve got a built-in bottleneck that will prevent the system from going faster than 30 TPS.  Now that’s not to say that if you eliminate that specific bottleneck that we won’t find other bottlenecks that limit system performance, or — heck — there may be other bottlenecks in the system that cause us not to even get up to this 30 TPS limit, but as long as you are flushing one transaction in an I/O then you are about 30 TPS-limited.

Now, in a high-transaction environment, if you could make a few transactions wait just a bit before flushing them, you could probably pick up a few more transactions seeking to commit in the same timeframe and then group those commit records together and write them all out in a single I/O.  Thus your new bottleneck becomes the 30 times the number of commit records flushable in a single I/O …

That is the kind of stream of consciousness you sometimes get from an engineer when discussing product details.  Sometimes you’re lucky and get handed a very precise, terse definition.  Sometimes you get the rambling stuff above and it’s up to you to distill it.

The great product marketer, both because they want to be articulate and because they want to free up time to talk about benefits, thus seeks to describe the function of the feature as clearly and succinctly as possible.

Remember, product and feature are not four-letter words.  But you do need to be careful to when to talk product, when to talk function, and when to talk benefits.