Maximize Results with the help of an MVP

A Minimum Viable Product is a tool, not a magic spell that will fix all of your business’s problems. It is not a cure all where all you need to do is murmur “M-V-P” three times and achieve your goals. An MVP is a process, and one that can go awry if you do not do it right. Eric Ries defined an MVP as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” MVPs are about getting to know your customers better so that you may build a better business. For more on what an MVP is, check out our ultimate guide to an MVP.

The focus of this post is to highlight the importance of an MVP in software development. Too often, software development is focused on developing a solution and too little attention is given to whether the problem being solved is important or valuable.

One of the worst things that can happen to a team is to build something that no one needs. It kills momentum, it destroys motivations, it eliminates team cohesiveness. MVP principles puts a premium on testing everything so that you can identify any and all issues early, allowing for you to pivot if necessary and to ensure that you build a product that people will use, and more importantly, pay for.

 

MVPs in Software Development

Everyone wants to build that perfect product that is in their heads; they do not want to “waste” time iterating. Why build something less than what you can build? The instinct to “do better” is often quantified as adding more features and “doing” more in regards to the product. People over-invest by developing their product instead of developing their knowledge.

 

Your job as an entrepreneur is not to build a specific product, but to develop a solution to a problem that your customers feel acutely and are willing to pay a good amount of money to resolve. Your deliverable is your customer’s relief, not some piece of software. Shifting your focus from your product to your customers is the first step to becoming an entrepreneur. At every step of development, you should be seeking customer insights and developing intuitions about what they need. This intuition, more than any technology or innovation, will be your unassailable competitive advantage.

 

An MVP is meant to help you make this shift, and in that way it’s name is misleading. By emphasising the “product” instead of the experience, many entrepreneurs believe that an MVP is just a minimal collection of features randomly tossed together in an effort to see if people respond. That is an incredibly inefficient approach. An MVP is an experiment, and it should be developed as such, with each small adjustment or iteration targeted towards addressing a specific, measurable question you have. 

 

MVPs are used to focus your attention on a “series of hypotheses that you need to test.” For some, an MVP doesn’t even need to be a product — it can be anything that answers a question about a market you want to enter: Surveys, landing pages or a video can all be an MVP. Others define MVPs as the minimum product that allows you to deliver value to a customer, and in turn, get value back.

 

MVPs were developed as part of the Lean Startup Method, which is about building your business and understanding your customers through a repeating, scientific process. It is a repeating process of hypothesise, test, synthesise, and adjust based on how customers respond to specific features and applications. The Lean Startup Method works especially well with Agile Development.

 

Agile Development was devised to mitigate the risk of building a product that customers won’t buy through a incremental development. As with the Lean Startup Method, the focus is on iteration; the development and testing of small changes. By building in small chunks, businesses can avoid disastrous coding errors. Agile can also be applied to customer base development. By testing multiple iterations of your MVP with potential customers, you can easily learn what elements you are thinking about works for your customers and what elements don’t. This can help you avoid disastrous over-investment in unpopular products. For more on how the Lean Startup Method and Agile Development can be applicable to your business, click on this link.

 

MVP Basics

So here is a quick reminder of how design and build an MVP, which can be found in more detail at this link:

• Prediction: Make a prediction that will identify a need or want in the market that people will pay to resolve. Identify what success versus failing short would be like for measurable results beyond just profits or revenues.
• Design: Prepare a design that will solve that need or want, and make sure it can be built relatively quickly and cheaply.
• Test: Put that design out into the field, and see how the market reacts. Release the product so you can best test your prediction; if you’re making a product for one market niche, make sure you target that niche when conducting your test.
• Review and Revise: Review the data from the test phase, and make new predictions. Maybe failure was due to a specific element, but your customers liked everything else? Maybe you can achieve more success if you add an element or take one away?

There are a lot of different hypotheses to test and they can be grouped into several different areas. Each area may need to be tested at different points during the development cycle. Below is a list of each different category of hypotheses, in the order of when they should be tested to ensure minimal misplaced effort and investment.

