Deliberate Ambiguity

Product Messaging Basics

Even assuming a world of conversational marketing where the masses shape your message, it's important to seed that conversation with something coherent.  A tight message shows why your solution is unique and useful, what your competitive position is, and tells users what problem you are going to solve for them.

Messaging discussions tend to fall on two sides of a spectrum.  On one hand, nebulous high-level documents, endless wordsmithing of simple phrases, and jargon can create a jumbled, confusing message.  On the other hand, slapping a few sentences together in a press release can sound unfocused and unclear.

A product manager's job doesn't end with creating a great product.  It's also our job to tell the world why they should care.  So what's the best way to create a messaging document?  And what should the end product look like?  Every company, product, and situation, but here's a few guidelines that have helped me:

1. Stick to basics - One of the classic formulations of messaging goes something like: "For [target user], who needs [reason to buy your product], [product name] is a [category] which [benefit], unlike [main competitor], which [differntiation]."  You should be able to rattle off something like this statement about your product without thinking twice.
2. Don't spend all of your time fixing words - Don't confuse messaging work with copy editing.  If you've a clear message conceptually, then the words can always be honed later.
3. Find a great template  - Whenever I do messaging, I e-mail a few of my marketing colleagues at other companies to see what they're using.  My favorite template is the Marketecture from Practical Product Management.  It starts off with a problem and solution statement, which helps you to frame how you talk about your product.  Also, the product statement is supposed to be short (under 25 words!) and I recommend making that an absolute upper bound.
4. Run it past someone non-technical - this is certainly true in the consumer space, but even in enterprise software.  I realized there was a problem with "natural language search" when I had to explain it to my well-educated hair artist.  Powerset's About page now contains almost no technical jargon (and I'm happy to entertain ideas about how to make it better).
5. Avoid meaningless words - This is a corrolary to the above.  Even if you think a word or phrase has meaning (e.g. "best of breed" or "highly scalable") think about a simpler way to say it.
6. Write something functional - This could be your About page, your press release, or even try your hand at the article you'd like someone from the press to write about your product.  Some might argue that you need your messaging in place before you effectively write a press release, but I think the two are informed by each other.

Anything I'm missing?  Anyone else have experience in creating a great messaging document?

Features: Band-Aid now or wait for the cure

Imagine that you get an e-mail from your CEO saying, "We've got to fix this user issue on the Web site as soon as possible.  People are complaining and it's a real problem."   Fixing this issue is not a simple bug.  It will require several person days of developer time, which may disrupt your project.  You know that you have a major release of your Website coming in two months that will fix a whole host of problems, including the one that your CEO identified.  So, the question is: do you work on this feature and endanger the release of the larger project or convince your CEO to hold off.  Here are some (internal) decision criteria that I've found useful in deciding whether to Band-Aid now or wait for the cure.

The first question always to ask in any product management situation is: what is the goal?  This isn't a about the importance of the feature, since you know it needs to be done eventually.  The question here is more immediate and contextual within the project: why should it be singled out as a potentially disruptive sidebar to the larger project?  Once you've established a goal, metrics will tell you the effect of the feature, giving you a qualitative measure of importance.

What's unique about this scenario is that you know the feature is going to come out eventually.  Therefore, statements like, "Users keep asking for it" are not sufficient to justify changing the project.  Even a financially sound goal like "Increase CTR by x%" isn't ideal, because you'll get the financial gain at the end of the larger project anyway. An ideal goal is one that justifies the feature in the context of the project, e.g., "Reduce the number of complaints to tech support so that they can focus on gearing up for the launch."  In this case, the very reasons for disruption are to prevent further disruption.

The feature's relation to the larger project is the next thing to consider.  If the feature is separate from the project, then the feature must be coded twice, once for the current version and once for your upcoming project.  If the feature is a subset of your project, then you can reuse the code and minimize disruption.  However, the scope of the feature comes into play here.  Releasing anything to the outside world incurs a maintenance cost.  Developers will fix bugs and make tweaks, which can be extremely time consuming. Any resources spent on maintaining the current product aren't developing the new, better product.

Of course, you still have the CEO gauntlet to run, but hopefully with some numbers, a clear model for decision making, and a few Powerpoint slides, you can do what's right!

 

Copyability in making feature decisions

A brief conversation between me and a coworker the other day:

Coworker: "That's something that Company X doesn't do.  We can differentiate with that."
MNJ: "But it's something that they could easily do."
Coworker: "But they don't do it."

When looking at points of differentiation between you and your competitors, there are two important classes of copyability: easy and difficult.  If your underlying structures are the same, it's usually easy for the competition to copy something.  But, if the feature requires either technical or conceptual changes to the product, then it's not nearly as interesting (from a competitive perspective).  For example, I'm not impressed with search companies who simply change the search interface without altering the underlying data.  If an interface happened to take off, it would be simple for Google to copy it.  On the other hand, if a company alters the data within the index, a major search player could take months or even years to replicate the feature.

In the end though, competition is useful when analyzing external reaction to your product, but user needs should drive your features.  The copyability of the feature shouldn't trump what your customers want.