10 Steps to Creating Software With a Budget

SOFTWARE DEVELOPMENT

Keep it lean and keep ’em keen!

It’s the ques­tion every­one needs to ask, whether they want to or not; how much is this go­ing to cost me? Sometimes the an­swer hits you hard be­cause the sheer size of it shocks you. Sometimes it’s sur­pris­ingly low and that leaves you scep­ti­cal that there are hid­den costs; the list of in­curred costs at the end of the pro­ject is go­ing to blind­side you. Or maybe the sales rep lists out all the in­di­vid­ual costs bro­ken down and you are fol­low­ing along whilst work­ing some crazy math in your head to see where you can make cuts. In other words, it’s an in­volved process.

Quality, fu­ture-proofed and tar­geted soft­ware is an in­vest­ment, but it’s how we can guar­an­tee there will be a re­turn on in­vest­ment be­fore throw­ing every re­source we have at it that makes it truly valu­able. On the other hand, you might be stretched for re­sources but have an idea that is likely solv­able with soft­ware so need to test this out a lit­tle more be­fore gain­ing ac­cess to more re­sources.

We have out­lined out a plan be­low that should get you started. We don’t hit the tools un­til the tail end of the plan — that’s the idea! There is a lot of up­front re­search, plan­ning and pre­lim­i­nary work that can be done with­out dip­ping into that tight bud­get.

1. Understand the prob­lem

First and fore­most, for any pro­ject, prod­uct or so­lu­tion de­sign, un­der­stand­ing the prob­lem is at the ab­solute core. There is a bril­liant frame­work out there, that we at WorkingMouse use for every pro­ject, known as the Lean UX Canvas. This can­vas will get you brain­storm­ing the vi­a­bil­ity of the prob­lem and an­swer the ques­tion: “should this be in the mar­ket?” vs “can this be in the mar­ket?” It will also guide the kind of so­lu­tion needed for the prob­lem.

2. Does a so­lu­tion ex­ist?

With 7 bil­lion peo­ple in the world, it’s en­tirely pos­si­ble that some­one else has had the same prob­lem as you be­fore, and they might have come up with a so­lu­tion (or tried to!) How do we find this out? Google it! Check out what they have done and use it to your ad­van­tage.

  • 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

Use the SWOT analy­sis frame­work to gain in­sight into the ex­ist­ing so­lu­tion. If you haven’t used this be­fore, the best ad­vice here is to keep the in­puts high level and not overly de­tailed; even bet­ter, keep this table to one page max­i­mum. In the ex­am­ple be­low, we have drafted a few guid­ing ques­tions for each box. Answer the guid­ing ques­tions with about 3 to 4 dot points for each.

Once this is com­pleted, ex­am­ine your an­swers and see if there are any items you can pair to­gether. 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 core func­tion­al­ity was lit­tered with use­less fea­tures, that’s an op­por­tu­nity where your so­lu­tion can be com­pet­i­tive!

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

From your re­search, find­ing that the so­lu­tion does­n’t ex­ist as a prod­uct cur­rently (or pre­vi­ously), does­n’t nec­es­sar­ily mean peo­ple haven’t tried to solve this prob­lem be­fore. Dig a lit­tle deeper into their tri­als and tribu­la­tions of prod­uct de­vel­op­ment — it might help you more than you think.

Acknowledging that this is a gap in the mar­ket is sat­is­fac­to­rily val­i­dat­ing your prob­lem state­ment. The next thing is to find the user group that this prob­lem needs to be solved for.

5. Crowdsource ini­tial feed­back

Cast the net wide, as they say! Put the prob­lem out there to con­tinue the val­i­da­tion process. Check out the com­pany Askable. They have a great way to ask a bunch of peo­ple what they think about your prob­lem and ideal so­lu­tion through crowd­sourc­ing. Using a plat­form such as the one Askable of­fers, en­ables you to get real-time, first im­pres­sion style feed­back from a wide au­di­ence. Keep in mind that this so­lu­tion might not be the an­swer for every­one, and that’s okay. Take the con­struc­tive side of it and ex­am­ine the feed­back that is com­ing in:

