Skip to main content

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 sur­pris­ingly low, which makes you suspect that there are hidden charges; the list of in­curred 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 fol­low­ing along while doing some crazy arithmetic in your brain to see where you can decrease costs. In other words, it’s a time­consuming procedure.

Quality, future-proofed, and targeted soft­ware is an in­vest­ment, but how we can ensure a re­turn on in­vest­ment before pour­ing all of our re­sources 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 up­front re­search, plan­ning, and preliminary work that can be done without breaking the bank.

1. Understand the prob­lem

Understanding the prob­lem is at the ab­solute heart of each pro­ject, prod­uct, or so­lu­tion de­sign. 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 so­lu­tion ex­ist?

With 7 billion people around the world, it’s quite pos­si­ble 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 so­lu­tion –> head to point 3
  • If there is­n’t a so­lu­tion –> head to point 4

3. Analyse the pre­vi­ous so­lu­tion

To get in­sight into the ex­isting so­lu­tion, use the SWOT analy­sis frame­work. If this is your first time using this, the best advice is to keep the inputs high level and not unduly de­tailed; even better, keep this table to one page maximum. We’ve written a few guid­ing ques­tions for each box in the example below. Answer each of the guiding questions with 3 to 4 dot points.

Examine your an­swers and see if there are any things you can pair together after this is done. For ex­am­ple, if the weak­ness of the ex­ist­ing so­lu­tion was that it was over­com­pli­cated and the main func­tion­al­ity was littered with un­neces­sary fea­tures, there’s an op­por­tunity where your so­lu­tion can be com­pet­i­tive!

4. Evaluate why a so­lu­tion does­n’t ex­ist

Finding that the solution does not now (or previously) exist as a prod­uct based on your research does not nec­es­sarily imply that no one has tried to address the problem before. Look at their product de­vel­op­ment trials and tribu­la­tions 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 val­i­da­tion process going, but the problem out there. Take a look at the company Askable. Through crowd­sourcing, 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 feed­back that is coming in on the con­struc­tive 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, ap­pli­ca­tion suc­cess is pro­pelled by an understanding of the user group.

6. In­terviews 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 crowd­sourcing feedback. They become a member of your user group. Con­duct dis­cov­ery in­ter­views with this user group in mind. This interview method is intended to delve into the user groups’ pain areas while also continuing to un­pack 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 tem­plates online, like this one from Kromatic.

7. Make a user persona

It’s time to create a persona once you’ve gone beyond iden­ti­fy­ing the users as a group and gained a better understanding of them. Every per­sona el­e­ment should be ar­tic­u­la­ted and spec­i­fied. It’s not a broad overview; it’s a careful examination of each de­tail of that person (Adobe XD). There are several resources available to help you get started. Miro, the digital white­board soft­ware, 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 un­pack 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 de­f­i­n­i­tions.

  • MVP stands for minimum viable product. This is your product’s lean­est version. It goes without mention that if the budget is low, so should the output!
  • MMP/F stands for minimum marketable product/feature. This av­enue may taint the project’s purpose to be more about the ap­pli­ca­tion’s re­turn than the requirements of the customers (i.e., not re­solving the prob­lem).

We want to build the MVP because it immediately opens the feedback loop and learning cycle without wasting time on un­nec­es­sary, 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 re­quire­ments (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 in­ter­viewed sample size. This feed­back might be focused on the ap­pli­ca­tion’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-re­searched and val­i­dated prod­uct, together with your business case and positive user feed­back, to (possibly) acquire that bud­get you need to create the ap­pli­ca­tion with all the fancy fea­tures.