10 Steps to Creating Software With a Budget
Keep it lean and keep ’em keen!
It’s the question everyone needs to ask, whether they want to or not; how much is this going to cost me? Sometimes the answer hits you hard because the sheer size of it shocks you. Sometimes it’s surprisingly low and that leaves you sceptical that there are hidden costs; the list of incurred costs at the end of the project is going to blindside you. Or maybe the sales rep lists out all the individual costs broken down and you are following along whilst working some crazy math in your head to see where you can make cuts. In other words, it’s an involved process.
Quality, future-proofed and targeted software is an investment, but it’s how we can guarantee there will be a return on investment before throwing every resource we have at it that makes it truly valuable. On the other hand, you might be stretched for resources but have an idea that is likely solvable with software so need to test this out a little more before gaining access to more resources.
We have outlined out a plan below that should get you started. We don’t hit the tools until the tail end of the plan — that’s the idea! There is a lot of upfront research, planning and preliminary work that can be done without dipping into that tight budget.
1. Understand the problem
First and foremost, for any project, product or solution design, understanding the problem is at the absolute core. There is a brilliant framework out there, that we at WorkingMouse use for every project, known as the Lean UX Canvas. This canvas will get you brainstorming the viability of the problem and answer the question: “should this be in the market?” vs “can this be in the market?” It will also guide the kind of solution needed for the problem.
2. Does a solution exist?
With 7 billion people in the world, it’s entirely possible that someone else has had the same problem as you before, and they might have come up with a solution (or tried to!) How do we ﬁnd this out? Google it! Check out what they have done and use it to your advantage.
- If there is a solution –> head to point 3
- If there isn’t a solution –> head to point 4
3. Analyse the previous solution
Use the SWOT analysis framework to gain insight into the existing solution. If you haven’t used this before, the best advice here is to keep the inputs high level and not overly detailed; even better, keep this table to one page maximum. In the example below, we have drafted a few guiding questions for each box. Answer the guiding questions with about 3 to 4 dot points for each.
Once this is completed, examine your answers and see if there are any items you can pair together. For example, if the weakness of the existing solution was that it was over-complicated and the core functionality was littered with useless features, that’s an opportunity where your solution can be competitive!
4. Evaluate why a solution doesn’t exist
From your research, ﬁnding that the solution doesn’t exist as a product currently (or previously), doesn’t necessarily mean people haven’t tried to solve this problem before. Dig a little deeper into their trials and tribulations of product development — it might help you more than you think.
Acknowledging that this is a gap in the market is satisfactorily validating your problem statement. The next thing is to ﬁnd the user group that this problem needs to be solved for.
5. Crowdsource initial feedback
Cast the net wide, as they say! Put the problem out there to continue the validation process. Check out the company Askable. They have a great way to ask a bunch of people what they think about your problem and ideal solution through crowdsourcing. Using a platform such as the one Askable offers, enables you to get real-time, ﬁrst impression style feedback from a wide audience. Keep in mind that this solution might not be the answer for everyone, and that’s okay. Take the constructive side of it and examine the feedback that is coming in:
User feedback is crucial at any stage of a project, as we know from our previous article, Product Led Growth. Understanding the user group/s time and time again propels the success of an application.
6. Discovery interviews
From the initial crowdsourcing feedback, you will be able to get a sense of the kinds of people who will likely use this solution. They become your user group. With this user group in mind, conduct discovery interviews. This interview style is designed to tap into the pain points of the user groups and continue to unpack the problem even further to ﬁnd its core. Remember, we are keeping this application lean, so the focus needs to stay on the core problem and designing the solution around that. Channel your inner Simon Sinek ‘start with why’ attitude for these interviews — but if you get stuck, there’s a bunch of templates online, like this one from Kromatic.
7. Create the user persona
Once you have gone beyond identifying the users as a group and understand them in more detail, it is time to create a persona. Every element of the persona should be articulated and speciﬁed. It’s not a generic overview, it is the consideration of each detail of that person (Adobe XD). There are so many tools out there to get you started. The digital whiteboard software, Miro, has an amazing template here for this.
8. Strategise the business case
It might seem we are ready to hit the tools, but there are a couple of remaining items to action before booting up the PC. This step is designed to unpack the seriousness of the software within the business. This step doesn’t need to be a 50-page document but start to put the pieces together of how this software will not only help the people you interviewed but will actually solve a problem for a wider audience.
9. Develop an MVP
Firstly, let’s get some definitions sorted.
- MVP — minimum viable product. This is the leanest version of your product. It goes without saying, if the budget is staying lean, the output should too!
- MMP/F — minimum marketable product/feature. This avenue can taint the goal of the project to be more about the return from the application over the needs of the users (i.e., not solving the problem)
We want to create the MVP because this opens the feedback loop and learning cycle quickly without getting caught up in the unnecessary, albeit pretty, features. An MVP isn’t supposed to be polished — it is supposed to provide a solution to a problem at a base level.
Developing an MVP in software can be tricky, so I would definitely recommend hitting up a digital agency who can tailor the project to meet MVP requirements (top tip: we do!)
10. Release! And test…then release again! And test…(repeat)
Release your MVP and start to gather feedback. It is important to test this out with a slightly larger audience than your initial interviewed population size. This feedback could be centred around the design of the application, the user journey (how people use it) or it could be about the concept in general (i.e., the solution to the problem). Gathering this feedback and acting on it to iterate the MVP continues to validate the solution design.
With this well researched and validated product, alongside your business case and positive user feedback, you have something ready to present to (potentially) get that budget you need to create the application with all the fancy features.