Building an MVP is hard. Creating a sustainable product from an MVP can be even harder.
Oftentimes, we build more than we need according to Eric Ries’ definition of an MVP in The Lean Startup:
What was meant to be an MVP turns into a hacky product crammed with half-baked features. Once it is out there, we keep on adding to that pile of spaghetti code and we do not take the time to learn. The resulting product is going to be subpar and hard to scale.
There are three challenges when it comes to MVPs:
How to build one in the first place and fully focus on the important parts
How to make time to learn
How to move to what your product should be
How to create an MVP for a Chat App
Let’s say you get tasked with building an MVP. I recommend following these 6 Steps to Build an MVP:
Start by researching your target audience. Who are you addressing? What’s the potential market? Look into market data and possible competitors. You want to find out anything and everything that will help you in your next step.
Based on your research, define the problem. You need to know what the problem is, who has the problem, when or where does the problem occurs, and why it is worth solving.
You want to spend a good amount of time defining your problem space and then it’s time to ideate. I like to use design-thinking-based workshops and techniques to come up with as many ideas as possible. Then choose the one you and your team believe to be the best one.
Validate your solution quickly and easily by testing with real users. Does your solution solve the defined problem?
Based on your findings from your user tests with the prototype, now you define the MVP scope. Think about your signature feature, the one thing you want people to remember about your product and your core functionalities, what’s needed for this to be usable.
Lastly, you build and ship your MVP. Stick to your scope. Do not try to reinvent the wheel and focus on your signature feature. Use libraries or 3rd-party tools and integrations for the core features where possible.
Here’s a quick example for an MVP:
Since we’re only at an MVP stage, we need to consider what we can “outsource”. Messaging can be handled by third-party Chat APIs like CometChat. In our example, we only need one-to-one messaging when we first launch. We can skip any other component.
As I have said in the first part of this series:
If you have made it this far, congratulations, you have built your MVP and shipped it!
Don’t fall off the wagon, you’re not done, the most important part is starting now. The reason you built that MVP was to learn and iterate.
Learn and Iterate
One thing I have missed when building an MVP was proper tracking. Make sure you are tracking all relevant user behavior. Work with an analyst or tracking expert if you can.
Again, you don’t want to overdo it. I recommend Google Analytics and Hotjar as a free-of-charge starting point, this gives you visitors and clicks as well as heatmaps and user behavior recordings. If you want to make data-informed decisions, you need the right data.
Define success metrics for your product, they depend on your context. Sign-ups might be a good starting point, but don’t forget about returning users. How many monthly active users do you have? Is your MVP part of an existing product landscape, what’s the adoption rate?
I cannot tell you what the best metric is, look at what you are trying to achieve and how you can measure the corresponding user behavior? Your metric should be able to tell you when it is time to scale and build a full-scale product.
After launching, it can go one of three ways:
Your product is wildly successful
You are so far away from your metric that you deem this product unsuccessful
You are on the right track but not quite getting to where you want to be
While we all hope for number 1, the reality is we usually hit 2 or 3.
If your product does turn out to be super successful from the get-go, you want to get started to move from MVP to the full-scale product straight away.
If your product is a failure, then you have learned what does not work, be honest with yourself, scrap it and go back to the drawing board.
If your product is somewhere in between, and that’s a majority, you don’t need to start over but you should consider tweaking the MVP or creating a variation. Analyze your data carefully to understand where in the user journey people drop out. Where in the funnel are you losing your potential users?
Once you have pinpointed the opportunities, you can loop through the steps again. It is possible that you need some additional research because you realize you missed something in the beginning. Then you can define the problem, ideate, validate, define the scope and build a new feature, optimize an existing one or create a variation and learn and iterate.
If you do not generate new insights about the signature feature and core functionalities, make a plan to scale your product. While building MVPs, we usually do not pay too much attention to tech debt because we need to move fast.
By the time we start to scale, we need to pay back some of that tech debt and not just tack on new features to the MVP and start calling it a product. That’s how you create Frankenstein applications that are hard, sometimes even impossible to maintain. In those products, the cost of complexity tends to go up exponentially.
Plan your project
Based on your learnings from your MVP, you would want to build a well-designed, stable product that you can scale. Often, this means to throw away (most of) the MVP. Now I know, this feels wrong and is hard to do. You all put a lot of effort into it.
MVPs are not designed to scale. They are meant to ship fast and learn fast. There’s no formula for when to move from your MVP to something like a full-scale product. In my opinion, you need to find the sweet spot once you’ve validated that your signature feature does solve your users’ problem and that there is a large enough demand for it. At this stage, it is again very easy to fall prey to confirmation bias. Even if you solve some people’s problems, make sure enough people have that problem!
Now it is time to plan your next steps. Roadmaps are a great way to do just that. I use a now/next/later format and try my best to keep it outcome-focused. Make sure you plan time for continuous discovery and designing your messaging app’s architecture.
Discovery is not a one-off. You might have done some initial research to get you started but that is just the beginning. Teresa Torres wrote a whole book on Continuous Discovery Habits to help teams answer questions like, “how do you know that you are making a product or service that your customers want? How do you ensure that you are improving it over time? How do you guarantee that your team is creating value for your customers in a way that creates value for your business?”
Discovery drives outcomes. You want to constantly be in touch with your customers or potential customers. There is no other way to truly understand the problem space and create valuable solutions.
Good architecture should be the backbone of your product. You want to deliver great user experiences, performance and stability are the parts we might not see as shiny new features but that can drive adoption and retention.
When you’re moving from an MVP to a product you want to scale, it is crucial to plan and design your architecture carefully. It’s a prerequisite for scaling. You should still keep your signature feature and core capabilities in mind during this process. Do not try to reinvent the wheel, a smart usage of third-party tools and libraries can reduce the complexity of your code if done well.
Let’s look back at our marketplace example; the matching algorithm is our signature feature. Even for the core capabilities, I would use third-party integrations. I believe no one should ever try to build payments if that’s not what your business is about. Compliance is way too hard and integrating with all kinds of providers and banks is too complex. It’s easy to agree on this, I suppose.
Messaging is a great example of something you think you might want to “just” build yourself. Even this seemingly small part can be complex and if it’s not the one thing you want to sell, you don’t need to build it. Use a chat integration like CometChat and start out simple but have the option to add more features as you grow your product to support new use cases.
6 Steps to move from MVP to final product
You have built your MVP and shipped it. Now what?
Learn and iterate, again
Make sure you have tracking in place and focus on your signature feature and core capabilities. Collect as much feedback as you can, qualitative and quantitative, about your MVP. Iterate on your signature feature and the core capabilities. This is not the phase to start adding new features randomly. You should still radically focus at this point.
Continuously discover
Do not stop your discovery efforts just because you have launched, keep talking to customers. In step 1, you collect feedback about the existing product, you are validating and improving on your solution. In this step, you keep on exploring the problem space to uncover more opportunities that you could solve in the future. This helps you to prioritize problems for the next bigger iterations and new features for your product.
Design a scalable architecture
Plan and design a sustainable architecture with a focus on core competencies and useful 3rd-party tools. MVPs are meant to be built quickly and without too much time spent on creating a maintainable architecture. The goal of an MVP is to ship quickly so we can learn. Your fully-fledged product should have a sustainable base, so you can actually scale it. Your customers will thank you for a stable and performant product. If you do not take the time now to pay off your tech debt, it will come back to haunt you.
Move to that new architecture while building new capabilities
Make time to pay off tech debt and move your app to your new reference architecture, add new features there not on top of the hacky MVP. I don’t think I have ever worked with a team that had time to stop and refactor for more than a sprint. If you don’t do it now, you never will and in one, two or three years from now you will rebuild your whole, much more complex application from the ground up. It will take a lot longer than if you do it now. At the same time, we want to keep the momentum of our new product going by extending functionalities and adding some new features. Find a balance.
Ship and launch
You don’t need to do it all at once with a big bang, it’s often easier and more sustainable to launch the full-scale product gradually. Whenever you move something to your new architecture, release it. Don’t wait for everything to be finished. It is a lot easier that way and since you had only launched an MVP, you probably do not have an insanely large customer base yet and early adopters are quite forgiving when the essentials of the product create value for them. Yes, that’s your signature feature and I am a broken record.
Rinse and repeat
Don’t forget, a product is never really done, experiment and validate new ideas, never stop learning and iterating. Take time for your continuous discovery, prototype and test, build an MVP version of a large new feature, collect data, iterate, create a sustainable architecture, scale.
Conclusion
When building an MVP, you want to focus on speed and learning, failing fast and improving. MVPs are not meant to be long-lived and scalable products. Once you have validated your product, you need to shift your focus. You still want to deliver new capabilities quickly, but you do not want to accumulate more tech debt. It is time to slow down a little bit, design your architecture, and set your product up for success in the long run. Decide on strong partners for integrations that can grow with you and build a maintainable, strong base.
About the author
Name: Lisa Mo Wagner
Bio: 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.
Lisa Mo Wagner
CometChat
