When you are building software there are risks everywhere. Are stakeholders committed? Do you have the right mix of skills in your team? Do you understand the problem /scope well enough? Do you have enough money? With so much to get right, things often go wrong. Digital projects have failure rates between 29% and 9% depending on whether you are following a Waterfall or Agile implementation approach respectively.

A 29% failure rate is ridiculously high but it is not the biggest risk in software development

Outright failure is a pretty bad outcome. You have lost all of the time and money that you have invested - what could possibly be worse than that?

Even with failure rates as high at 29% it means that 71% of projects don't fail. But that doesn't mean that they are successes either. Most products are released when they are good enough. Customers can use them but they don't solve the customer's problems fully. They are functional but not lovable.

Whether this is a good or a bad situation actually depends on the processes and the mindset of the team behind the product. If the team are investing in UX upfront to understand their customers and their problems, validating assumptions with real customers and continuously improving the product based on the each iteration's feedback then it doesn't matter if the product isn't great yet - because the team know where the problems are and they are working on it.

Unfortunately most teams don't work like this. Software is primarily delivered in projects. Teams are formed based on the scope of the work and they disband when the project is finished. There is no time to get intimately acquainted with the customers because very soon you could be working on a completely different project. Success is measured based on whether the software was released within planned time, cost and budget and not on the value delivered. In theory there should be a benefits realisation analysis on the product but this both rarely happens and isn't acted upon. In fairness, tracking the benefits isn't straightforward. It is simpler when you are dealing with a brand new product (baseline is 0) but in the majority of cases teams are enhancing an existing product. You could track whether sales increased or decreased but it is very hard to exclude external factors. Did sales go up because more people were coming online? Did they go down because a competitor released a product?

Recently with fine grained A/B testing it is now possible to validate the effect of new features. Microsoft did some detailed analysis of success rates in the market as well as on their Bing platform and the results are not good. Up to 33% of features developed had no impact on their key metric. Even worse, up to 33% had a negative effect on their key metric.

66% of features deliver no, or negative, value

A/B testing works best when you can learn from the outcome. Which means you need to think about the assumptions that go into the tests, which again means that you need to be thinking deeply about the customers' problem and how you can solve it. In the example above the team aren't around long enough to learn the intricate details of their customers and their problems. And once the software is delivered they move on without learning whether it was successful or not.

Waterfall is a concerted effort not to learn while delivering software

But how big of a problem is this?

As part of the UXDX Community events we always ask an opening question on the biggest challenges that companies face. I have now met thousands of people from hundreds of companies and over 70% of people flag the problem that there is "Too much focus on features and not enough on user research and solution validation". Unfortunately this means that the most companies skip the research, experimentation and validation steps. Features are formed as part of internal whiteboard sessions and they are never validated after release.

66% of features delivered provide no, or negative, value and over 70% of teams feel they aren't investing enough in customer research in order to learn what is working or not. Combined these two paint a bad picture of the health of product development.

This lack of understanding of what customers want and what features are working is what leads software to bloat over time. New features get added but the features that aren't working don't get removed. As software becomes more complex it get laden with technical, design and product debt. That debt could be paid down but who pays for it? It is like the tragedy of the commons - each of the projects rely on a healthy code base but none are willing to invest in it. Subsequent changes become more and more expensive until the organisation decides to embark on the "Big Re-write". Throughout this time teams are paying the initial upfront costs, plus the maintenance costs which increase exponentially over time due to the technical, design and product debt that accumulates.

With failure you have no on-going costs. And after the failure you are free to start again - hopefully having learned something so you don't repeat the same mistakes. With bad products you have to keep maintaining them.

The biggest risk in software development is building something that people don't want

Do bad products really lose money?

If people are able to use/buy from your product then its still making money. It is better to have the software out there earning money than not. So even if it is not optimal how can I claim that it is worse than failure?

Failure makes everyone painfully aware of where their shortcomings are. Ok products mask them. When your products don't really meet your customer's needs you open yourself up to competitors who can perform better. All companies nowadays are software companies, whether they realise it or not. As the industry matures software companies are branching out. Apple is working on a self driving car after having conquered the phone industry, Amazon are investing in supermarkets, Alphabet are working on thermostats and door locks, Netflix are creating content and everyone seems to be getting into health care. There is no industry that isn't being challenged by lean, software startups or well funded competitors.

The big question is can traditional companies become better at software quicker than software companies can become better at their industry?

So what is worse than losing all of your money in a failed product? Launching that product and giving your customer's permission to look elsewhere.

Why is it hard for traditional companies to build software?

The rate of change caused by the internet is much higher than when most established companies were created. The most efficient way to structure a company in a low change environment is the functional structure: separate departments for sales, marketing, finance, operations etc. Periodically projects would cut across departments, such as a new product launch, but these were infrequent. Therefore collaboration between departments was less important than the efficiency within each department.

We are not in a low change world anymore. In order to move fast you need to replace the traditional functional structure with dedicated teams filled with people from all necessary functional areas. These teams own the products that they are building and they are responsible for their success. Startups fall into this structure not through design but just through a feature of their size. But this happy accident means that they can move faster. The digital startups have seen the value in this structure and have been diligent in maintaining it even as they have scaled.

So in order for traditional companies to compete they need to shift how they think about product development. This isn't easy but it is possible. Organisations need to unlearn the ways they worked in the past in order to create the environment that teams need to succeed. There are three core ingredients to ensure success - the motivation to change, the skills and ability of the teams on the ground and the ability of the organisation to enable the teams.

We've created the UXDX conference to help companies navigate this path from projects across functional boundaries to cross functional product teams who are empowered to deliver. Our conference targets all three areas with motivating case study presentations from the leading companies, hands on training on the latest best practices and techniques for organisations to set up the governance structures required to enable autonomous product teams.

Find out more about how UXDX can help you.