Last week for the umpteenth (umphundredth?) time, someone referred to marketing’s contribution to a particular effort at work with a hand wave and snickering reference to “marketing stuff.”  

In my last job, I’d regularly proofread and edit technical folks’ papers, which they asked me to do and really needed.  They’d be totally thankful for my work and in the next breath they’d ask if I could beef up their intro with my “marketing fluff.”

Also in my last job, I had responsibility for managing the resources and experience for customers visiting our facility.  My opening hour-long presentation on corporate strategy and history was regularly referred to as “the marketing stuff.”

I know the people I work with respect me, don’t think of me as “filler” so why the derision?

Now I have a dirty little secret – I’m offended when other people do this, but I’m just as bad.  I will often mumble the marketing part of my job title.  “I do PRODUCT marketing,” I’ll say.  I’ll say, “I’m the technical part of the marketing team” or “I’m barely allowed to stay in marketing, I’m so technical.”

I don’t really know where this comes from.  I’m not ashamed of my job – in fact I’m proud that I’ve gotten here.  But marketing carries with it a lack of gravitas, a reputation for being lightweight, a part of a company that college students who didn’t know what else to major in end up.  I got news for you – it’s none of those things.

Here are some of the problems I’ve been working on since I started at Infinio three weeks ago:

• Who will our customers be and how will we find them?
• If we put a lot of engineering resources into a new feature, does the market exist to justify the decision?
• What’s the right balance of talking about the benefits of our product vs talking about the technology?
• What are our competitors doing, how are they talking about it, and how do we differentiate our product?
• Is the vertical market we’ve chosen to focus on the right one?  How do we know?
• What resources do our salespeople need to successfully articulate the value of the product to close deals?  (Oh, and we’re a startup – so that list you made? Great, now go make the resources.)
• What resources do other parts of marketing need to successfully attract new customers? (See above)
• What is the one-sentence, 50-word, and 100-word summary of our company?

(And if you think that last one is easy, try it.  Then show it to 100 people and see what they think.  Then go back to your previous non-gravitas, lightweight job and thank your lucky stars that messaging isn’t your job.)

This stuff is hard.  It’s the part of the company that decides how we are going to talk to the public about what we do.  It can be really technical if you are the person ensuring that the messaging is technically accurate (blended latency vs. average latency vs. latency – which one of these can we say).  It’s a part of the company that has to be really close to customers (imagine writing a case study without knowing a customer really well).

Also, a lot of it is very analytical. We look at models of the market, the programs we are running, the cost of new leads, the close rate of deals, just about anything you can imagine measuring is measured in marketing.  Fun Fact: my teammates use Excel more than they use PowerPoint.

Sure, marketing is also where pithy advertisement sayings come from and it’s where the people are who decide what the giveaway is at tradeshows.  But the former is really, really hard.  And the latter is a tactical decision made in the context of lots of strategic decisions before it.

So enough with the “fluff” and “stuff” when you refer to marketing.  I promise to do the same.

I’m in product MARKETING.

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.