• Assumption: These hypotheses must be tested first because these speak to the foundation of your business. Important assumptions include whether you are trying to solve a problem that is important to your customers, whether your customers will pay for a solution to that problem, and if your solution actually solves the problem.
• Need: Your product should only be as complex as it needs to be and no more. Need hypotheses focus on what elements need to be included in your product to so that it achieve the end it sets out to resolve.
• Uncertainty: Uncertainty can addresses questions that come up during development. Coders can be unclear what development choices to make when building a product. Testing can resolve this indecision.
• Impact: Impact hypotheses is about understanding which features and elements of your website app are the most important to your customers and which are not. These tests help you better understand how to market and develop your product so you can maximise your value to your customer base.
• Cost: These should be things you should test towards the end of development as you move toward building your refined product and after you have absolute confidence that you know what the customer needs and what they like. Testing cost hypotheses is about learning how to build a product that provides the best user experience, but at the lowest possible cost.

 

While doing your iterative testing with your MVP, it is also important to differentiate the difference between a complex feature to build versus a feature that makes the system more complex. A complex feature to build is something that will be expensive to develop initially, but does not make navigating or iterating your system more complex. A feature that makes the system more complex might not be expensive to build initially, but makes future iterations slower and more expensive because all future adjustments would require additional steps. Decisions regarding which type of feature to test first will vary based on context and where you are in development. In a future post, we will discuss how to determine the priority and which feature to build. (subscribe to our email list to be notified)

 

Approaching Excellence with MVP Approaches  

There are lots of different ways to build an MVP, and there is no single best approach. Making the best choice for your MVP is a very contextual decision. Below are a few different approaches on building an MVP and how each can address a key area of your business development.

 

• Build your product, iterate your product. This is the most straightforward approach to MVP and is probably how most entrepreneurs would approach the challenge. The key to this approach is to begin with building something quite small, but engaging, and working your way up from there. It can be quite easy to build something that is a little to large, with a few too many features, and therefore stray from strict MVP principles. This risk is heightened because you do not get any customer feedback before you start to build. Only pursue this route if you have some experience prior to building that provides some suitable basis for making early design decisions.
• Build a landing page, generate leads, build the product, iterate your product. The benefit of this approach is that you get feedback from your customers early before you begin developing software. The landing page in this approach should describe the problem you are trying to solve and provide a sketch of the solution you are planning on building. At the end of the page, you ask for some identification information and an email address if they are interested. This allows you to gauge interest in your product as well as cultivate a list of potential customers. This can help you assess whether your assumptions about your product and market are correct, and will guide you on building the product.
• Start a blog, build a community, build the product, iterate your product. This is more involved than a landing page, but the content you receive can provide more insight and build a more passionate user base. A properly blog provides you with the opportunity to receive more detailed feedback from potential customers, as well as the chance to act direct questions of your potential customers allowing you to iterate your ideas without building a prototype. You also stand the chance of building a passionate following before you draft one line of code.
• High Fidelity Prototype. A lot of people think that the back-end is the first thing that should be developed since it acts as the “engine” for the application. However, many people start with the front-end to gauge customer interest. An interactive front-end can give people a sense of what the product is, even if all the functionality is not there, which will allow your potential customers to provide in-depth feedback for future iteration. At CobbleWeb, we like building interactive prototypes with Axure or interactive design with Invision to get quick, detailed feedback from customers. We find this works especially well for B2B clients.
• Smoke Test. A smoke test is like a landing page except the customer is asked to pay up-front instead of just asking for a name or email. An example of this approach is a crowdfunding site, such as Kickstarter. This approach provides you with a higher level of certainty regarding the interest of your potential market. It is one thing for a client to ask to be kept informed; this does not put him at risk and there is no commitment. By having clients pay upfront, you get a pretty clear signal about whether what you are building is valuable and can be monetised.
• Demo Video. A demo video is a two to five minute explanation of your business’s proposed value proposition in terms of what problem you are going to solve and what functionality you plan on providing. It saves you the trouble of building a prototype, while still providing a sense of interactivity for the viewer. The comments on the video can provide valuable feedback on whether your product is valuable and can help you form early hypotheses to test with a prototype. Demo videos have been used very effectively by many startups, most famously by DropBox.

MVPs can be crucial when building your business, as it can help you develop a strong foundation for your success. However, MVPs only work when the focus is on what your customer needs and not on what you could potentially build. Iterating your MVP without receiving customer feedback is a waste of your time and resources, so be sure to budget in user outreach to your process.