In Part 1 of today’s blog I looked at using Lean start-up to create an MVP. In this second part I look at some of the common misconceptions and confusions surrounding the MVP.

MVPs are frequently used as Misunderstood Value Propositions

A common misconception is that an MVP consists of the minimum set of features deemed necessary for a working software product, with the goal of bringing it to market quickly. This is incorrect as there is an over-emphasis on speedy delivery and time to market, as opposed to focusing on customer and market acceptance. Rapid development is important, but only to the extent that learning and research objectives can be obtained quickly.

“If you don’t intend to learn from the MVP, it is not an MVP it is simply a release.”

MVP should not be confused with…

• Minimum Marketable Product (MMP) – is the smallest set of functionality that provides value to your market, whether that market is internal users or external customers.
• Minimum Marketable Feature (MMF) – is the smallest possible set of functionality that, by itself, has value in the marketplace. You could release your software with just one of these features and you would see some benefit.
• Pilot testing – is when a select group of end users try the full production system under test, (usually before beta deployment), to provide feedback about the product. The reason for doing a pilot is to get a better understanding of how the product will be used and then refine the product.
• Prototype – is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from. There are many different types of prototype:
  • A Paper Prototype is a printed or hand-drawn representation of the user interface of a software product, these are commonly used for early testing of a software design and can be part of a software walkthrough to confirm design decisions before more costly levels of design effort are expended.
  • A Visual Prototype represents the size and appearance, but not the functionality, of the intended design. A Wireframe, Mock-up or Scamp is a preliminary type of visual prototype which displays the functional elements using rough lines, and less concerned with colour, texture, or other aspects of the final appearance.
  • A Functional Prototype captures both function and appearance of the intended design, though it may be created with different techniques and even different scale from the final design.
  • A Working Prototype represents all or nearly all of the functionality of the final product.
• Proof of Concept (POC) – is a small exercise to test a discrete design idea or assumption. Software developers tend to do POCs instinctively when they experiment with technology. A POC should clearly state what it is to be proven and to what degree, the results need to be measurable so that they can be fed into the decision-making process.
• Spike – is a product-testing method that is used to determine how much work will be required to solve or work around a software issue. It can be used as a way to familiarise the team with new hardware or software, or to analyse a problem thoroughly. A distinction can be made between technical spikes and functional spikes: The technical spike is used more often for evaluating the impact new technology has on the current implementation. A functional spike is used to determine the interaction with a new feature or implementation.
• Release Candidate (RC) – is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge.
• Stable Release – once released, the software is generally known as a “stable release”. All product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs. A release is called “code complete” when the development team agrees that no entirely new source code will be added to this release. There could still be source code changes to fix defects (bugs), changes to documentation and data files, and peripheral code for test cases or utilities.
• Alpha – is short phase in which you prototype solutions for your users’ needs, test with a small group of users or stakeholders and get early feedback about the design of the service usually using several prototypes.
• Beta – build a working version of the service based on the alpha prototypes, develop against the demands of a live environment, understand how to build and scale while meeting user needs. Release a version to test in public (Release Candidate).
• Soft Launch – is a preview release of a product or service to a limited audience prior to the general public usually used to gather data or feedback regarding its acceptance in the marketplace.
• Hard Launch – is the general release of a new product or service to the public.
• Dark Launch – is the practice of deploying the very first version of a service into its production environment, well before release, so that you can soak test it and find any bugs before you make its functionality available to users.

How do all these fit together…

See the illustration at the top of the page.

If none of these terms still describe what you’re doing, then check out this blog by Herik Kniberg – he describes other terms such as Earliest Testable Product (ETP), Earliest Usable Product (EUP) and Earliest Lovable Product (ELP).

Key takeaways

• Learning – MVP is a strategy for learning about your customers.
• Test your hypothesis – break down your idea into a series of hypotheses and use an MVP to test your hypothesis; what is the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort?
• Deliver iteratively – Move from big to small learning loops (Build- Measure- Learn).
• Using the term MVP sparingly to avoid confusion – you don’t have to use the terminology above but make sure that whatever term you use everyone has a consistent understanding so you can all work towards achieving a shared vision that delivers value.

Best of luck testing your ideas

Andy Birds

Thoughtworks Product Strategist

https://uk.linkedin.com/in/andybirds

https://twitter.com/AndyBirds