Building successful software products is hard.

Most products fail to gain traction, leaving businesses wondering what went wrong.

Some emerging research offers us useful insights into why products sometimes fail. Let’s look at this problem in a startup setting, where it is always easier to find more data.

One fairly detailed analysis of startup failure was completed by CB Insights (Figure 1). This was unpicked in an article on Hackernoon (Figure 2). According to their research, the number one reason for startup failure was not getting the product right.

But surely technology would play a crucial part in building the product?

It does. To build a great product, you will need skilled engineering teams. Let’s compare this to building a house.

To build a house, you need skilled carpenters, joiners, roofers, painters, electricians, and plumbers. But you will also need architects, surveyors, and project managers. To truly execute a great vision, all of these people should be on the same page with a clear vision in mind. Great technologists are also important. Without a clearly mapped outcome and focus on users, great results can’t always be expected.

At MOHARA, our focus is based on the understanding that a great product should be powered by technology, delivering great outcomes for the user. The product should be at the absolute heart of what you do. A great product is a blend of understanding users, focusing on the outcome and razor-sharp technological implementation. Based on the understanding from Jeff Paton’s User Story Mapping, we created this 6-step checklist to guide you through the process of building your very own product, focused on user outcomes.

So how do you build a great product?

To illustrate this, we’ll use a recent medical tech project. We were faced with a particular problem, which involved processing subject access requests (SARs). This is where a patient requests information held on them by a general practitioner (GP). However, this data is enshrined in heavy GDPR legislation. GPs get a large volume of these requests, sometimes taking weeks to process. It can cause administrative issues for GPs and patients having to wait to receive important data.

To solve this problem, we need to ask two key questions:

• Where are the GPS and patients now in the user process?
• Where do they want to be?

When answering these questions, we need to not only think about the technology that could solve the problem. We also need to consider what we can build. What product will solve this problem and simplify the user’s journey? Technology isn’t the saviour in this example – a great product is.

Next up – come up with a set of requirements and feed it through to a software development team to build, right?

No, think about the outcomes you want for your users through the use of technology instead. We need to truly understand the pain points users are facing. This will give insight into how their overall experience is affected. In the example of GPs and their patients, it can put a strain on a professional relationship, waste time and affect medical outcomes.

Consider the bigger picture.

Look at the big picture and keep the analysis high-level. Consider the macro issues. Efficiency is the problem in this case. The process needs to be faster.

Having a hypothesis of what the problem is, we can start speaking to users. We try to understand the problem and come up with potential solutions. Start looking at how the problem can be addressed. A solution can be found in a better database or system processing, a more accessible app. You should keep in mind that every feature needs to be designed with the user in mind, meeting the designated outcomes.

Address the more challenging parts of the project first – this will allow you to detect potential problems early in the development process. Focus on building out things that allow you to spot problems early. If there are issues with the current database that can open up bigger problems, then look at those first.