It’s my third week here at Infinio and I’m starting to sort through what exists from a messaging and content perspective, and figure out how to make the biggest impact as quickly as possible.

One of the items that landed on my desk early was a messaging document.  I was included in a (productive!) meeting to hear the greater team talk about the background, then I was invited to take it over and “fix” it.

There was a lot of great content, but there was also a draft of a feature-benefit matrix.

I hate feature-benefits matrices.

I don’t think they work, I don’t think they are useful.  Do you? 

I think their very format, listing out all the features and then assigning a benefit to each one, is counter-productive to what they are designed to do: help a customer understand what our product can do for them.

The format:

(a) doesn’t let you describe a benefit that is derived from a collection of features

(b) forces you to assign value to a feature that may provide no individual benefit

The result is a list that doesn’t include all the benefits the product provides, but also (bonus!) includes benefits that are not really beneficial.

Huh?

So for our own product, I’ve spent a few days unraveling all of this.  It turns out, distilling benefits from a muddled list of features and benefits is really, really hard.  And where I’ve gotten to so far is four buckets:

1. Benefits the customer gets from using our product

[Accelerator provides I/O smoothing – more consistent performance]

2. Things that make our product easy to use

[Accelerator installs in less than 30 minutes with just 6 clicks]

3. What the customer would do if they don’t use our product

[Customers may buy expensive SSDs or PCI-Flash devices as an alternative]

4. What the customer avoids by using our product *

(*I am pretty close to this being folded into #1, cost avoidance and operational avoidance being benefits, albeit negative ones.  Not relevant for the rest of this discussion.)

Once I bucketed everything, I noticed that we’ve been underselling #1 in relation to #2. Granted, our product is unique in its laser focus on being easy for administrators to deploy, evaluate, purchase, and use.  <30 minute install, 6 clicks, no manual reconfiguration of anything, able to see results within minutes.  But you’re not going to buy the product solely based on those characteristics.

You might try it based on that, and you’ll prefer it to our competitors’ products because of that, but you aren’t going to cut a PO just because a product is easy to deploy, evaluate, purchase, and use.

You are going to cut a PO because we reduce your latency, smooth your I/O performance, and offload work from your backend storage….and our product is easy to deploy, evaluate, purchase, and use.

It really falls into the category of “how do we provide these benefits” – and not “how” as in “we use 8GB of memory from each ESX box to create a global distributed deduplicated cache” but “how” as in “we provide all these benefits with no disruption or changes to your existing environment.”

And that’s exactly the kind of confusion a traditional FBM creates.  It conflates (a) top-level benefits with (b) features with (c) what it’s like to use and what environments it can go into.

So I don’t want to work with an FBM.

Who, though, is expecting to find an FBM and what do I have for them instead?:

For internal use, we may need a connection between features and benefits, but it doesn’t have to be a 1:1 mapping.  It’s probably better if it’s not – what we need is something that will help us prioritize upcoming features based on how much leverage we get with them.  For messaging purposes, we need to clearly know what our product does and how it compares to the alternatives.  Fleshing out the three/four buckets will serve that purpose.

For customers, most don’t need to know the name of the feature that provides a particular benefit.  Primarily, they need to know what the benefits will be for them – and secondarily they need to know (to differing degrees of detail) technically how we provide those – as in, classically, how does the product work.  It’s also going to help them to understand what it’s like to use.  An FBM is not a good way to communicate all of that.  A whiteboard video, whitepaper, podcast, video, webinar, SlideShare, or blog post is a far better medium.

I’ll write again on this topic in a few weeks when I have a better sense of what it’s like to do marketing and messaging without an FBM.  For now, our FBM is dead.  RIP.