✕
Book a free consultation
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
For the uninitiated, the world of startups and technology might seem a bit impenetrable, with its various acronyms and prevailing jargon. But whilst new methodologies, terminology and approaches to digital product development have been created since the dawn of the internet, the fundamentals of having an idea, going through a research phase to validate that idea, developing the product and then releasing it to market remain more or less unchanged. In this article, we hope to provide a practical overview of minimum viable product (MVP) design and development. What is it? What are the best ways to achieve success? And what are some of the pitfalls to watch out for in our experience.
If we break the term down, fundamentally, the term ‘product’ encompasses goods or services capable of satisfying customer needs. In the context of an MVP, digital products tend to refer to some kind of mobile application or web platform. The term MVP itself was coined by Eric Ries as part of the ‘Lean Startup’ methodology, which was created to get products into customers’ hands as efficiently as possible, hence the ‘minimum viable’ part of the term. This concept of efficiency is key, with customer feedback being the main driver for change in further iterations of the product.
In the simplest terms, an MVP can be defined as the most basic version of an idea that can be used to get feedback from customers.
This question doesn’t really have a concrete answer. According to the definition above, pretty much anything can be classed as an MVP. Indeed, Dropbox is often cited as a product whose MVP consisted simply of a 4 minute video, outlining the product idea and USPs. This was released to the public before a single line of code had been written and just looked like an instructional demo. They received a huge amount of positive feedback and could be sure that they were not spending time and money on a product that no one was interested in. In reality, however, the term MVP is probably a bit of a misnomer here, used more to drive home the importance of user feedback in the early stages of product development.
How far should your MVP go, then? This depends a lot on the individual project and your personal business approach. As a general rule, though, the faster you release a beta version the less likely you are to spend time developing functionality or features that the customer doesn’t actually want or need. So keep in mind the words ‘minimum’ and ‘viable’ - if you have something that you can start testing on real people, launch it asap!
It is often the case that successful products provide capabilities the users did not know they wanted. Prototyping is a useful technique for getting a clearer picture of what is needed beyond the initial ideation stage. It generally involves creating some kind of simulation of the system that can be reviewed together with the eventual users of the product. This could be anything from paper models or illustrations on a flipchart to screen designs with click dummies.
Given the Dropbox example above, you could argue that the lines between a prototype and an MVP are a bit blurred. In practice, however, prototypes can be created, changed and thrown away quickly all in the interests of developing the final product idea. The MVP should go beyond this and represents the first phase of realisation of the product idea itself. It is something you can release to customers, while prototypes are more for informal feedback rounds.
Ultimately, the key thing to take away is the importance of feedback from the end users at every stage of the development process.
There are many approaches to creating an MVP and, whilst there is no magic bullet, there are several things you can do to increase your chance of success. One route map that we have found to be successful is outlined below.
Clearly, coming up with a great idea is a crucial part of the whole process. Unfortunately, however, the chances of your idea being totally unique these days are pretty small. Where you can easily differentiate yourself is in the development and implementation of your idea. As a result, a lot of time should be spent on this part of the process.
Develop a concept paper getting feedback from as many sources as possible. Always keep in mind the problem you are trying to solve and investigate it thoroughly; it is often the case that the initial problem you think you are trying to solve is only a superficial one. Workshops, interviews, surveys, buyer analysis, scenario analysis and prototyping are all great investigation techniques to get a better understanding of the real problem you are facing. Put all your findings into a business plan and also focus on sales, marketing and financial models. After all, the best idea in the world is meaningless without customers and financial viability.
Once you have a good understanding of the problem, it is time to design your solution. In a typical IS project, over 80% of errors are introduced at the early stages. Less than 10% of errors are introduced in the development stage, yet most of the project time is devoted to development and testing. So it really cannot be overstated how important it is to work through this stage fully.
At Heliotrope Digital, we like to start this stage by developing an Information Architecture document. This is a structural overview of features, dependencies, organisation schemes as well as navigation and search systems. This can be used as a basis for the product requirements. It also helps to plan the user flow, from which UI designs can be developed.
Depending on the project, process models, use case diagrams as well as data and class models are useful to get a clearer picture of the interaction between various stakeholders and data/entity relationships.
Once again, feedback should be sought from users on completion of this phase.
We could obviously devote (and probably will in future) a separate article to this phase of MVP creation. There are lots of varying approaches to software development, each with its advantages and disadvantages. The waterfall methodology, for instance, follows a rigidly defined sequence of stages.
At Heliotrope, (depending on the project) we like to use the Agile systems development methodology. In comparison with the linear waterfall lifecycle, which emphasises completing one stage before moving on to the next, Agile philosophy advocates an evolutionary approach based on the early delivery of increments. Key to the success of these projects is close cooperation between the user community and the developers, usually bridged by the product owner. Prioritisation of tasks is also key.
As mentioned previously, errors that occur during development are usually the result of lack of definition in the earlier stages. In an agile project, these are almost inevitable to some extent, and even welcomed if they generate discussion about the best way to move forward. The important thing is to keep the momentum up or developers can lose motivation. Developer Experience (DX) alongside Customer Experience (CX) and User Experience (UX) is increasingly being recognised as crucial to project success.
Testing is a term which can have different meanings to different people, so it is important to delineate at the outset of a project what kind of testing will be required and when. It can cover testing the software from a technical perspective, which alone can include unit tests, smoke tests, functional tests and user acceptance tests. As discussed, an MVP is more than a simple prototype, and consequently quality and performance are important. Testing, however, is associated with increased time and costs, so a balance will always need to be struck regarding how much testing to do before release.
Another key segment of MVP testing is that of usability. This is related to how real users interact with the platform. It usually consists of setting a series of tasks for users to perform, while recording their screen and possibly facial expressions. The data that you can collect from this kind of test is invaluable, as it can tell you where the kinks are in your interface. Crucially, it also tells you what they like about the platform as well as features they might not notice or gloss over. It’s also worth mentioning that this kind of test can even be carried out on wireframes or UI mockups; once again, it’s never too early to get feedback on your ideas from real users!
As with any complex project, opportunities for something to go wrong are plentiful and many of these pitfalls are common to all large-scale projects. Most commonly, these include misalignment of expectations vs. reality, failure to balance quality, timescale and cost, as well as tacit knowledge. Requirements definition can also be an area of contention, particularly in an agile project, where requirements are continuously defined and redefined throughout the process.Needless to say, at Heliotrope Digital we have devised ways to deal with these various concerns, but this article is already much longer than I expected, so for the low down, please give me a call and I’ll be more than happy to share our experience with you free of charge. Or stay tuned and sign up to our blog for the follow up article!
Socials
