It’s the question that everyone must ask, whether they like to or not: how much will this cost me? Sometimes the answer hits you hard because the magnitude of it astounds you. Sometimes it’s surprisingly low, which makes you suspect that there are hidden charges; the list of incurred costs at the conclusion of the project will catch you off guard. Or maybe the sales agent breaks down all the individual prices and you’re following along while doing some crazy arithmetic in your brain to see where you can decrease costs. In other words, it’s a timeconsuming procedure.
Quality, future-proofed, and targeted software is an investment, but how we can ensure a return on investment before pouring all of our resources into it is what makes it really valuable. On the other side, you may be short on resources but have a great concept that can most certainly be solved using software, therefore you’ll need to try it out a little more before gaining access to more.
We’ve outlined a strategy for you below that should help you get started. That’s the goal: we don’t use the tools until the very end of the plan. There is a lot of upfront research, planning, and preliminary work that can be done without breaking the bank.
1. Understand the problem
Understanding the problem is at the absolute heart of each project, product, or solution design. The Lean UX Canvas is a great framework that we at WorkingMouse utilise for all of our projects. This canvas will help you think about the problem’s viability and answer the question “should this be in the market?” vs. “can this be in the market?” It will also direct the type of the problem-solving solution required.
2. Does a solution exist?
With 7 billion people around the world, it’s quite possible that someone else has faced the same problem you have, and they may have found (or attempted to find!) a solution. How are we going to find out? Look it up on the internet! Take a look at what they’ve done and put it to good use.
- If there is a solution –> head to point 3
- If there isn’t a solution –> head to point 4
3. Analyse the previous solution
To get insight into the existing solution, use the SWOT analysis framework. If this is your first time using this, the best advice is to keep the inputs high level and not unduly detailed; even better, keep this table to one page maximum. We’ve written a few guiding questions for each box in the example below. Answer each of the guiding questions with 3 to 4 dot points.
Examine your answers and see if there are any things you can pair together after this is done. For example, if the weakness of the existing solution was that it was overcomplicated and the main functionality was littered with unnecessary features, there’s an opportunity where your solution can be competitive!
4. Evaluate why a solution doesn’t exist
Finding that the solution does not now (or previously) exist as a product based on your research does not necessarily imply that no one has tried to address the problem before. Look at their product development trials and tribulations a little more closely – it could benefit you more than you think.
Recognizing that there is a gap in the market validates your problem statement satisfactorily. The next step is to identify the user group for whom this problem must be resolved.
5. Get first feedback from the crowd
As they say, cast a broad nett! To keep the validation process going, but the problem out there. Take a look at the company Askable. Through crowdsourcing, they provide a terrific approach to ask a group of people what they think about your problem and perfect solution. Using a platform like the one Askable provides allows you to collect real-time, first-impression feedback from a large audience. Keep in mind that this answer may not be right for everyone, and that’s fine. Examine the feedback that is coming in on the constructive side of it:
As we learned in our last article, Product Led Growth, user feedback is critical at any stage of a project. Time and time again, application success is propelled by an understanding of the user group.
6. Interviews with researchers
You’ll be able to get a feel of the kind of people who would likely utilise this solution based on the initial crowdsourcing feedback. They become a member of your user group. Conduct discovery interviews with this user group in mind. This interview method is intended to delve into the user groups’ pain areas while also continuing to unpack the problem further to identify its core. Remember, we’re trying to keep our app minimal, so the focus should be on the underlying problem and designing a solution around it. For these interviews, channel your inner Simon Sinek’s’start with why’ attitude, but if you get lost, there are a slew of templates online, like this one from Kromatic.
7. Make a user persona
It’s time to create a persona once you’ve gone beyond identifying the users as a group and gained a better understanding of them. Every persona element should be articulated and specified. It’s not a broad overview; it’s a careful examination of each detail of that person (Adobe XD). There are several resources available to help you get started. Miro, the digital whiteboard software, provides a fantastic template for this.
8. Develop a business strategy
Although it may appear that we are set to go to work, there are still a few things to do before turning on the computer. This stage is intended to unpack the software’s seriousness within the business. This stage doesn’t have to be a 50-page document; instead, start piecing together how this software will not only aid the people you interviewed, but will also address a problem for a larger audience.
9. Create a minimum viable product (MVP)
Let’s start by sorting out some definitions.
- MVP stands for minimum viable product. This is your product’s leanest version. It goes without mention that if the budget is low, so should the output!
- MMP/F stands for minimum marketable product/feature. This avenue may taint the project’s purpose to be more about the application’s return than the requirements of the customers (i.e., not resolving the problem).
We want to build the MVP because it immediately opens the feedback loop and learning cycle without wasting time on unnecessary, but attractive, features. An MVP isn’t supposed to be polished; instead, it’s supposed to provide a basic solution to a problem.
Because developing an MVP in software might be difficult, I would strongly advise hiring a digital firm that can tailor the project to fulfil MVP requirements (hint: we do!)
10. Release and Test (Repeat)
Start collecting feedback after you’ve released your MVP. It’s critical to test this with a slightly bigger audience than your first interviewed sample size. This feedback might be focused on the application’s design, the user journey (how people interact with it), or the concept in general (i.e., the solution to the problem). Gathering and acting on this feedback to iterate the MVP continues to validate the solution design.
You have something ready to present with this well-researched and validated product, together with your business case and positive user feedback, to (possibly) acquire that budget you need to create the application with all the fancy features.