Continuing on from the questions and challenges raised during our Agile in the Real World event here at TAB HQ, I wanted to tackle one particular area that crops up a lot - how to make a good MVP.
The term ‘MVP’ can easily be misunderstood, or even become a bit maligned. It isn’t uncommon for it to be associated with shipping a bootstrap product, something thrown together in a short amount of time in order to satisfy senior stakeholders, and which lacks quality and finesse.
At TAB, we don’t think that an MVP has to follow this pattern. I wanted to share my take on what an MVP really is, and how to make sure that you’re shipping something that will wow your users.
What an MVP is, and what it isn’t
Firstly, it is important to define what we mean when we use the term ‘MVP’. So, let’s be clear - the minimum viable product (MVP) is the very first iteration of a product. When building an MVP, you should do so with the primary aim of doing as little as possible to go live as quickly as possible. At this point, we are looking to build fast and include only the most essential and important features of a given product.
However, let’s debunk the myth that an MVP should be a sort of lowest common denominator product where the quality and design must suffer in order to ship something - anything - out the door.
At TAB, we believe MVPs should be constructed with the same care and attention as any other product. Often, the MVP will be the first step in your product’s journey, and it’s imperative to start with strong foundations.
One of the major benefits of launching an MVP is that it allows you to deliver value to users as early as possible. By focusing on delivering the features that really matter to them, we can pinpoint the functionality that will enable them to achieve their core outcomes in the easiest possible way.
Another key benefit of an MVP is that you can get your product into your user’s hands fast. An MVP provides a short feedback loop that allows user insights to be collected quickly. This ensures the continuous improvement of your product in order to help inform later phases and the overall product vision.
And what on earth is the ‘wow’ factor anyway?
Defining what we mean by ‘wow’ factor is important, too. At TAB, we think the biggest ‘wow’ factor is a feature or a USP (unique selling point) that fills the user with delight, typically by providing them with some aspect of utility that they were looking for. Think about Uber and how they have managed to disrupt the car service industry: they took the principles of ordering a ride and boiled them down to the essentials, providing only what was needed - and users have flocked to it.
So, when we talk about wow factor, it must be within the framework of providing value to users. For example, augmented reality is often considered a wow factor - but often, this is just based on novelty. In the real world, we would never consider implementing AR as a feature unless it actually provides some tangible value to the users. Otherwise, it just gets in the way.
Obviously, every product will come with its own individual target audience and user stories. In order to ensure your product is able to provide the ‘wow’ factor, it’s imperative to have a deep understanding of what value really means to your core end users. For example, the key stakeholder may initially insist that the value of the product will come from including a new piece of technology that has grabbed the headlines. But on conducting user research, we might realise that security is the element that matters most to the end user. In this case, ensuring a high level of security will be the wow factor of the MVP and not that awesome new feature you originally thought.
So when you are defining what gives ‘wow’ factor, it is vital to notice the difference between valuable features and gimmickry. It is why we place so much emphasis at TAB on understanding users and the outcomes they are trying to achieve. Novelty may be fun at first, but if it stops or even slows your users from accessing the aspect of the app that they really need, they will quickly become frustrated and stop using your product. First, you must give them what they need most - before attempting to finesse to the product.
An MVP isn’t incompatible with high quality
It can’t be stressed enough: an MVP does not mean a buggy, ropey product. For your product to succeed in the long-term, your MVP must provide a solid foundation to support future releases. An MVP is an early opportunity to try out your product ‘in the wild’ with users, delivering them value whilst at the same time learning about how to improve your product over the long-term.
With that in mind, our aim at TAB when creating an MVP is to solve the most pressing painpoint, or set of painpoints, in the smartest way possible.
To find out what those painpoints are, we work hard to prioritise features according to their relative value to the end user. Once prioritised, we treat each feature with the same care and attention as we would when creating any other product, ensuring quality does not slip. Anyone involved in product design, or managing an app, will know from experience that what users really need often conflicts with that initial great idea you had. At TAB, a common mantra is ‘no idea is a great idea until it’s validated.’ That means this is the moment for both you and your stakeholders to leave preconceptions at the door and do some research to find out what users really need.
The importance of user research
Finding what your users really need, what outcomes they are trying to achieve, is vital. The good news is that user research doesn’t have to be complicated.
The aim here is to find out what is most important to the people who will be engaging with your product. Techniques such as low fidelity wireframing and interviews are simple methods that can be employed to zoom-in on exactly what makes up the most valuable, high priority features - according to the user.
And being ruthless about prioritising these user needs is the only way to ensure you can get your product out as early as possible. Always keep in mind that you are going for the smallest, most releasable product first. Desireable but lower priority stories should be added to the backlog to be built in future versions.
Once you have pinpointed what functionality you will be focusing on thanks to your research, it is important that you keep those users in the loop. Try out designs, bounce ideas off them and ensure they buy into your MVP. If they don’t find what you have built useful or enjoyable at this early stage, it is unlikely they will change their minds once the product has been released.
And one piece of advice from our product teams: don’t be too precious about what you have to show. The later you get users involved, the less time you will have to fix features that aren’t working for them, and the greater the likelihood you might have failed to capture what they really need. The brilliant, sparkly feature that had the designers swooning and took your developers weeks to code might not be appreciated by your target user, who simply doesn’t care about it as much as the team might have thought. It is far, far better to find this out before you have spent large amounts of time strategizing, designing and building.
An MVP is just the beginning
You are on an exciting journey with your users, so remember to keep gathering feedback once your MVP is released. The MVP isn’t the final product - just its first incarnation. This way, you can ensure that your backlog for the next iteration of your app continues to excite your users by delivering genuine value that reflects their needs - needs which will, inevitably, evolve over time.
If you’re thinking of starting the product build journey, get in touch here to see how we can help.