How to Build a Minimum Viable Product: A Guide for ISVs and Startups

Launching a Minimum Viable Product (MVP) to test ideas is not new. MVPs validate business hypotheses, reduce risk, and get customers to open up to new products. Ever since Frank Robinson coined the term in 2001, and Eric Ries popularized it through his book, Lean Startup, many product teams have given their ideas a preliminary shape through MVPs. But are MVPs only for startups? Are they the first stage of building complex products? How to define the minimum in an MVP?

Today’s successful businesses like Uber, Twitter, Instagram, Dropbox, Groupon, etc. have started with an MVP. However, MVPs are not just for Startups or only to test distinctive ideas. Established enterprises and ISVs also build new products or features of products as MVPs. Building and releasing updates in short sprints starting with an MVP, is apt for modern and reliable methodologies like Agile, DevOps, and CI/CD.

coMakeIT has been building MVPs for ISVs and other product companies for more than a decade. Our customers who started their journey with us by co-creating an MVP now grew into businesses offering full-fledged sophisticated products and platforms.

Here are some tips from us to Startups and ISVs on building an MVP.

Start by defining the minimum.

There is no hard definition of what features an MVP must include. It varies according to the product and the domain. If you’re building a product that is quite similar to other competing products in the market, then to catch even the minimum attention of your customers, your product should include a few advanced and distinguishing features too.

On the contrary, if you’re implementing a totally new idea, the minimum may include the basic features that can be built fast and with minimum resources. A Minimum viable product in many cases also refers to a minimum marketable product.

Do not skip market analysis.

MVPs are for testing several hypotheses, like a new business idea, a new technology, a new architectural pattern, or a new but smaller product. Quite often these hypotheses are risky. The minimum in an MVP should include the assumptions that the makers intend to test. Like any new idea or product innovations are inherently risky. Hence, it is important to do a market analysis, develop a reasonably sound hypothesis, and test and refine the product as per the MVPs acceptance.

Market analysis is especially important when the product should overcome strong competition.  But if the MVP pertains to a totally new idea of a product or functionality that doesn’t exist in the market yet, what should the market analysis include? Well, the analysis, we think, should include how the product or features impact the lives of customers. If you’re sure of a positive impact, you can have a fairly successful MVP.

Think about future strategy.

An MVP is not a full-fledged product. Though it is not necessary to implement all your ideas and features in an MVP, defining a product roadmap with subsequent features and releases is essential. However, do not freeze the anticipated future of the product or platform. It should be flexible for modifications according to customer feedback, market conditions, technological developments, etc.

Though it is important to think short-term and develop products and platforms in sprint cycles, having a plan that is also long-term and yet flexible can assure successful business outcomes. Adjusting product plans to the context and conditions is as important as the initial idea, the product, or the platform itself, especially during uncertain times. Building MVP is a short journey, not a destination.

Follow Design Principles.

Design thinking and principles are needed for an MVP as well as each iteration and release. Makers should think not just about what features should be included but also about how to build the features. Though MVPs are intended to gauge customer acceptance, it is important to note that to catch attention the products should be made user-friendly and ergonomic.

For example, our market analysis might say that customers would like a new feature. But if the design is bad, or if the new feature disturbs their understanding of other features of the product, customers may not find it useful. You may see an increase in customer call traffic seeking help with the feature. This might turn out to be costly and a waste of resources. Adhering to design principles and correcting products accordingly can avoid such unnecessary expenditures.

Customers also judge future releases as per the efficiency and usability of the MVP. Hence, it is important to release a promising MVP that can prompt customers to consider buying future versions if not the current one. Design principles are the guiding light to software products, right from ideation to implementation. However, makers should be aware that building products is a rather continuous process and hence they need not obsess over building a perfect product. Moreover, the idea of a perfect product changes fast according to technological advancements and market conditions, and hence is non-existent.

Interpret customer feedback.

Since an MVP is a basic product, it is worth remembering that it seldom becomes an overnight success. However, MVPs that gain a reasonably good acceptance from customers can assure the success of further releases and hence business too.

Assessing customer feedback on MVPs is essential to designing subsequent versions of the products. In fact, building MVPs doesn’t end with their release, but rather with interpreting customer feedback collected directly and from customer data like usage patterns. It is hence important to interpret feedback in the right way.

Sometimes customers may suggest improvements or alternative solutions. As makers, it is important to understand that customers are not happy with those parts of the product they mentioned in the suggestions. However, implementing their suggestions may not make the product better. This may sound paradoxical. While it is important to consider and value customer feedback, it should not be understood literally.

For example, customers may suggest that they would like to see an icon instead of a description, or a button instead of a link. The best way to interpret it is – currently, the part of the product the suggestion pertains to is not easy for our customers to use or is not clear. Instead of moving ahead and making the design changes suggested by the customers or anyone else, it is better to think about the purpose of the links or buttons and simplify them as much as possible. As a maker, you need to exercise discretion to think through the changes with a clear mind.

Collaboration

Thinking in short sprints, implementing ideas faster, following basic design principles while building products, and fine-tuning products as per customer feedback are basic steps for building any software product or platform. All these steps are included in MVP development. However, MVPs need to be built faster – before the market conditions change and technology becomes outdated. It may not be possible always to translate an idea or a prototype into a fully functioning MVP in less time and with minimum resources.

Also, the complexity of the idea or domain may inject more steps into building an MVP. The process of building an MVP changes as per the technology, domain, market conditions, etc. Collaborating with technology experts provides the makers with necessary data and market analysis and helps in taking objective decisions backed by data.

Collaborations are a good way of complementing domain expertise with deep knowledge of technology. By delegating the responsibility of building the product in time the owners can concentrate on other essential aspects of their business that need their attention. Do you have a business idea? Are you looking for a collaboration that can build an MVP for you?