Build Experiences, Not Features


We’ve seen it, or experienced it, too many times before.  A product with great features that just don’t work well together.  As a user, it frustrates you that the simplest, most obvious action cannot be easily done.  If you’re invested enough and savvy enough, you search for shortcuts, hacks or some type of solution to improve your disjointed workflow.  Whether you find one or not, you’re still left with a bad taste in your mouth.

Features vs. Experiences

What is an experience?  In product terms, it’s about giving the user an enjoyable session while interacting with your product or service. It’s more than functionality.  It’s elegance, delightment and a little bit of magic.  It makes your user’s activities effortless.

Why are experiences important? 

In short, you care about experiences because you want your users to come back and use your product or service again.

In the new world of cloud services and enhanced SAAS offerings, the upfront investment cost of a service has significantly been reduced making the cost of switching products or services affordable.  Gone are the days of users needing to provide an upfront investment with a multi-year ROI on a product or service.  Back in those days, having a robust feature set was extremely important since the buying decision was usually based on a feature-based comparison with an eye on longterm value based on feature-set.  A user would opt for a more robust feature-set to ensure that their choice (and investment) is still valuable for years into the future.  Users decided that this perceived future value was more important than the user experience.  This led to products and services that focus on a breadth of features and not on the user experience.

Now-a-days, a user can change their mind on service offerings more frequently than they change their underwear. Users are more willing to pay a recurring fee to avoid up-front costs.  With that recurring fee comes the promise of a continuously improving service.  From the service provider’s perspective, comes the prospect of recurring revenues – a dream for most companies since recurring revenues translates into predictable revenue streams. However, with all of this comes a reduced upfront investment cost and in turn a reduced cost of switching to another service provider.  With the low cost of switching, the service provider needs to give the user a reason to come back.  So in addition to a relevant feature-set, the provider must also provide a compelling and delightful experience.

How do you build an experience?

It’s quite simple really.  To build an experience, you need to give users what they want… or better yet, what they don’t know they want yet.  Clearly, this is easier said that done. As Steve Jobs once said, “A lot of times, people don’t know what they want until you show it to them”.

However, there are some strategies that you could employ to help.

The Product Guy

The key to understanding what people want, is to measure their responses.  That requires two main items to be worked out: (1) what should you measure and (2) how do you measure it.  Depending on your industry, what you should measure may be evident.  You’ll need to scrutinize the main drivers of your industry, business and target customer.  It would be really hard for me to give any specific guidance on what needs to be measured in generic terms. What you will need is someone who deeply understands your industry and customers.

The advice: Hire a great product person with extensive experience in the industry.


Once you know what you need to measure, the next step is to actually measure it.  While building software, most people don’t think about measurement upfront and consider in as an after thought.  Why wouldn’t you? You only have to worry about measuring once the product or service is deployed, right?  But that is the ultimate pitfall.  Measurement is a difficult and costly thing to do in a manual manner.  If you think about your measurement needs during the early product development phase, then you could instrument your software to do the measurements automatically, giving you instant and realtime feedback on your key measurement areas.  You can then used this data to make decisions on how to change or expand your service offering.

The advice: Plan and design for instrumenting your code early on.

The suggestion box

In the digital world, this is a service like GetSatisfaction.  You need to allow your customers to tell you what they want and what their pain points are.  In addition, you actually need to read and respond to that feedback.  If your customers believe that their feedback is being ignored, then they will very quickly stop providing it — which is usually followed by abandoning the associated service altogether.

The advice: Respond to all feedback.  Yes, all of it!  This is a job for someone at your company to be responsible for.  You can file it under market intelligence, product management, customer support or public relations because it is really all of those things combined.

Fail Quickly

When building something entirely new, it’s almost a certainty that you’re going to get it wrong at first.  It’s never been done before, your customers don’t know what they want and you don’t know how to build it yet.  So what you need to do is get your idea realized and into your customer’s hands as soon as possible. Why? So they can tell you that it’s all wrong — then they’ll tell you how they would like it to work.  Once you update it to work that way, they’ll tell you it’s wrong again.  And you do it again.  Get the point?

This constant and inevitable cycle happens during any new product introduction.  It’s how concepts become prototypes then a full-fledged service — and if done right, it becomes a success.  So you want to go through this cycle as quickly as possible.

The advice: Adopt an agile development and deployment model that allows for the quick creation and launch of the service.  It’s key to note that the deployment needs to be as quick as the development or your value realization of any built product is delayed.  Build an infrastructure that supports this model from the get-go.

Combining these four pieces of advice early-on in your product development, mixed in with a little bit of luck, you’ll be able to build more than just the features your customers want, but the experiences that they didn’t know they wanted yet.




Leave a Reply