A minimum viable product (MVP) is the backbone of any new venture. It is your starting ground, your testing period, your rough draft. You use your MVP to get to market as quickly as possible so you can start building user validation and proving that your product is solving a specific need. An MVP often comes directly after your prototype and wireframe.
What Defines an MVP?
Reid Hoffman has a great line about MVPs. He says, "If you aren't embarrassed by the first version of your product, you've launched too late." I really like this quote because it encompasses all of the emotion and fear of launching your first version. I tend to extrapolate this quote and think of it as, "If you aren't embarrassed by your MVP, it isn't an MVP." Yes, you can quote me on that.
An MVP is not your final draft, and it is super important that you take this to heart. The purpose of the MVP is to gather feedback and see where you can improve, so if you feel like some part of it isn't perfect, or the design isn't right, that is okay! Gather your user feedback, and more often than not, the feedback you gather will help point you in an even better direction than you previously anticipated.
Technical Debt
Technical debt is one of the most important concepts you need to learn if you're considering building a new software product. It essentially will help guide you in the right direction when it comes to quality assurance, testing, etc. There is the gold triangle of software (or as seen below, Venn diagram) that breaks down the give and take relationship of the three factors everyone cares about: Quality, Time, Cost.
Essentially, in starting a business, and focusing on your MVP, you are going to want to focus on the fast and cheap intersection, meaning lower quality. Now what is important to understand is what low quality is really referring to.
Let's use a research paper as an analogy here. If we were writing a research paper and you were looking to pump out your MVP paper, otherwise known as your first draft, you would be following the fast and cheap method.
Anyone who is going to be reading your your first rough draft is going to understand the paper. The arguments will be clear and the reader will be able to understand the purpose an intention of the paper itself. Now, while reading, you may see some typos. There may not be parallelism between paragraphs, and you can be sure that it won't be in APA formatting. However, all of this is intentional! When you're working on your first draft, it takes too much time to worry about all of this formatting, when in reality, all you care about is content feedback. This is what technical debt would be referring to.
When building your MVP, you want to get a product out to your audience as quickly as possible. As they give you feedback, you want to implement it right away and get their feedback on that iteration. If you had to re-APA format everything with each iteration, and double check your parallelism, etc., with each minor change, it would take you forever to complete! At the end of the day, whoever is reading your paper will understand what you are writing about, just as anyone who uses your product will understand how it works and operates.
Now, when it comes time to scale, you will need to go back and repay your debt. Just like in a paper, when you know you've got the right direction, you go back to the paper and start making the proper fine tuning tweaks to get it ready for your Professor to review. And in software, the same principles hold true. You build your first product for feedback and iteration, and then once you are in a comfortable spot, you go back into the codebase, clean it up and edit it for scalability, and then you're good to go.
Technical debt is a startup's best friend. It is what will allow you to iterate and pivot quicker than any big player out there, and what will fuel your product-market fit.
Failure = Iteration
One of the most classic words in the startup scene is, pivot. If you are going in one direction, and you choose to change your main focus, that is reflective of a pivot. Every pivot is going to be the culmination of many iterations. Sometimes you have fewer iterations and the pivot is more aggressive, other times it is more gradual. Whether you pivot or not, what you need to embrace is the pillar of iterations.
Iterating is really a mindset, in my opinion. If someone is resistant to change, then each piece of negative feedback is seen as a failure. However, if someone embraces the fact that change is part of the process, then each "failure" is actually just an iteration. With each failure, you become closer and closer to success. Think about Thomas Edison and inventing the light bulb. As he said himself, "I didn't fail 1,000 times. The light bulb was an invention with 1,000 steps." If you replace the word "step" with iteration, then you get the point. Nothing is built overnight, even overnight successes usually take 10 years to come to fruition.
So how do you embrace this mentality? I think Uri Levine, founder of Waze, sums it up best in a simple quote, "Fall in love with the problem, not the solution." If you fall in love with the solution that you have, then you will be resistant to change. Each iteration or failure will sting and make you think about how bad your current solution is. However, if you're in love with the problem, then each iteration is a joy, as it is helping you get one step closer to the right solution. At Aloa, we believe in a world where anyone can innovate freely. We saw software development as a barrier to innovation, especially for the non-technicals and startups of the world. So, as we are in love with the problem of software development accessibility, each iteration and piece of feedback helps push us closer to achieving our goal of eradicating the problem itself.
Don't Build Rome Twice
It took a long time to build Rome. Now, while it won't take as long to build your product as it took to build Rome, the analogy still holds true. Imagine if the architects of the Colosseum had put it together without ever getting validation from Emperor Vespasian. If they did a poor job, and the emperor wanted them to redo some part or change some design, the process of having to go back to the start would take ages (literally)! Taking this analogy to product development, you don't want to build a final product that you don't know if people actually like. At a high level, it makes sense, right? When you actually get into it though, it is not as easy as it seems.
The whole purpose of iterating and gathering feedback is so you don't have to do things twice. Building technical debt into your MVP will protect you from duplicating efforts down the line. For example, if you were to build out a whole module in a scalable fashion, that would take a lot of time. And if user feedback told you that it is preferred to be structured in a different way, well you now have to go back and redo your work. Instead, what you should have done, is thrown something out there that gets the point across from a User's perspective and allows you to iterate more quickly behind the scenes.
Don't make the mistakes that you don't have to make. Your goal is to do as little effort as possible to get the feedback you need. If you put too much into your MVP, you're wasting your time, and in the startup world (as well as most worlds), time is money.
Recap
- "If you aren't embarrassed by the first version of your product, you've launched too late." - Reid Hoffman
- "If you aren't embarrassed by your MVP, it isn't an MVP" - David Pawlan (that's me!)
- "I didn't fail 1,000 times. The light bulb was an invention with 1,000 steps." Thomas Edison
- "Fall in love with the problem, not the solution." - Uri Levine
Overall, your MVP is your testing ground. Get something out there, quickly, and take the feedback to heart. Iterate where you can; let the user feedback guide your roadmap. Don't spend all your effort on the MVP, because you'll regret it down the line.
For more on MVPs, we also have a free e-book that dives even deeper in the topic and will help you make a decision between building an MVP and a full product!
If you have any questions, don't hesitate to reach out to us! resources@aloa.co
