We can split the types of MVPs into two categories: high-fidelity and low-fidelity. Here’s a brief rundown of their key characteristics:
High-fidelity MVP: This type of MVP takes more time and effort to execute than low-fidelity solutions. It has a much more complex and intensive development process. On the other hand, high-fidelity MVPs provide you with lots of practical data from the get-go. This makes them valuable assets for hypothesis testing in early product development.
Low-fidelity MVP: Low-fidelity MVPs offer fewer opportunities to be creative and illustrate your vision to potential users. However, they are more affordable and take less time to create than their high-fidelity counterparts. For one thing, it’s not necessary to do any programming when designing a low-fidelity MVP.
For a quicker insight into the different MVP types, check out this video from our Railsware Academy MVP series:
The importance of idea validation in MVP development
Before we move on to explain the types, we want to stress that product creation should always start with validating your product idea. There’s more than one way to do this, but we recommend using Lean Canvas to outline your business model before launching into the development phase.
In tandem with Lean Canvas and other agile methodologies, we also employ another approach to idea hypothesis testing at Railsware: customer development. It’s an effective way of connecting meaningfully with your customers and gathering user feedback.
Depending on the nature of your product idea — its complexity, originality, etc. — you may also want to develop a prototype or proof of concept prior to an MVP. Taking these small steps could reduce your chances of failure as you move forward – and even after the MVP launch.
So, let’s discuss the objectives of high-fidelity solutions first. We create these types of products when we want to:
- Learn if there is market demand for the product.
- Acquire early adopters and establish a market presence.
- Test the value proposition, communication channels, and CTA.
- Iterate more effectively on our designs.
- Optimize the product marketing strategy.
Examples of high-fidelity MVPs are functional prototypes, 3D models, or mockups which allow you to examine user experience, interface, and engagement.
It’s important to note that some of these MVPs require a lot of manual work to maintain after launch. Take Quora for instance. During its MVP stage, the team had to write Q&A themselves to attract users.
But before we go deeper into the reasons behind that approach, here are four of the most commonly built high-fidelity MVPs:
This is where humans perform the actions that an automated algorithm should. Users are manually guided by humans working behind the scenes to power the app’s core functionalities. The concierge MVP is a good fit for projects based on recommendation engines or machine learning techniques.
- Customers receive a highly-personalized service right off the bat, making your product more attractive to potential users.
- Save money by validating your opportunity hypothesis before developing the entire intricate solution.
- You interact closely with real customers, which can lead to more accurate feedback.
- Requires a lot of time and effort to keep the product up and running after launch. Human operators need to be reliable, consistent, and readily available.
- If you lack the resources, you may need to outsource the operation aspect of the business, driving costs up.
Wealthfront MVP example: Before wealth management platform Wealthfront had automated functionality, the platform was operated by a team of experts who gave personalized investment advice to users. When the company saw how popular the service was, they decided to expand the automation aspect of the business, and today it’s one of the most respected robo-advisor platforms in the world.
Wizard of Oz MVP
This is sort of an enhanced version of the concierge MVP. It also uses human-powered functionality but looks and feels like a real solution. Crucially, users aren’t informed of this human intervention. For all they know, the app is powered by complex algorithms.
- No need to build an expensive technological solution from the outset.
- Get an in-depth look at how users are interacting with your product, and what their true habits and needs are.
- Like the concierge MVP, it takes a lot of time and effort to maintain.
- If users find out that the app is not automated, they might feel cheated and form a negative association with your product.
Zappos MVP example: Online shoe and clothing retailer Zappos launched as a Wizard of Oz MVP back in 1999, at a time when online shopping wasn’t commonplace. Founder Nick Swinmurn started out by selling shoewear via a simple website, using photos he took of shoes at his local mall. Instead of an automated ordering system, Swinmurn manually prepared and sent the orders himself, at least until Zappos took off.
With this type of product, a significant share of functionality is also manually powered. However, some of the missing features are emulated with existing services. For example, you might use a CMS like WordPress to create a frontend, then Google Sheets to create a backend, and tools like Typeform and Zapier to gather customer information and automate workflows.
- Quickly build a functional solution with the help of tried-and-tested tools.
- Offer a more engaging user experience by leveraging the advanced functionality of those tools.
- It might be difficult to get some external products to work in sync with one another.
- Overdependence on third-party tools could threaten the reliability of your app. If one of them stops working temporarily, this could damage your brand reputation.
Drone technology example: Steve Blank advised a startup aimed at the production of agriculture drones. His idea was to use an HD camera and a helicopter to collect the necessary data and sell it. It was not drone-driven technology at the outset, but it validated the idea and even brought some income to its founders.
Single-featured or one painkiller feature MVP
The hallmark of this type is its focus on one feature. Above all, you need to provide users with a clear understanding of what the product is meant for. Later on, the set of features might (and probably will) expand, but not at the MVP stage.
- By focusing all your efforts on building one great feature, you improve the quality of your initial offering.
- Compared to other high-fidelity MVPs, it has a limited scope, which reduces time to market.
- It’s not always easy to choose which feature should be implemented first.
- In this case, limited scope also means limited functionality. This could leave early adopters feeling underwhelmed with your product.
Smart Checklist – Single-featured MVP example
Smart Checklist for Jira is a great example of one painkiller feature MVP. It came about when the Railsware team needed a usable solution to make long To-Do lists in Jira.
In just two days, we had written a piece of code and built a minimum viable product. Its sole feature was the ability to convert Markdown into checklist items.
Sometime later, we made it available on the Atlassian marketplace for free, with no monetization plans. It was simply an internal solution, which was good at solving our tasks.
As soon as we obtained numerous user stories and requests, we understood that the demand for our barebones product was rising.
Therefore, we decided to iterate and start the product evolution process, with the aim of making Smart Checklist better and monetizing it.
At the time, we had two or three competitors that offered products with similar functionality. Nevertheless, they all lacked the value we put emphasis on — the markdown editor.
Today, Smart Checklist feels integral in Jira, and users seeing it for the first time may not even notice that it is an add-on. The MVP has definitely solved our business goal and also brought benefits for target users.
It’s worth noting that we never jump straight into MVP development at Railsware. For the sake of reducing risk and refining our goal, our product team invests a lot of time in product discovery and idea selection.
When nailing down the product vision, ideating features, or mapping out the user journey, we use various product discovery techniques at Railsware. Our personal favorite is the ideation and decision-making framework we spent years bringing to life — BRIDGeS.
We always recommend starting the product development process with a solid yet flexible roadmap. This will help you focus on the most important aspects of your solution from the outset.
As we mentioned, this approach to MVP building has its limitations. However, it’s not always necessary to start with a functional product — sometimes, simple is best. We can say that low-fidelity MVPs help product teams and startups:
- Learn if the product has practical value
- Identify which solutions customers are most in need of
- Better understand customers’ needs and preferences
- Conduct niche analysis; grasp whether or not the problem is worth solving.
- Takes proportionately fewer resources to get these types of solutions up and running.
- You don’t need advanced technical skills (or programming knowledge) to create them.
- Cost-effective way to gather customer feedback and test market-need hypotheses.
- Limited data collection. Since you are not sharing a functional product with customers, user feedback on low-fidelity MVPs is less practical and nuanced.
- It can be difficult to attract investment with these types of MVPs because you are unable to prove that your solution actually works or that customers are benefitting from it.
- Doesn’t give your product a foothold in the market.
Examples of low-fidelity MVPs
Blogs: Writing about your product concept and sharing it with others is a good way to find out if people are interested in your solution. For affordable platforms, think WordPress, Wix, Medium, etc.
Forums/Communities: A good way to collect user feedback and figure out if your problem is worth solving. Share your solution on platforms like Hacker News or Reddit.
Surveys/Questionnaires: Test your product hypotheses via surveys or customer interviews. Tools like Typeform or Google Forms come in handy here.
Landing pages: Create an engaging landing page that illustrates your value proposition. Sites like Product Hunt are a good place to start.
Explainer videos: Design a short introduction video, ideal for sharing on social media platforms and forums.
Advertising campaigns: With your customer research on hand, create targeted campaigns and test hypotheses by analyzing engagement data.
Mockups/slide decks/presentations: These are suitable for presenting at sales meetings or startup pitches.
Crowdfunding campaigns: Raise funds before you invest time and money into building a functional product. Think Kickstarter or Seedrs for promoting your idea.
Idea spotting networks: Submit your startup idea to platforms such as AngelList, or attend startup hackathons and tech conferences to network with peers/potential investors.
How to Plan the Right MVP
When we are choosing the right kind of MVP for our own products or our clients, we start by asking ourselves a few key questions:
- What’s our goal/what do we want to learn?
- How big is our budget?
- How much time can we afford to spend on this stage of product creation?
Let’s expand a little more on this decision-making criteria…
The type of MVP you choose hinges on the type of product you are creating. It also depends on what kind of hypotheses you need to test. To break it down simply…
Goal: Acquire early adopters and establish a market presence.
Type: High-fidelity MVP. Pick the Concierge or Wizard of Oz approach if your product will rely heavily on AI or custom automation.
Goal: Better understand customers’ needs and the solution they are looking for.
Type: Low-fidelity MVP. Choose a medium based on the preferences, budget, and approach of your team.
Bear in mind that it doesn’t always need to be a strict choice. Building a low-fidelity MVP doesn’t mean you can’t pivot into high-fidelity MVP development in the future.
Sometimes, you can opt for several types in one go (combine the release of a Concierge MVP with a survey to be held in a specialized community or forum). The careful allocation of resources should be the main priority at this part of the process.
Low-fidelity MVPs are generally cheaper to build than their counterparts. That’s because there’s little to no development involved. Startups with smaller budgets can benefit from the low-fidelity MVP approach — but again, it all depends on the type of product they want to build.
Let’s say you want to create an MVP for a cloud-based HR management platform. However, you don’t have the capital to build a functional product at this stage. Since the platform won’t have any machine learning elements or complex features, a landing page MVP or explainer video is enough to showcase the value of your product to potential users.
On the other hand, let’s say you were building a product recommendation platform for pet owners. This requires machine learning capability upfront. You could choose to create a landing page or crowdfunding campaign, but if you really wanted to ignite interest in your solution, the best option would be to simulate its machine-learning functionality with a Concierge or Wizard of Oz MVP.
Although it costs more to build, this type of MVP may also increase your chances of attracting investment, acquiring early adopters, and gaining valuable user feedback.
How soon do you need to go to market? Low-fidelity MVPs can be executed in a matter of days, so choose this approach if you need to confirm market demand quickly and get to work on a functional solution.
At the same time, if you decide to start with a low-fidelity MVP (e.g. crowdfunding campaign) and create a high-fidelity MVP later (e.g. Single-featured MVP), this could slow down the entire process.
High-fidelity MVPs can take anywhere from weeks to months to build. This approach requires more resources to execute, and since software development is involved, there’s the possibility that bugs and technical snags could slow things down. However, opting for the no-code MVP approach could help speed up this process.
You’ve done your research, worked out what features your MVP should include, and chosen the most suitable MVP type for your product.
It’s time to start building, right? Not so fast. For our product teams here at Railsware, there are a couple more steps to follow before we dive into actual MVP development and launch. These steps allow us to choose our startup metrics, prioritize features, and break down the product backlog — all before we get caught up in the process of creation and iteration.
For more on these steps and how to proceed, check out our comprehensive guide on how to build an MVP. Meanwhile, our team of product experts are always on hand to help you navigate the product development process from ideation to launch, and beyond. Don’t hesitate to get in touch!