Have we not all seen countless so-called MVPs that included so many capabilities that you could hardly call it a minimum of anything.
We know we should be lean. And yet, have a hard time focusing and letting go of anything we do not need. This way, we end up trying to squeeze everything we can into an MVP because we all know that "version 2 is the biggest lie in software development."
The acronym MVP stands for Minimum Viable Product.
Synonyms for viable include possible, workable, usable, and feasible.
Let us unpack this together and dive deeper into what an MVP is, why and when we need it, how to define it using a messaging-focused app as an example, and how to avoid common pitfalls.
What Is an MVP?
The term minimum viable product is anchored in the lean startup methodology and has been popularized by Steve Blank and Eric Ries.
We already know what the acronym stands for, and most of us have an idea of what an MVP should be. It is a product that has just enough features to attract early adopters and helps us gain insights and feedback at the beginning of our product development cycle.
Did you know that 90% of startups fail?
The most common reason why startups fail is due to misreading market demands (42%), followed by running out of funding or personal money (29%), and sometimes by having a user-unfriendly product (≤10%). [Source]
Putting something in front of real customers fast can mitigate those risks significantly.
Why And When Do We Need an MVP?
Whenever you plan on building something new, be it a feature or complete product, you should work as lean and iterative as possible. Short feedback loops will reduce time and money spent on developing the wrong thing and allow you to change direction if needed.
According to Marty Cagan, there are four risk areas we should take a closer look at when creating new features or products:
Value - Will customers buy or choose to use your product?
Usability - Can they figure out how to use it?
Feasibility - Can we build it with the skills and technology we have?
Business Viability - Does the solution work for our business as well?
Our MVP should contain only the smallest set of features that we need to release to learn. Consequently, we can assess the above-mentioned risk areas earlier in our product development cycle and iterate.
Of course, there are ways to evaluate these risks even before building an MVP, but user interviews and tests can only get you that far. Scaling the number of users quickly increases the amount of feedback and statistical significance.
Components of an MVP With In-App Chat
Let us look into a tangible example, an MVP with in-app chat available. A lot of popular apps have a bunch of different chat features available.
Text chat - The classic we all know and love.
Voice chat - At times, it can be easier, faster, or more accessible to use voice instead of text.
Video chat - Face-to-face conversations can create a feeling of closeness and avoid miscommunication
Group messages - Having async communication with several people, even better for use cases like making plans with your friends.
Media attachments - A picture says more than 1000 words.
Presence indicators - If we want people to interact in real-time, we should let them know when they can.
Stickers & emojis - Adding some fun to any conversation in settings where you communicate with friends and family.
Push notifications - We all like to know when someone messaged us, don't we?
Real-time translation - If we do business across borders this can make our users' lives easier, and we can potentially connect even more people.
Collaborative whiteboard - For those times, we want to collaborate and visualize what we are talking about.
Voice & Video notes - Leaving a voice or video note can feel more personal.
Delete messages - Sometimes, we need second chances.
@user mentions - To not get lost in a group chat again, tag a person.
What Components Can We Skip in an MVP?
Our new app could be a marketplace app. Our signature feature might be an amazing algorithm that matches buyers and sellers perfectly and effortlessly.
Messaging will be part of our core features together with login, payments, and the ability to create products.
In our MVP, we do not need a video chat feature or group messages. We want to connect buyer and seller one-on-one for starters, so we choose only private messages and possibly customize an existing UI.
We can skip any other component.
Which components you need depends on your product. Evaluate what you need carefully and radically focus.
How to Create an MVP For a Chat App
Building an MVP is part of my general approach to any new feature or product:
Research your target audience - This includes discovery on user and potential market(s)
Define the problem - You need to know what to solve exactly
Ideate - Come up with one possible solution
Validate the solution - Test with real users to see if your solution solves the problem
Define the MVP scope - Think about your signature feature and your core functionalities
Build and ship - Do not try to reinvent the wheel and focus on your signature feature
1. Researching Your Target Audience
We want to make sure to do just enough research to be able to define our problem. I like the Jobs-To-Be-Done (JTBD) framework for generative research -
What are your users trying to get done?
What are their pain points?
What are the potential gains they seek?
Market research should give us an overview of competitors and their products to inspire us. Remember, copying the competition is not a product strategy!
For help creating user personas try this free template from product management expert Steve Johnson.
2. Defining the Problem
Once we have the initial research completed, our next step is to create a clear problem statement by answering these four questions:
What is the nature of the problem?
Why is the problem worth solving? What is the impact?
Where or when does the problem occur?
Who has the problem?
Sometimes it is worth consulting with a subject matter expert after we define our problem.
3. Ideating
Based on our problem, we then need to come up with a suitable solution.
There are many valuable design thinking activities to help us in this step which could fill an entire article on their own. All I want to add is, we should ensure to include the whole team in this process. We have a bunch of cross-functional experts around and should very much rely on their knowledge and experience.
4. Validating the Solution
Once we have decided on a solution, we validate it.
Building a prototype does not mean coding anything. Creating a good façade is all we need at this point. Testing it with five users will already reveal patterns. [Source]
Based on our findings, we might want to iterate on our prototype once more or move on to determine what to implement.
5. Defining the MVP Scope
As we have discussed, you need to build the smallest set of features that make your product functional, launch it, and learn from it. The prototype usually has more capabilities than you can implement in your very first release, so how do you prioritize what exactly to build?
The most helpful activity to define the MVP scope is this classification from TWG's Product Definition Canvas:
Signature Feature - What is the secret sauce to your product? Which feature would you like people to remember? This feature will most likely be your differentiator. Netflix’s “Browse” screen is one example.
Core Feature - These are features that you need to make your app functional and fulfil basic user needs. Examples would be a login screen or settings pages.
Other - As the name suggests, it contains all features that are not Signature or Core.
It is easy to think everything is important. The art of building an MVP is to focus radically on the Signature and Core features and drop anything that is in the category “Other”.
Remember, we decided that our marketplace core functionality includes connecting buyer and seller, login, payments, product creation.
You need private messaging and notifications. All other capabilities around messaging are nice to have and will not make it into our MVP. You can also look at Chat APIs and SDKs from CometChat to reduce development effort and time.
Check out this article on Microservices and how this new approach is saves development cost and effort for businesses building new products or features.
6. Building and Launching
Ideally, developers are part of the whole process and can build what you decide on. For this step, I highly encourage everyone to try not to reinvent the wheel. We should use libraries and third-party integrations for anything that is not your signature feature.
Always remember to dedicate most of your time and resources to your signature features. As much as possible, buy rather than build the other features to keep your overall investment low.
With most third-party providers, you can choose between simple ready-made components or an SDK and API integration. My recommendation is to go with the off-the-shelf variant while taking a look at available SDKs and APIs so that you can build upon this for customized iterations in the future.
All you need to do then is launch it and start learning.
Common Mistakes Developers Make While Building an MVP
As I have mentioned, you do not want to reinvent the wheel. To make your lives easier and create progress faster, you should use external libraries and third-party tools. Anything but your signature feature can most likely be built using integrations and libraries. Others have already put the time and the money into developing them. It will never be cheaper to build something like a chat or payments system or CRM from scratch.
I have witnessed many projects take significantly longer because designers and product managers have held onto the exact designs, and developers did not question it. If it is not easy to implement something with the libraries or integrations, developers should renegotiate with the product manager or PO.
What's Next After the MVP Has Shipped?
Congratulations! You’ve learnt to build and launch an MVP.
What now? You need to make sure you are learning. That is your goal of putting something in front of your customers.
You need to define what success looks like early in the process and measure if you are getting there.
The V in MVP should be your most important KPI. You need to specify the one metric to tell us if our product is viable, possible, workable, usable, and feasible.
Head to this article for tips on how to collect and apply user feedback to improve your product.
Get Started!
Now that we’ve discussed the strategy, you are ready to actually start building your MVP. Log in to CometChat’s dashboard and start building for free. If you still have questions, talk to our experts today!
About the Author
Lisa is a product person with a strong focus on inclusive and empowering product management. Her 8 years of experience range from early-stage startups to corporates in Europe and Canada across industries like retail, ad-tech, e-commerce, and fin-tech.
She loves to write on everything Product Management related and has her own blog. Lisa is also an active member and Ambassador for the WomenTech Global Network.
Lisa Mo Wagner
CometChat
