Global Moxie

Photo by Artiii.

My favorite recent feature in Big Medium was hardly ever requested by customers. It barely even came up. The easy conclusion would have been: Nobody wants it, and building it is a waste of time. In fact, that was my conclusion, but I was wrong.

Big Medium 2 now has basic version control. You can review the edit history of any text on your site. Don’t like a page’s latest changes? Roll back to an earlier version. It’s a super “undo” for your website.

Even though this feature never even registered on the customer-request index, I have a hunch that people will love it. If I’m right, it’s an object lesson for anyone who makes stuff or provides a service: Don’t rely exclusively on customer feedback for product development.

Keeping content safe

Versioning has been kicking around my to-do list for, I dunno, a couple of years. Despite the obvious utility of this feature, it’s one that I shoved to the back burner, since nobody was asking for it. Can’t be too important, I figured.

Two weeks ago, Deane Barker of Gadgetopia and Blend Interactive asked me to take a peek at a draft of his now-published article, “What Makes a Content Management System?”

I questioned his inclusion of versioning as a “must-have” for a content management system. After all, I consider Big Medium to be a pretty excellent CMS and, um... *cough*... no version control. Hey, I told him, nobody even asks for it. How can it be a must-have?

Deane answers succinctly and persuasively in his article: “Managing content is largely concerned with keeping it safe, and making sure old versions are recoverable is a big part of that.”

Huh. Right. Turns out versioning isn’t just some feature, it’s basic to what Big Medium is supposed to be doing for you. Lost track of that somewhere.

Your product’s fundamental promise

Photo by abbyladybug.

What does your product or service do? I mean really do, at the most fundamental level? What promises does it make? In the end, making sure that you keep and exceed those promises is much more important than fulfilling glitzier feature requests.

Big Medium’s promise is to manage content. It has to store it, protect it, make it easy to retrieve, format it in useful ways, relate it to other content. That’s the whole thing. Big Medium does a swell job at most of this, but I realized that outside of its permission and workflow features, the app was a little weak on the “protection” angle of its promise. It does need version control.

The new feature strengthens Big Medium’s core promise and, I expect, will give my customers additional peace of mind about the safety of their content.

Suggestions and distractions

Just as soon as a product gets a following, it also gets requests, suggestions and criticisms. And that’s great. That feedback is the foundation of community, signaling the interest, even passion, that your product inspires. Feature requests show that customers have a stake in your product. Feature requests are awesome.

A high volume of feature requests presents the obvious challenge of sorting out which ones are the gotta-haves. But there’s also a less obvious and more important challenge: making sure that you identify the important features that are not being requested.

That’s where the opportunity lies to surprise and delight: Find the way to solve a problem that the customer has absorbed as a fact of life, a pain they’ve borne so long they don’t even realize it’s there anymore. Those opportunities rarely present themselves as feature requests, as Kathy Sierra wrote:

Our users will tell us where the pain is. Our users will drive incremental improvements. But the user community can’t do the revolutionary innovation for us. That’s up to us. The world never needed the iPod until Apple created it. Now, look how many of us could not live without it. … The world never needed GUIs. Or digital cameras. Or cafe mochas. Or skateboards. But I have a hard time imagining my life without those things.

I don’t pretend that Big Medium represents the kind of “revolutionary innovation” that Kathy describes, but she’s getting at a good general principle of product design: Trust your vision. Listen carefully to your customers, but carve out the time to step back and review the fundamental goals of your product or service. “How can I help customers with those goals in ways they haven’t even considered?”

You’ve thought about your product more than anyone else. You know where its untapped potential lies. It’s important to stay true to your own goals for it. You have a better line of sight than your customers, as Kathy wrote in another essay:

In the end, we have to trust ourselves. This is a controversial position—we’re not supposed to be building things for us... it’s not about us. But that doesn’t mean we aren’t the ones who can make the best overall decisions. We’re the ONLY ones who get all the feedback and can think through the long-term implications, and can see how pleasing one user group might piss off another group, so which group do we choose?

Leaving stuff out

Photo by oli bryant.

Giving preference to my own feature ideas over customers’ requests turns out to be a hard thing to do. It’s telling my customers no (or at least “wait”), and at the very root of my personality, I always want to say yes.

The importance of saying no is the most important lesson I’ve learned since I started this fandango. One of Big Medium’s strengths is its focus. The software doesn’t try to answer all possible problems or build all possible websites. This makes it easier to use for the sites it does support.

Decisions of what to leave out are even more important than what to put in. I’m just one guy, and I can’t compete with larger companies or open-source projects in a feature arms race. Where I think I can compete is in taste, empathy, customer service. I can make software that’s pleasant and fun to use, that solves a specific set of problems very well. My goal is a tidy feature set, executed with elegance and supported with competence and good nature.

It doesn’t matter how much a product or service does if it doesn’t address customers’ problems elegantly. The gang at Rogue Amoeba Software captures the spirit:

We need look no further than Microsoft Word to see that it’s easy to add lots and lots of things. There’s a great word processor buried in there somewhere, but each and every user has to work to dig it out from under the 80% of features they’ll never use. Instead of this jambalaya style of design, we strive for a simpler, more elegant (and Apple-like) approach. Our software may not do everything, but everything it does, it does well.

So, what, don’t listen to customers’ feature requests?

Of course you should listen. Your customers are the only ones who can tell you if your product is really keeping its promises. As I wrote recently in Understanding the Piano, “Creating a technology is naturally an act of collaboration (sometimes of compromise) between maker and user. I might be the guy who actually writes the code, but it’s the way that the software is actually used that defines the product.”

In fact, information about how Big Medium is used interests me more than the actual feature requests that I receive. Don’t get me wrong, I really do dig feature requests, and many suggestions are inspired. But I’ve found requests to be most useful when I view them not as face-value solutions but as indicators of problems that need to be solved.

My job is ultimately to solve problems, not implement features.

That’s why, in explaining to customers the best way to ask for features, indie software developer Brent Simmons advises focus on the problem at hand. Want to sell a developer on a new feature? Here’s Brent’s advice:

The trick is not, as you might expect, to convince me that it’s something lots of people would want. The trick is to tell me how you would use it, how it would benefit you, how it solves a problem that you have.

Forget about other people—let me do any extrapolating. (It’s my job.) Instead, just tell me a great story about how this feature would be cool for you. …

Also remember that, lots of times, software developers pay more attention to the problem being solved than to the exact feature being requested.

What they do, not what they say

In other words, feature requests tell you where the pain is. Paying attention to those pain points leads you to the interesting features (which are not always the same as what the customer proposes). Clayton Christensen’s said all this stuff far more eloquently than I ten years ago in The Innovator’s Dilemma. He revisited it in a recent BusinessWeek interview:

You have to be careful which customers you listen to, and then you need to watch what they do, not listen to what they say. … The problem is when you say “listen to your customers,” your customers are only going to lead you in a direction that they want to go in. Generally, that will never lead you to disruptive growth.

Follow what they do, not what they say.

All of which brings me back to my humble version-control feature. It turns out that customers were asking for the feature, but not in so many words.

I got feature requests for elaborate backup routines, for “undo” on the last save, for making an unpublished copy of every page before editing it. The suggested features weren’t great, but they all attempted to solve the same underlying problem, which was best solved by a version control feature.

My customers were asking for it all along. Took me long enough to figure it out, eh?

Just keep those feature requests and criticisms coming. Sooner or later, I’ll manage to make the connections and uncover the common problems we’re all trying to solve.

Tags: bigmedium, business, customerservice, programming, versioncontrol