User feed­back is cru­cial at any stage of a pro­ject, as we know from our pre­vi­ous ar­ti­cle, Product Led Growth. Understanding the user group/​s time and time again pro­pels the suc­cess of an ap­pli­ca­tion.

6. Discovery in­ter­views

From the ini­tial crowd­sourc­ing feed­back, you will be able to get a sense of the kinds of peo­ple who will likely use this so­lu­tion. They be­come your user group. With this user group in mind, con­duct dis­cov­ery in­ter­views. This in­ter­view style is de­signed to tap into the pain points of the user groups and con­tinue to un­pack the prob­lem even fur­ther to find its core. Remember, we are keep­ing this ap­pli­ca­tion lean, so the fo­cus needs to stay on the core prob­lem and de­sign­ing the so­lu­tion around that. Channel your in­ner Simon Sinek ‘start with why’ at­ti­tude for these in­ter­views — but if you get stuck, there’s a bunch of tem­plates on­line, like this one from Kromatic.

7. Create the user per­sona

Once you have gone be­yond iden­ti­fy­ing the users as a group and un­der­stand them in more de­tail, it is time to cre­ate a per­sona. Every el­e­ment of the per­sona should be ar­tic­u­lated and spec­i­fied. It’s not a generic overview, it is the con­sid­er­a­tion of each de­tail of that per­son (Adobe XD). There are so many tools out there to get you started. The dig­i­tal white­board soft­ware, Miro, has an amaz­ing tem­plate here for this.

8. Strategise the busi­ness case

It might seem we are ready to hit the tools, but there are a cou­ple of re­main­ing items to ac­tion be­fore boot­ing up the PC. This step is de­signed to un­pack the se­ri­ous­ness of the soft­ware within the busi­ness. This step does­n’t need to be a 50-page doc­u­ment but start to put the pieces to­gether of how this soft­ware will not only help the peo­ple you in­ter­viewed but will ac­tu­ally solve a prob­lem for a wider au­di­ence.

9. Develop an MVP

Firstly, let’s get some de­f­i­n­i­tions sorted.

  • MVP — min­i­mum vi­able prod­uct. This is the lean­est ver­sion of your prod­uct. It goes with­out say­ing, if the bud­get is stay­ing lean, the out­put should too!
  • MMP/F — min­i­mum mar­ketable prod­uct/​fea­ture. This av­enue can taint the goal of the pro­ject to be more about the re­turn from the ap­pli­ca­tion over the needs of the users (i.e., not solv­ing the prob­lem)

We want to cre­ate the MVP be­cause this opens the feed­back loop and learn­ing cy­cle quickly with­out get­ting caught up in the un­nec­es­sary, al­beit pretty, fea­tures. An MVP is­n’t sup­posed to be pol­ished — it is sup­posed to pro­vide a so­lu­tion to a prob­lem at a base level.

Developing an MVP in soft­ware can be tricky, so I would def­i­nitely rec­om­mend hit­ting up a dig­i­tal agency who can tai­lor the pro­ject to meet MVP re­quire­ments (top tip: we do!)

10. Release! And test…then re­lease again! And test…(re­peat)

Release your MVP and start to gather feed­back. It is im­por­tant to test this out with a slightly larger au­di­ence than your ini­tial in­ter­viewed pop­u­la­tion size. This feed­back could be cen­tred around the de­sign of the ap­pli­ca­tion, the user jour­ney (how peo­ple use it) or it could be about the con­cept in gen­eral (i.e., the so­lu­tion to the prob­lem). Gathering this feed­back and act­ing on it to it­er­ate the MVP con­tin­ues to val­i­date the so­lu­tion de­sign.

With this well re­searched and val­i­dated prod­uct, along­side your busi­ness case and pos­i­tive user feed­back, you have some­thing ready to pre­sent to (potentially) get that bud­get you need to cre­ate the ap­pli­ca­tion with all the fancy fea­tures.

Discover Software
Secrets

ABOUT THE AUTHOR

Alice Spies

KPI mo­ti­va­tor and res­i­dent head chef

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

How to Budget for an Agile Software Development Project

11 September 2019

What are the monthly op­er­a­tional ex­penses to bud­get for a soft­ware ap­pli­ca­tion pro­ject?

02 March 2020

The Process and Price of Software Releases

19 May 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion