Tag: just ship it

Agile Marketing, Customer Development, Customer Strategy, Innovation

Customer Experience is Not Rocket Surgery

Posted on by gregmeyer
image courtesy of http://flickr.com/photos/stickergiant

Let’s get this straight. Rocket Surgery doesn’t exist. It’s a made-up term combining two things people think are hard: rocket science and brain surgery. It sounds so hard that no one would even believe that a Venn Diagram of these things could even exist (or maybe it would just be strange, like that feeling you get when you see someone on the street these days riding a Segway.) But Customer Experience does exist.

And one of the great problems with Customer Experience (capital C, capital E) these days is that there is a “Right Way” to do it. (And a wrong way.) Please don’t mistake this rant as a screed against those who try to learn what customers want to do and to help them achieve it. I just want to point out that when we (the Royal We) have the feeling that “Customers Don’t Get It” and that “They are doing it wrong” and that “They don’t know what they’re talking about” we’ve really missed the point. Because customers are the reason that we are here.

So here are a few modest ideas to make your Customer Experience feel less like Rocket Surgery (or whatever acronym you might have in your environment that sounds sort of like that made-up term):

  1. Get Out of the Building – this is a classic, shared by Eric Ries, Steve Blank, and a host of others as a cardinal rule of understanding your customers. Go talk to them – in their environment – and ask them what they’d like to do that they can’t do. And instead of telling them what they should do: just listen.
  2. Create Random Acts of WOW – The next time a customer makes a reasonable suggestion, just ship it. Don’t worry about the impact to the schedule, the placement on the roadmap, or anything else like that. Just trust that if one customer made the suggestion, there are 10 more (or 100) that you haven’t talked to yet who feel the same way. And it doesn’t matter to them if it’s done perfectly.
  3. Make a list of “cringe-worthy” experiences – like the “broken window” theory of policing championed by former NYPD police chief WIlliam Bratton, the basic idea of capturing and eradicating bad experiences one at a time starts with finding and cataloging those experiences and asking yourself if you would put up with them as a customer in your own product. You may not have the equivalent of an annoying Squeegee guy asking you for a buck, but you know what I mean. Find and remove more of those cringe-worthy experiences, and your product will be better.

So delivering customer experience is not hard. It’s not brain surgery, rocket science, or rocket surgery. But it is harder than just hoping that problems get solved. It involves identifying small things that your customers care about, identifying ways to move beyond those problems, and the ability and will to deliver them unexpectedly that turns a mediocre experience into a potentially great one.

2
Agile, Marketing Strategy, Product Thoughts

You know you’ve made progress when users say, ‘it’s better!’

Posted on by gregmeyer

Just Ship It

This is the fourth in a series of posts on Agile Marketing – the working definition of which is to “Create, communicate and deliver unique value to an always-changing consumer (or business) in an always-changing market with an always-changing product.” See the original post here. We know that we’re always promising something along the lines of “I think that will be shipping with our next release.” The best way to help your Agile Marketing efforts is to Just Ship It.

Agile Marketing Principle #4: Working Software is the Principal Measure of Progress

People only know that you’ve made progress when they can see for themselves how things have changed. Notice that the headline above doesn’t say “finished software,” but instead says “working software.” This is a critical notion that makes some product managers quite nervous because they measure progress by looking backwards after they’ve finished, not by measuring whether users can achieve the tasks and stories the users want to do with the “not-quite-finished” software.

Working software generates progress because people can measure the difference between how they want to use the software and what it actually does. Even though the rounded corners on the UI may not be done, the point at which the software works (or alternately, requires the user to do something that doesn’t make sense to them) is the key turning point that drives user adoption. (Note: you might need to finish your software to the nth degree to make your users ecstatically happy. But I don’t think that rule applies to the 80% of users who only use 20% of your features.)

If we accept that working software is the principal measure of progress, it means that both internal and external users of your software need to know how things are supposed to work for the most common use cases and why they work that way. It also means that fewer, more easily understood features usually trump increased functionality and edge cases (for the 80% “good-enough” user). Finally, when you do deliver “the next version” of the feature, it will feel like incremental, easily understood progress to the user, rather than a brand new set of cases to learn and master.

How then, can you make “the way things work” most consistent, understood, and discoverable? You can increase consistency in your product by having a glossary of terms and actions, describing both the nouns of your product (what is that thing I’m looking at?), the verbs (what should I be trying to do here?), and the overall grammar (now that I understand what it is and what it does, how can I make a new activity with that thing and expect it to turn out in a way that seems familiar?).

You can make the product better understood by asking, speaking with, and listening to your customers. It’s neat that a team can find really great ways to use its own product, but if the customer (because the customer is not you) can’t figure out what they’re supposed to be doing or how to do the things they want to do, your product will never gain wide adoption (which, by the way, might be ok if you price it correctly.) Also, figure out the easiest ways for your customers to get help (it’s usually to call or email you directly.)

Consistency, discoverability, and ways to get help – then you can ship even when it’s working, but not yet finished. And use your customer feedback to take it from working to finished – you’ll know and your customers will know how you are progressing if the software you deliver just works (or is very clearly described so that they can make it work)

0