When you think about your next big application idea, you probably need to do a lot of trimming and prioritising. One of the ways to do it is to come up with a set of features that are not only vital for your app but also valuable to your users. It’s a very difficult exercise for young startups – their appetite is great and users’ wishlist seems to be a never-ending story.
Why the first version is not an MVP
Most people call the first version of their product an MVP (Minimum Viable Product). According to Eric Ries who coined the term, it’s far from it. An MVP is “a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” In this sense, an MVP does not require writing a single line of code. It’s only a visualisation (a prototype) that allows us to avoid the risk of building a product no one would pay for anyway.
What can serve as an MVP for your application?
- mockups (on paper or clickable)
- landing page describing unique advantages of your product
- your business model (e.g. on Lean Canvas)
Why build small first?
But let’s assume you’ve gone through the MVP. You want to build a product. You know you don’t have the skill yourself. The next challenge ahead of you is to plan what to release in particular versions of your app in order to:
- release and test often
- implement the feedback in the future releases
- give value from version one
- do all of the above with the least effort
How to prioritise features?
There are multiple ways to classify the features for the first version. The one I want to introduce in this article is called MoSCoW prioritization technique.
In this method, you focus on the features that bring the biggest business value to the product.
It pays off to prioritise more than once.
When you should go through your backlog and set new priorities:
- For the entire project – to come up with a closed set of absolute must-have features that bring business value;
- At the beginning of each release – after gathering the feedback for version 1.0 you’ll probably come up with new features for releases 1.1, 1.2 and so on;
- Whenever you get new funds, or your project’s budget is at risk (because of new legal regulations, because of your competitors, because of a new and better technology, because of you changing the requirements every second day, because of the change in your software team etc.).
Let’s discuss MoSCoW technique on the example of Starter24 app we made for an assistance company that worked with hundreds of subcontractors and had no system to track issue progress, the location of the contractor or the vehicle they used to pick up the issue.
M stands for “must have”.
The app makes no sense without these features. It’s like making a bank app without the connection to your bank account. In the case of Starter24, the app for tracking assistance issues would make no sense if a contractor wouldn’t be able to get assigned to an issue and to pick it up.
S stands for “should have”.
These are the non-critical features without which the main business value would still be delivered, however, the satisfaction from the end result would be low. Usually, S-features have some sort of a walk around. In the case of Starter24, a “should have” feature could be the ability to log into the application. Without this element, the contractor could call the customer centre and be assigned a task by the consultant. Would it make much sense? No. Would it be painful? Yes. Would it the walk around work? Probably. But the main feature of the application would still be there.
C stands for “could have”.
These are all desirable but not necessary solutions we come up with so easily. C-features enhance user experience but can be skipped without harm for the end user. For Starter24, one of these features was the ability to set the estimated time of arrival by the contractor.
W stands for “won’t have this time”.
That’s a tricky set as they force startups to think of all the nice settings and technologies they plan to sell their app with. For Starter24, one of the W-feature was to fully integrate the mobile app with their billing and invoicing systems. It turned out too costly and carried too little of business value at the time of the project.
It’s a challenge – don’t do it alone
As a sponsor and a product owner, you own the best knowledge of the product and your business. You can expect that your software team will ask you a lot of domain and business questions to make sure they understand your actions and reasoning.
A well-established team will be also able to take you through the design process and help you set the priorities if you are not able to decide on your own. They will:
- Involve a product designer or strategist,
- Involve a UX designer to learn about your users and their goals,
- Set up an architect to come up with technical solutions that resonate with your business choices,
- Meet you at a workshop when you’ll be able to educate them on your application and be challenged with their point of view.
Summary and key takeaways
The appetite to build the most beautiful and amazing application in the world is natural for all aspiring startups. It’s also a very dangerous hunger that makes founders jump right into full development and forget about their users.
Prioritising helps to:
- clearly point out what brings business value,
- sketch the future direction for the product,
- bring value fast and frequent.
To do it right, remember to qualify the features to one of the groups:
- Must have – absolutely critical; without them, the app makes no sense,
- Should have – their lack is painful but you can use a workaround instead,
- Could have – additional features that enhance user experience but bring not much business value,
- Won’t have (this time) – a wishlist for the future; your product will be fine without them.