Minimum Viable Product (MVP) in Tech Product Development
The Minimum Viable Product is the prime focus of both product and business activities in software startups. Not all companies have a full understanding of MVPs, how they facilitate product design, product development activities and communication, some don’t even use MVPs at all.
They are a part of systematic approach and a precedent to the multi-facet product (MFP), implying research and development directions as well as setting the overall pattern for the startup. To understand the MVPs better and what comes after, I will explore their usage from the perspective of software prototyping, and offer insights via boundary spanning theory and use case showcasing.
The Role of MVPs in Startup Companies
With the growing number of startups we see many newly created companies joining the market with little to no operation history, but aiming at high-growth products. As the main differentiator from established companies, startups usually deal with the challenge of identifying and implementing a product that needs to deliver an actual customer value. The methods to achieve this vary from company to company, but the common model – the Lean startup [1,A] – predominantly emphasizes the ability to pinpoint an actual problem of a customer, spend time learning about it and build a minimum viable product to validate their hypothesis about what the customer needs. In this context, let’s define an MVP:
MVP is a product with just enough features to gather validated learning about the final product.
It is crucial for the team, for informing the external stakeholders, investors, potential users and advisors. It is a key artifact that is shown during a meeting with an investor. There are multiple types of MVPs varying in purpose, stages they occur and the amount of effort being put into creating it. We can differentiate them from a communication perspective (creating a landing page – can be created quickly) or engineering perspective (building a single feature prototype – may take months), depending on who is being informed.
MVP and Prototype Classifications
Multiple MVP types [1] used in the industry:
Explainer video – A short animation (half minute to few minutes) explaining the product use and features, including a prompt to buy it.
Landing page – A webpage to ‘land’ and learn about the product, containing links, campaign and contact information. It quickly communicates the proposal, objectives and a call to action
Wizard of Oz MVP – This is an illusory way that creates an user interface that seems like a real working product, but the actual workings are manually performed. It aims to demonstrate the user mechanism of the final product.
Concierge MVP – Similar to the previous, it contains manual service consisting of the exact steps users to need to go through while using the product.
Piecemeal MVP – Also similar to Wizard of Oz MVP, only the executive process is done with existing tools.
Mockup MVP – A wireframe prototype with a representative user interface, but without any functionality.
Single feature MVP – A prototype that implements only one and the most important feature of the product.
Public Project Proposal – Kickstarter to pre-purchase the product and raise funds for initial orders.
Rip off MVP – Creating a successful product to gain user base, then pivot to a different direction.
Boundary Spanning
Now when we have an overview of the MVPs and prototypes, we will look at the Theory of Boundary Spanning as an empirical method that can be used in the context of building software startups. System and information science define management of information and knowledge to initiate the most innovation within specialized fields, aiming to alter these knowledge boundaries:
— Syntactic boundary – A syntactic knowledge boundary defines a lack of a shared syntax and creates the concern that information may not be processed properly across a given boundary.
Example: Entrepreneurs use business terms that developers do not understand.
— Semantic boundary – A semantic knowledge boundary is present when a common syntax is in place, but different interpretations of the common syntax occur, making communication and collaboration difficult.
Example: A designer thinks about artistic expression while a developer thinks of software architecture when talking about design thinking.
— Structural (pragmatic) boundary – Occurs when a common interest has to be achieved and participants negotiate with each other on the scope, consequences and conflict solutions of knowledge delivery.
Example: Developers and entrepreneurs do not share common interests.
Boundary artifacts are utilized to transcend these different varieties of understanding limits. The theory puts forth that an artifact can only assist in overcoming those boundaries if it meets the criteria as a boundary object, described as something that "resides in between" various knowledge groups, establishing a "shared and transferable" context for distributed issue resolution. These artifacts must be flexible enough to adjust to local demands and conditions of the many parties utilizing them, yet strong enough to sustain a communal identity across sites.
MVP as an Artifact for Overcoming Issues
To create better prototypes – and thus final products – visions, theory and practice need to come as close as possible, which is unfortunately not as common as it could be. Initial ideas and visions about what we are trying to build can vary. Technical and non-technical minds come together to exchange ideas, reflecting on processes can sometimes be reduced to a bunch of inputs that nobody knows how to implement. In some cases, teams develop a product with decently functioning features, but have no idea how to communicate it to the investors or the public. Sometimes the ideation phase takes too long for products where a rapid prototype would be more fitting, other times a rapid prototype is necessary to convince a team member about adding a new feature to the model. The various types of MVPs are necessary to address the variety of needs and render the function of MVP as an artifact:
MVP as a Design Artifact – MVP facilitates the visualization of ideas, reflection on design, and innovation.
MVP as a Boundary-Spanning Artifact – MVP facilitates knowledge transfer between the entrepreneur team and external stakeholders, such as customers, mentors, vendors and investors.
MVP as a Reusable Artifact – MVP needs to serve many purposes. Even if it is a throw-away prototype, it can serve other purposes later in the startup process.
Built to Measure
The central part of the build-measure-learn process is customer validation, and MVP plays a crucial role in it – as a design artifact, boundary spanning artifact and reusable artifact. The journey from a business idea to launching a project is made of loops, but also from parallel branches. If product design and market validation run simultaneously, certain types of MVP influence mutual adjustment between the input from both customers/users and product design. In many cases, there are vast benefits of having an MVP on the final product development, such as increased quality and reachability. MVP adoption is also influenced by contextual factors, one of them being product development methodology. For software startups, the most viable type is Agile Development [B]. This type relies on fast releases with an iterative and incremental approach, which shortens the timespan from ideation to production.
At the end, it all boils down to the complexity of the product. If the product is very complex, a single-feature MVP would not work and it would rather become a liability. Instead, such companies should focus on continuous integration and adopt evolutionary prototypes and not single-feature MVPs.
Case Analysis — The OWNverse World
The product of OWNverse is a complex infrastructure of an entire virtual ecosystem. Constructing a single-feature MVP would not only not demonstrate the workings of the final product, it would show a knowledge deficit. The team initially created a multiple-feature early MVP and now proceeds towards a multi-facet product (MFP), a later stage of MVP. Following is the evolution of functionalities for this particular case:
MVP – Functionalities built for MVP was a sample of 3D virtual environment demonstrating the interactive movement of avatars. It accommodates a platform-independent VRM file format designed for use with 3D characters and avatars in the modern VR landscape. The sample virtual environment is also used to showcase the activated early version of multiplayer functionality.
MFP – The MVP viewer and sample environment will be upgraded to an editor version, the avatar configuration system will gain the physics settings and pose setting functionality as well as animation running. In regard to the 3D space, there will be a demo of a virtual space editor and constructor supporting import of 3D models and avatars, scene and parameter editing. The 3D virtual space demo will serve as a basis for laying the foundation for template integrations.
Alpha Version – In the next step after the MVP, we will be looking at the Alpha version stage. If we apply continuous integration, the exact evolution will be defined by mapping the development of MFP. The team will be testing the platform internally and moving all applications to a single platform. The preliminary timeline is set to achieve the full user registration mechanism, multiplayer implementation as a full-fledged SaaS platform, and creation of the first version of Avatars HUB with avatar library, multiple format support and a third-party import mechanism.
This is a complex agenda of tasks that run simultaneously and where functionalities emerge in relation to other functionalities. It is not a linear process and changes in the plans are expected. The market-validating activities and product design tasks are carried out during the same time, while the MVP plays a role of mutual adjustment between the input from the outside and the input from the product design team. In a way, MVP serves a bridge between all – developers, designers, marketers, investors and of course the early adopters.
To Summarize
Revealing some prototyping approaches clarifies the role of MVP in design process, communication and cost-saving activities. When market validation and product design are carried on at the same time, MVPs serve the mutual adjustment between various inputs of all that are involved in the product building and thus help overcoming knowledge boundaries. An MVP shows the early design, bridges communication gaps and can be re-purposed in later development stages.
—
Notes:
[A] Lean startup – Lean startup is a methodology for developing businesses and products that aims to shorten product development cycles and rapidly discover if a proposed business model is viable; this is achieved by adopting a combination of business-hypothesis-driven experimentation, iterative product releases and validated learning.
[B] Agile software development – refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
References:
[1] Ries, E. (2011) The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Crown Business, New York.
Recommended Readings: Research on five startup case studies
Title gif credits: Schnellebuntebilder