Cut Out The Fat/Eliminate The Essence?

Mistakes to Avoid When Building Your MVP

The purpose of the MVP (Minimum Viable Product) has primarily been customer-driven instead of product-driven. It begins with laying out a business hypothesis and then validating it by learning from customers and figuring out what customers want or don’t want. The MVP idea originated years ago with Frank Robinson, and then later was popularized by Eric Ries in his Lean Startup movement in the 2000s. According to Ries, an MVP is: “the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

Outsourced Product Development

This idea almost immediately became a favorite with developers as the tech industry boomed and the barriers to product development lowered. Product developers and designers now had a framework for getting new products to market quickly. Businesses liked the option of being able to showcase a stripped-down product, test it with real customers, and measure its success in the marketplace without building a fully developed solution.

And here’s perhaps where the problem begins. MVP instead of being a minimum “viable” should have been named a minimum “valuable” product because an MVP came to be misinterpreted as something with the least features necessary to solve only the top level problem of customers. Developers were enjoying the benefits of saving time and money, and of getting feedback almost immediately.

Developers and designers use MVP as an excuse to cut corners, remove features, and sacrifice UI/UX in the name of “staying lean”. They end up creating a product that’s not competitive and alter the core idea by replacing a feature with something easier to implement.

So what are the mistakes to avoid when using this sustainable approach that tempts businesses with its indisputable advantages?

Aiming for perfection

The idea of MVP is to provide customers with a preview of the future product, without implementing all features, regular and sophisticated. You will understand you are moving in the right direction even if the MVP is launched with only a few features. By adding a “cool design” and fancy features in the MVP, you may lose focus on the product’s performance and actual viability. When it began, Uber simply connected iPhone owners with car drivers and was used only by the founders and their friends. Today, Uber shows a whole evolution from the primary idea, making it easy for users to book and pay for the taxi via the app. They never rushed into stuffing the apps with buttons and animations and stayed focused on developing the core features that they built over time.

Ignoring Feedback and Metrics

A key purpose of an MVP is to generate feedback in order to make the final product better. Yet, developers tend to ignore any feedback you received from users and testers. Don’t forget that in the end, you are creating your product for users, and their feedback is critical. Feedback will help you understand the user better, adjust your product to meet the customers’ needs as well as gauge the audience’s perception of your product. Also make sure to implement analytics such as daily active users, retention rate and average time spent using the product, into the platform that houses your product in order to get an idea of your MPV success.

Building an MVP when not needed

This is one mistake that surprisingly many startups often make. They start building their MVP without any research and end up creating a product that already exists for a market that is most often crowded already. Not every business idea is purely innovative and disruptive. As a result, they end up wasting time, money and effort on something that may not yield expected results or wow targeted customers. Instead of rushing into developing an MVP that replicates your competitors’ features, you must first validate your business idea and make a product that does not exist or at least has additional features that are unique and can improve the user experience.

Using shortcuts to get there fast

Perhaps the most exciting perceived benefit of developing an MVP is the “get rich quick” attached to it, however inaccurate. Success stories of startups like Airbnb and Dropbox give entrepreneurs the idea that they can easily replicate their success. Sparkly features and other frills and bells and whistles will not make your product successful. It requires a great business proposition and a lot of iterative effort.

To quote Eric Ries himself: MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don’t need the MVP. In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.”

Disregarding marketing strategy

Another common mistake that traps and trips most entrepreneurs who think that everything they need for a product to be successful is a unique and fantastic idea that will advertise and become popular by itself. But without a proper marketing strategy, every MVP is doomed unless marketed and promoted the right way.

Getting wrong or under-skilled developers

Would you hire an executioner to do a barber’s job? Or ask a history professor to teach quantum physics? Both are in the same profession and possess skills, but are they the right talent? On the other hand, while you take extra care in hiring well-qualified new employees, why would you ask someone not qualified enough to build your MVP? In a best-case scenario, they’ll turn out to be really creative and somehow manage to complete most of the task, with quality being compromised of course. Worst case, they’ll waste your time and effort taking you back to square one. Building an MVP requires having a professional team of designers, developers, QA engineers and project managers with proficient skills and capable of delivering a good product within a strict timeline.

Picking the wrong project management style

Waterfall and Agile are the two most popular project management methodologies. When it comes to MVP development, the main difference between is how frequently you’re going to deliver your product to users. Unlike Agile, the Waterfall model is a strict sequence of development phases, and moving to the next phase is possible only if the previous one is fully completed. This approach may not be the best option because you need to stay competitive and keep launch time in mind when building an MVP. Besides, Agile provides greater transparency. You can see how much time has been spent on the different stages and the results. It is a more flexible approach allowing you to change the direction of your project whenever you want. Most importantly, in the Agile approach, the MVP is shared with all stakeholders, and their feedback is incorporated into future iterations.

Choosing the wrong tech stack

Before creating an MVP, it’s very important to choose the right tech stack from the very begin because it ensures a solid foundation for future improvements. Simply put, the better the ingredients you use, the more delicious will be your cake. You will also time and money because the right tech stack goes a long way in helping you minimize errors. Your MVP and then later your product will be easier to maintain and scale if originally built on the right tech stack.

Conclusion – Is your product viable or valuable?

Before moving into production of your MVP, ask yourself – What makes your product unique? What problems does it solve? Who are the intended customers and why? This is important because an MVP is not just a scaled down product with some of the features chopped out, or a way to get the product out the door a little earlier. The MVP doesn’t have to be a product at all, especially if you’re going to build only once and then consider the job done.

Think of MVP is a process that you repeat. When you develop a product, you make many assumptions like what users are looking for, how the design should work, what marketing strategy to use, what architecture to use, monetization strategy etc. Know your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct. Twitter was intended to be the Odeo podcasting platform. But when Apple launched iTunes, the founders realized they had to change strategy because they would never be able to compete with the giant. One of their ideas was to create a platform that gave the ability to share updates with a group of people using basic text messages with the codename “twttr.” And so Twitter was born.

No matter how good your team, some of your assumptions could be wrong. The problem is, you don’t know which ones and that’s the purpose of an MVP.