The most expensive way to build software

Low code, MVPs and agile development: There are so many tools that promise to make the creation of software cheaper and faster. 

All of these approaches do not provide the solution to one key challenge. No matter how fast your development is, no matter many features you are able to build within a week:

The most expensive way to build software is to build something that your customers will not use.

It may sound obvious – but if this challenge is so clear, why does it happen all the time?

Building  solutions or features  that are not being used is not only expensive – it is also very, very widespread. Some hard facts:

One of the earliest studies on this topic was presented at the XP 2002 conference claims that 80% of features requested by stakeholders are rarely or never used. 

In a study performed by platform vendor 1E in 2016, the spendings on unused software was calculated to be 247$ per employee or a staggering 28 billion dollars per year in US enterprises.

A study conducted in 2019 by software statistics platform “pendo” gave similar results: 80% of all features developed in the average software product are hardly ever used, estimating the waste to be around 29.5 billion dollars per year.

If you find these numbers surprising, just think about it for a second: If would walk up to the average office employee’s desk and would be allowed you to have a look at this employee’s start menu:

  • Will you find software solutions that this user has maybe tried out, but then never came back to use them?
  • Will you find major features within their often expensive tools such as SAP, that this particular employee has never, ever used?
  • Will the IT department hold licenses on stock for some software that they never rolled out, because hardly any employee ever requests them?

The answer to all these questions are likely to be: yes, yes and yes. 

Now that you know the problem, what do you do about it? Here are three major reasons why users don’t use your software:

Reason 1: It does not solve their real problem

Have you ever downloaded an app that should solve a specific problem for you and the way the tool worked was okay, but slightly “off”?

Maybe it did work well, but you were missing one major requirement? If the users of your own products have a similar experience, your development spendings are wasted.

Only by understanding the expected product behaviour, understanding the outcomes that the customer expects from your product, can you be sure to solve a real customer problem with your solution.

Reason 2: The user does not understand it

Maybe the new version of your software contains everything necessary to provide a good solution to a customer problem – however, you still see no adoption by the user. How come? 

You might investigate and find out that most users do not find the button to start the process, since your stakeholders had at some point decided to place it in a settings dialogue that only few users ever access (yes, this is a real life example). 

It might also happen that the user simply does not understand how the new solution works and gives up quickly. Just as much as we all overestimate how much other people understand our thoughts and intentions, we also overestimate how much people understand the solutions we want to offer. 

Reason 3: The user cannot use it

There may be several reasons for this: A significant number of your potential users could be  using the wrong operating system or have a machine too weak to  handle your product.

In B2B environments, there may also be the reason that they want to, but are not allowed to use your product. This might be due to security policies such as certain languages or frameworks being disabled, certain operating systems not being allowed, or certain ways of ordering or paying for your product not being provided, just to name a few reasons. 

What to do about it:

In order to make your software development more effective, you need to make sure that your customers will actually use your new features. Only if your product is valuable to the user, and is understood by the user, will your development efforts be worth the money you have spent on them. 

Meeting all these challenges is complicated and, no doubt, hard to master.  But there is a solution.

Here is a way that I has, over years, proven for me to be working:

3 steps to ensuring usage in your products

Step 1: Establish a needs first approach

In order to Identify the real value for the customer, you need to identify customer “outcomes”. These are the conditions under which your customer will be satisfied with your product. 

You do this by investigating customer needs. Ways to do this could be the “jobs-to-be-done” approach invented by Clayton Christensen, Tony Ulwick’s outcome-driven innovation (ODI) or the continous discovery process promoted by Teresa Torres, just to name a few.

Just having good “ideas” or gathering “input”  from key customers and acting on it is not enough to understand what really makes the customer use your product. 

I have described this process in detail on my new website: www.needs-first.com

Step 2: Set your success metrics based on customer needs

In order to build products and features that customers will really use, it is essential to identify the outcomes your customers expect when using your product. 

Here is an example from my own experience: 

In 2009, I had the task of building a job platform for the real estate industry – a website where employers can post their job offerings and potential employees can search for them. 

Now, the value that a job platform has for employers, which makes them pay a four-figure sum for the placement of a single advertisement, is to create high coverage for their job ad in the target group. They want as many people as possible to see their advertisement.

The success measures for such a website sound easy, right? For example, let’s measure the:

  • Visitors on the page
  • Average views of the advertisements
  • Number of applications per advertisement

It seems easy as 1, 2, 3… because after all, your paying customers would be all the happier, the more applications they get for their job advertisements, right? Wrong!

If you only look at some basic measures, you might easily miss the reasons why your customers are not happy with your product.

In this example: of course the employer wants as many applications as possible when posting a job advertisement. But only from  candidates who are qualified. 

Any candidate who applies, but is obviously not qualified for a specific job, increases the work load  for an HR department, because the candidate must be tracked and turned down politely, without ever having a chance at getting the job.

So, better success measures would be: 

  • Visitors from the target group on the page
  • Average views from potential candidates 
  • Number of qualified applications per advertisement.

This example shows how only a deep understanding of customer needs can result in a highly competitive product.  Missing out on this kind of understanding will lead your efforts to fall into the 80% of unused products. 

Step 3: Establish goals-based communication

Once your goals are defined, the challenge is to keep the focus: Once your todo-list is written and the development has started, it is easy to lose sight  of the goals you started with. I’ve seen it a hundred times, and it is all too human. 

It is essential that your teams not only “commit” to the goals defined  or to “agree” on them. They must actually follow them in their daily work and update them constantly.

Here is what to do:

Keeping track of your goals via OKRs (Objectives and Key Results) can help you install a framework that enables you to keep an eye on the metrics that really matter.

What are your ideas and thoughts on this topic? Please let me know via LinkedIn!

Article photo by Ron Lach from Pexels