This is a question we get asked quite frequently. It's a very difficult one to answer when it comes to software innovation, there is no single answer and the path to success is different for everyone. However, the key to finding your pathway lies in minimising the risk of failure so you set out in the right direction.

Firstly, why do we get asked this question? It's because people often fear software development projects due to the investment required. This usually causes them to constantly question the trust that they're putting into their software developers and secondly, it causes project paralysis which damages momentum. So, how do we remove that fear around the success of a software development project? Unfortunately, there's no right or wrong answer. It can however be addressed in a multitude of different ways. In this article we will share some of our processes that work well when de-risking a project.

The Two Key Risks

There are two key things you need to be aware of when dealing with the risk of software development. Firstly, there is the delivery of the functional requirements. This is often where the product owners focus on assessing who is to develop their solution. In reality though, this comes down to technical competency and expectation management of your developers. If your developers can demonstrate this, your focus should be on the second risk, what we call the people software fit.

The people software fit is the key driver of any software projects success. Will users actually use the software that you're building? There's one key thing to keep in mind here, assumptions. Assumptions are unvalidated information that is based on what we think a person or a user is going to do or want from the software. They must be discovered and either validated or removed.

To validate and remove assumptions we have a Discovery Kit within our Way of Working. It is a series of about 30 different exercises that can be used at any point. For example, during scoping we're creating the requirements backlog and clickable prototypes that we can take to the end-users of the software. We identify assumptions to test before we actually build. We test and from those tests, we learn. We want to ensure that all assumptions are validated before we go into development so we are sure what gets built adds value to the solution.

This means we're building user designed solutions, not just a shopping list of requirements. It de-risks the project to ensure that what is built will be used. This ensures we're going to get that people-software fit as close as possible (keeping in mind that it will never be perfect). We want to make sure that we're not building unnecessary features. So, the focus is on the value of the features, not just the sheer volume of them.

So, what we'll do today is share with you three exercises from the Discovery Kit, the business model canvas, the persona builder, and user interviews. These three are probably the most important to validate your assumptions if you're considering a software development project. You can bring these results to any software developer and it will provide useful context when building the project.

The Business Model Canvas

The first exercise is The Business Model Canvas. Now, if you're running your own business already, you're probably aware of this. However, if you're creating a new product or service that is related to a software product, this might be something that you sit down and review.

We recommend that before you do the rest of the exercises, attempt the business model canvas first. This forms your list of assumptions for each area. It's like your original hypothesis. The other two activities are going to help validate the assumptions identified here.

User Personas

The next exercise is mapping out personas. Personas are the various groups of people that are going to use the software. During software development, we refer to them as our user groups. Different groups will have different goals, objectives and motivations. If you only focus on one group, other groups may not be satisfied. So, write down who they are, what their behaviours are, their goals, their beliefs and their values. In doing so, you can use that to inform both the business canvas and which users you're going to interview.

Discovery Interviews

The last exercise is discovery interviews. This is where we recommend interviewing as many people as possible from each of your personas. That could be your staff, your top hundred customers or strangers on the street. The more interviews you do, the more patterns you will uncover, and the more learnings you validate. Tim Kastelle from the UQ Business School recommends that you do somewhere between 50 to 100 of these interviews before you even embark on a project. From our experience, these are gold.

It's recommended to try a combination of qualitative and quantitative interviews. The more you know your customer, the more you know the user and the better people-software fit you're going to have.

We adopt an agile approach to building software. We scope for a period of time, build and scope again. That creates a build, measure learn feedback cycle for the minimum viable product.

Conclusion & Resources

There are also some other great resources to help. If you're in Queensland, be sure to look into Innovate Queensland. They provide a free one-hour consultation paid for by the Queensland Government with an innovation advisor. A fantastic program that gives that early stage validation and lays out other helpful resources.

In terms of workshops, you can attend one of the free Ideas to Outcomes workshops. Or if you're a female founder, there's a female founders impact program available.

So, how do you know your project is going to succeed? It's all about de-risking your path to success. If you're making sure that the user is the absolute focus of scope or development, you're headed in the right direction. Our second point, as I said before, is to validate those assumptions. Thirdly, make sure that you're feeding your learnings back into the software. You don't want to build too far into the future. We hope this has been valuable and wish you the best as you start building your innovative software.