Answer? Build an MVP (Minimum Viable Product)
First thing to say about an MVP is it means something different to everyone. People struggle with the terminology, because it’s subjective. Different businesses will have different thresholds for an MVP.
But it always comes down to this: what functions do you NEED the software to perform and what are your priorities?
Step 1: Minimum
Firstly: who are your target market? Have you defined that?
Build a character profile, and go find them. Speak to them to really get to the root of their pain points. You want to conceptualise a product which allows them to solve their challenges and unlock opportunities. What’s the minimum level of functionality you need to alleviate their pain points?
Talking to your audience is a massively undervalued part of software development. And yet it is a vital step many scaling businesses miss out. You might have designed an app around a feature which your audience aren’t bothered about.
Step 2: Viability
Viability is multi-facetted. It comes down to three main areas:
· How it looks and feels
· The quality and completeness of interface and the benefit it offers
· Robustness, security, and integrity.
Consider the points above in relation to your audience, and weight your effort according to what’s important to them.
Sense check what is the minimum required to include in your product to attract your target audience to use it. For example: if your business is in a safety critical industry, security (and an element of robustness) is a requirement for an MVP. If you’re a start-up bringing a new product to market that doesn’t have those kind of implications, MVP will mean different things for you. It can be a bit scrappy and buggy, because there aren’t dangerous repercussions.
Remember that if your MVP addresses a legitimate pain point, your audience might be willing overlook issues of functionality of the product, and the aesthetic of the interface etc.
Step 3: Product
This is where we come in.
We will work with you to list the features and benefits of your MVP and make sure it’s a problem worth solving. We often work with the 80/20 rule. When we’re evaluating any feature, if 20% of the requirements require 80% of the effort, then you need to think about whether or not it’s essential. It might be a rogue criterion.
This avoids tech debt. Building features that aren’t essential cause harm; it’s more work for the developers, more cost for you, and if it goes t*ts up, you’ll have to pay to remove them.
We build features that align to benefits. These features and benefits are then split into phases (or sprints). We then build a clickable prototype. It’s the step we use to demonstrate how the MVP will look and work.
An MVP allows you to get a product out far earlier for less money:
1) Because the product goes to market faster, you receive custom feedback more quickly, and this can generate revenue.
2) Reduces risk- you’re testing the concept, and the less you build, the less risk. It’s much more appropriate to build something that isn’t enough and customers demand it, rather than over build
3) The more focused your MVP, the more focused the delivery partner is on building high quality functionality