Delivering a Useful Product

“If you’re not embarassed by the first version of your product, you’ve launched too late.”
Reid Hoffman – Founder, LinkedIn

I understand that quote and in my gut, I agree with it. But it’s a really hard thing to do. Coming from a sales and marketing background, I know that you only have one chance to make a first impression. And if someone isn’t immediately impressed with your product, you may not get another chance. So how do you decide when to launch your product?

Every new product begins with a vision and ends with feature overload. At least that’s how it often seems. From Microsoft Office software to high-end sports cars, things start off simple and end up so complex that we often feel baffled and resent having to pay for things we don’t really want. Why does this happen, and what can we do to prevent it in the products we create ourselves?

Often it’s only in retrospect that most things appear as unnecessary features. Every new product begins with someone’s vision, and that vision is usually simple and crisp. Sometimes this vision is so remarkable that the product could never have grown out of focus groups and customer surveys. Before the iPhone people didn’t know that cell phones could be fun, they didn’t know what was possible, so they couldn’t have asked for it. Before the development of commercial flight, people didn’t know to ask for cheap tickets to exotic destinations.

When we develop a product we need to find a balance between innovative vision and useful features, and often this balance can only be determined by trial and error. We may start out with an idea of where our product will be most useful but often we discover that users find it fits a different need from the one we originally envisaged – and then we have to add new features to enhance the product’s suitability to its new real-world application. An example of this comes from the auto industry. Original four-wheel-drive vehicles were built on the assumption that the customer would use it for hauling supplies, driving across fields, and maybe taking back-country trips. So the early 4x4s were built crude and rugged. Turns out, though, that the vast majority of those vehicles from the 1990s onward were bought by people who just loved the visibility they got from the tall driving position and the sense of adventure they enjoyed from knowing that, although they’d never use it, they had some off-road capability. Once the manufacturers caught up with what their customers were valuing, they realized they needed to increase the comfort quotient and didn’t need to pursue the off-road angle. And that’s what led to vehicles like the ultra-successful Lexus RX series – a Toyota Camry with a taller body and zero off-road capability but with all the luxury features and the tall driving position that customers really appreciate. It doesn’t have low range or the capability to ford even a modest stream but it does have an iPod connector and reasonable gas mileage.

So getting a product right is all about triangulation. Start with a vision and then pay attention to customer feedback. But even this isn’t as easy as it sounds. For example, one customer might want the ability to create custom graphs while another wants integration with a relatively obscure accounting system. Yet another customer asks for the ability to pull in data for a purpose never imagined in our original vision. After a while the list of asked-for features can add up to a multi-year product release plan, so then the product team has to work out which features will satisfy most people. If ten customers are asking for integration with TicketPower software but only one is asking for the option to modify the product’s default color palette, chances are we’ll prioritize the TicketPower integration over the color change. It’s a real balance to try to build the features that are going to be important to the largest number of potential customers.

Yet even with this approach, as the years pass the challenge is to keep the product from becoming bloatware. That’s because with technology there’s usually the ability to add things indefinitely. With a physical product like a car there’s a finite limit to how many gadgets you can fit into a reasonable space. You can’t add a workbench and a fridge and a stove and a sewing room and a small personal gym to a family car. It’s just not possible. But you can add feature after feature to software because the only practical limit is the memory space of the computer you’re running it on – and these days memory is a cheap and plentiful commodity. So unless we’re very careful we’re automatically going to crowd our users with a huge pile of features, all of which have been requested and prioritized perfectly reasonably in their time.

What’s increasingly clear is that design is becoming ever-more important. If we can add features without limit then we need to ensure that users can find what they need and use it easily, no matter what level of sophistication they are at and no matter what task they are trying to accomplish. So the user interface becomes the focal point of utility. Again, the auto industry got there ahead of us. Way back at the dawn of the auto era, cars were highly variable. Each car required a period of figuring out where everything was and how it worked. Some cars even had the accelerator pedal located in the middle, with the clutch on one side and the brake on the other. Over time, the car makers realized that they should compete on useful features, not try to lock-in customers with potentially dangerous idiosyncrasies. So now, when we climb into a car, we always find the basic controls in the same place. We can focus on the high-level goal (getting to where we want to be) instead of having to struggle with low-level objectives (like figuring out where the brake pedal is located). We need to keep the same objective in mind when we develop software: make it incredibly easy for customers to fire up the product and get straight to work with it. Copy things that are standard, make all basic features incredibly obvious and easy, and create simple ways for people to find and use more complex features if they need them. To do this we need some basic Design Rules, and we’re still in the early stages in the world of hi-tech. Too often, we don’t pay attention to lessons learned. Today, as the pace of change has accelerated beyond what anyone could have dreamed possible just a decade ago, we really have to focus on the basics even as we add more and more features and capabilities to our products.

As always, leave a comment to start a discussion or email me at jlewis@brightmetrics.com

You may also like

Leave a comment