Digital innovation fails all the time, but it doesn’t have to

Most companies, big and small, fail miserably at developing digital products (we’re not talking basic websites here). They fail nearly every time they try. Digital products usually go vastly over budget and far past deadline. And when they fail to take off, their creators blame marketing, or competitive activity, or simply say the demand is not there at all. This is an insidious kind of failure where product leaders don’t know how badly they have failed, and therefore fail to learn from it. Even those who recognize their failures are reluctant to admit it or act on it, for fear of damage to their reputation or job prospects.

But the failure is in the process, not the people.

Feature density is not strongly correlated with user experience

Most teams use product innovation methodologies defined in terms of deadline, budget, and feature list. They presume that if they deliver the right features on time and within budget, all that’s left is marketing. They focus on features as competitive differentiation, and just want to “check the boxes.” But customers don’t love features; they love solutions. And history demonstrates that customers often love features you don’t expect, and don’t use the features you were certain they’d love. So, if it’s not features, what is it?

It’s about user experience

It’s all about user experience – how your customers feel about using your product. And feature rich products are often experience poor. Meanwhile, surprisingly simple and deceptively powerful products elicit delight. If your customers love your product, they’ll pay for it, tell their friends, and pine for your next product.

User experience is the totality of how customers feel about using a product

Creating delightful user experiences requires multi-disciplinary thinking, and a readjustment of traditional notions of product evaluation. The key product experience attributes as I define them are:

• Usefulness
• Usability
• Credibility
• Value
• Reliability
• Aesthetic

Which are complicated by the process of human cognition, which is primarily subconscious and involves three levels:

• Visceral
• Behavioral
• Reflective

And all of these factors are further complicated by both the physical capabilities of the user (e.g., eyesight) and the user environment (e.g., browser, network speed).

User experience is hard to predict

As a result of all this complexity, it’s difficult, even for the most intuitive and experienced product leaders, to reliably predict how users will feel about a product. In turn, it’s very hard to tell what your product must do to elicit delight. And you can’t just ask users what they want. Research demonstrates that customers don’t know what they want; they tend to focus on workarounds and minor improvements to the status quo. Even worse, if you give them what they say they want, they often don’t like it.

But user experience is easy to measure

While user experience is a very complex matter, there are directly correlated (and measurable) factors that describe user experience. For example, customer satisfaction, trial conversion rates, and virality are all easy to measure. Even such simple measurements as frequency of use and churn indicate the quality of a user experience.

Deadlines and budgets are real. Scope is not.

Even if you do measure a project solely in terms of deadline, budget, and scope, you’ll almost always fail. First of all, it’s impossible to reliably estimate the amount of time it takes to build a specified set of features. Some developers will argue this point, but historical data is overwhelmingly against them. The obvious solution is to establish fixed deadlines and budgets, and expect scope to vary. This approach also has the benefit of explicitly allowing scope to change as you learn more about customer needs. But how do you learn most effectively?

Scientific method of product development

I believe that product development should leverage the scientific method. Come up with a hypothesis–an insight about what your customer needs. Run an experiment–a test to determine whether your insight holds. And then analyze the results of the experiment to seek new insights, which lead to further experiments, and so on. The key is to explicitly identify hypotheses, choose the fastest and cheapest ways to test them, and to remain open enough to pivot as you learn from your analyses.

Most companies (big and small) are really bad at failing quickly and cheaply

Successful innovation requires failure, or more specifically learning from failure. It’s typical for companies to spend a million dollars (plus) and six months to a year (plus) to release a product, only to figure out that nobody wants it. Big companies often bull through this, either sucking up losses because the stakeholders don’t want to admit failure, or spending into oblivion until they eventually come up with some approximation of a good user experience. Small companies usually just go out of business.

Traditional user experience design is rarely right for digital products

Even the companies that focus on user experience often go about it the wrong way. They spend tremendous time and money on traditional user experience methodologies in an attempt to predict and plan user experience. They argue that it’s better to get it right the first time than it is to change a product already on the market.

But most digital products are easy to change. And it’s cheaper, easier, and more reliable to measure experience than it is to predict it. It’s also much easier to distinguish right from wrong in your user experience when it starts out simple. So get it in front of users very early, and don’t waste too much money on predicting user experience. Launch something really simple (often called a minimum viable product), and evolve from there.

Some guidelines derived from my experience

1. Prioritize user experience
2. Fix deadlines and budgets, but flex on scope
3. Explicitly test your hypotheses and embrace failure as forward motion
4. Test in small batches right from the start
5. Emphasize speed and low cost for experiments
6. The best tests involve real users
7. Practice feature Darwinism: only the strongest should survive

I’m writing a book on digital innovation, and this post covers a lot of the high level concepts I’m addressing. Let me know what you think so I can make the eventual “reader experience” as delightful as possible. I welcome challenges to my arguments and suggestions for improvement. Even better, suggest some reading or research to support or elucidate your thoughts.

No related posts.