In Part I of this series we discussed the importance of having a marketing vision and plan before embarking on your new App project. In Part II of this series we discussed how one would go about reviewing App store guidelines prior to creating your App. In Part III I wrote a little bit about how to create your initial product feature list / requirements. By now you should have a pretty clear idea what your App is going to look like. The next bit is the hardest bit! Now you are going to have to prioritise your requirements!

The ability to prioritise is critical to successful delivery of an App. You are probably thinking “well, my idea is great and I’m going to need ALL of my features in it for it to be a success. I don’t want to release an incomplete App…”

This turns out to be untrue! Prioritisation will maximise your value for money by minimising your cost and focussing your expenditure on those critical, unique features of your App. In essence, prioritisation lets us build a Minimum Viable Product.

Moscow

MoSCoW prioritisation is a good place to start. You may have a lot of index cards, each with a different requirement on it. MoSCoW prioritisation encourages you to organise your cards into these categories:

  • Must
  • Should
  • Could
  • Won’t

Must means what is it CRITICAL that your App does. For example, if your App is designed to allow its users to send text messages, then your “Send Text Message” card would be a MUST.

Should means what is it IMPORTANT that your App does, but you could live without it if you really have to. For example, if your App is designed to allow its users to send text messages, then your “Show Emoticon :)” card would be a SHOULD. Emoticons are the kind of things that users expect to be able to use, but they could live without.

Could means the requirements that are UNIMPORTANT, but might be nice bells and whistles to have. For example, your text messaging App may have a requirement to “Share message on Facebook”. This might be nice to have, but it isn’t important.

Won’t defines the scope of your App by saying what you will not do. For example, your text messaging App will not support non-Latin characters.

Continual Prioritisation

You should continually review and re-prioritise your requirements as your ideas and environment change. Very few App projects are static and you will receive feedback from potential users as you go. Be prepared to change!

Minimum Viable Product

The first release of your App should be the requirements in the MUST category. This represents your Minimum Viable Product. It is the lowest cost, highest benefit set of features that you can think of. It is tempting to keep adding features in from your Should and Could list, but this is the wrong thing to do! This will drive up the cost of the product and it means that you will build the WRONG App!

There is only one way to KNOW if you have built the right App. The right App is the App that your users will download, love and recommend to their friends. The only way to know if you have built the right App is to release it and get it out into the wild! Once your App is released, you will start to receive feedback about it from your users. The quicker you release, the quicker you will get real feedback. Real feedback will lead to new ideas which will lead to a better product.

Essentially, the longer you wait to release your App, the more time you will spend building the wrong App!

Next: Choosing A Development Team

Now you have a good idea about what it is that you want your App to do, you should start thinking about who is going to do the work! In Part V we will explore your options and how to choose!