Deliberate Ambiguity

The PR Blame Game

A friend recently was complaining to me about having trouble with her PR firm.  "What's the problem," I asked.  "Well," she huffed, "They just aren't getting me the coverage I want.  I just don't think they're working hard enough.  At Powerset, SHIFT must have had it so easy.  Your story just told itself."

I didn't have a decent response at the time. Powerset did have an amazing story. To convince someone that natural language is a better search interface than keywords is a piece of cake.  Additionally, our product was cool, innovative, and solved user problems.  We spent a lot of time getting the message right, but it was more about perfecting the words to communicate our story than perfecting the story itself.  On the other hand, our PR team worked their butts off, turned around some from doubters to believers, and got us an insane amount of coverage.  What was the secret sauce?

After reading Julie's post about firing a client, something important struck me: my was just playing the PR Blame Game. My friend's company had a mediocre idea and a lame product.  It's not the PR firm's fault that coverage was spotty.  Instead of jumping down the throat of her firm, I think she should have taken the following steps.

First, maybe it's not your product that's the problem, but the way you're telling the story.  Instead of pitching more reporters, go back to your product messaging basics. Figure out who your audience is. Understand what their problems are and articulate how your product solves those problems.  Communicate that message in crisp, clean, simple language.  This kind of strategic PR can be time-consuming, but it's something that your PR firm should be able to help with and will make subsequent pitches much easier.

But, there may be a deeper problem.  If your product sucks, no amount of product marketing will fix it.  Make sure that you're getting feedback from your PR firm about your product.  And, ferchrissakes, listen to it.  Your PR firm is on the front lines talking to experienced reporters who can give valuable suggestions for product enhancements.  Empower your firm with the ability to bring this feedback to your company and then act on it.  Obviously, don't forget your core strategy or your users, but you'd be remiss to ignore an expert opinion. 

Finally, if your PR is stagnant, the feedback you've been getting is largely negative, and you can't find an easy way to improve your product, maybe it's time to take a drastic measure: shift your monthly PR budget to product development.  This is kind of like "firing" your firm, but done with an "it's not you, it's me" realization. Your PR firm will appreciate the honestly and will likely be ready for you in 3-6 months after you've produced something marketable.

My friend was absolutely right that Powerset did have it easy. But, that's only because we had a cool product and a compelling story around it.  So, next time your coverage report isn't as rosy as you'd like, take a step back and don't play the PR Blame Game. If you haven't armed your PR firm with a great message about a killer product, you only have yourself to blame.

n.b., this post is a response to Julie Crabill's Fire a Client Today post as part of our ongoing dialectic.

The Feedback Lacuna

la-cu-na [luh-kyoo-nuh] (n.)

a gap or missing part, as in a manuscript, series, or logical argument; hiatus

Much noise is made about the way that social media will influence products.  Whereas social media is beginning to collect huge amounts of customer data, this feedback is not yet making it to the right people: the product managers and developers.  Though I don’t have a simple solution to this problem, I hope to convince you that there is indeed a lacuna that needs to be bridged.

The Playaz

On one side of the lacuna are social media gurus and marketing types, who cheerily proclaim “Feedback from customers through social media will cure your product woes!”  They imagine that Twitter, Facebook, forums, etc. are channels to listen to users in a brand-new way. They're sick of putting “lipstick on a pig,” and believe they have access to a feedback stream that will connect the organizations directly to users in a way heretofore unimagined.  The products resulting from this feedback will delight users.

On the other side of the lacuna are the product managers and the developers, who groan loudly upon hearing this advice.  After years of usability studies, user-centric design, log-analysis, and countless other techniques to get into the mind of the consumer they wonder, “What now?  They’re always cooking up something useless in that marketing department.  Why don’t they just focus on what they’re good at instead of trying to bother me?  I have a product to build!”

The Problem

Putting on my marketing hat, social media gurus are wrong if they believe that social media is the panacea that will solve all product development problems, but right in believing that they can deliver a new, important voice.  Putting on my product manager hat, I feel justified in being skeptical of marketing people who have never built a product, but I can’t deny that they have access to a fascinating new stream of data that I want to incorporate into my product planning and design.

The real question should be about how marketing/PR folks can get looped into the product development process and how product managers can partner with marketers to create the right product and inform the market about what they’ve (jointly) created.

Bridging the Lacuna

Assuming that we all agree that there is some signal in the noise of social media (right?) and that products could benefit from listening to it (yes?), the question is: how do you get that information to the right people in the organization?

Therefore, I propose a few questions that I’ll follow up with more detailed posts:

• How can we tell the difference between a prominent, whiney customer, and other problems that affect the more subdued masses?
• How should feedback through social media channels be communicated to the right people in an org?
• Why should product managers think about PR/marketing while they’re writing specs?
• (and the flip side) Why should PR/marketing demand to be involved in the spec writing process?
• How do marketers walk in the shoes of product managers without stepping on their toes and vice-versa?
• How should product management use social media to communicate with customers?
• How should marketers get more in tune with the product to be even more effective with social media?
• Why should PR people know about the product development process?

This list is really only the beginning and represents my product manager-focused view of the world.  I’d love feedback from marketers, developers, PMs, CEOs, and social media experts. As with any process, this is an evolution: techniques will be tried out and some will survive, some will fail, and others will be amended with improvements learned from trying.

Let’s work together to bridge this lacuna (see Julie's "Mind the Gap" response) so our products benefit from this phenomenal new source of customer feedback.

Follow me on twitter!

User Studies find problems, not solutions

When a usability professional is making a presentation to a homogeneous group of executives, developers, and designers, the following questions/comments often come up:

• "Oh, since that feature tested poorly, we should take it out"
• "Since users had a problem with feature x, we should do y."
• "Hmmm, so the feature didn't like that aspect of the product.  What would they have preferred?"

All of these statements presuppose that a user study should find product solutions.  Users are not product designers and the most you can reasonably expect from them is that they'll articulate (with the right coaxing) their problems. 

Sure, useful suggestions often come out of usability tests, naming can be refined, and features can be tweaked.  Whenever that happens, it should be counted as serendipity, not a core outcome of the study.

User studies should aim to discover user goals and understand problems that arise when a user tries to reach those goals.  Usability tests should uncover feature-specific problems.  Once all of these data are amassed, it's up to the creativity of the design and product folk to use these constraints to create a new solution and then test the improved solution with more testing.

Users are your customers, not your designers, so don't overwork them.

Product Messaging Document Basics

Creating a product messaging document shouldn't be that hard.

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 what problem you are going to solve for a group of users.

Messaging discussions tend to fall on two sides of a spectrum.  On one hand, nebulous high-level jargon and endless wordsmithing of simple phrases 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 document look like when it's done?  There's no one-size-fits-all messaging document or process that will solve every situation among different companies, products, and situations, 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. (But adapt it to your needs) - Don't take the template as fiat.  Feel free to absorb the spirit of the document, even if you don't accept all of the details.
5. 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).
6. Avoid meaningless words - This is a corolary 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 that makes sense to a person on the street.  Your product is not so complicated that you can't explain it to someone else.
7. 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.

I'd love to hear from other people about other general guidelines and great templates of messaging documents.

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.