The MVP ‘Box’

February 15th, 2017

Wikipedia defines a minimum viable product (MVP) as a product with just enough features to gather validated learning about the product and its continued development (https://en.wikipedia.org/wiki/Minimum_viable_product).

On the surface, this strategy sounds like a great idea as it avoids building products and functionality that customers do not want and maximizing the amount of information gained and minimize the amount of money spent in gaining that information.

In practice though, defining what functionality is in the MVP is difficult due to the numerous conflicting desires of members the startup team. It is a very delicate situation and, from what I’ve seen, the CTO is usually at the center of the discussions, negotiation, compromise and eventual implementation, essentially defining what the MVP will include and fitting the agreed upon functionality into a ‘box’.

Let’s take a look at some of those potential high-level conflicts:

• Investors – Obviously they want as much functionality in the product as quickly as they can get it.
• Marketers – The marketers have several concerns. Having a product maximizing the features and functionality makes it easier to sell and to a wider audience. They are also rightly concerned about the fact that in many instances you only get one chance with potential customers so if they sell or attempt to sell a product with limited functionality the customers will be disappointed and will not buy or not continue using the product.
• Founder with original concept – The Founder who had the original concept usually has a grand vision of what he/she wants the product to be. There are usually numerous ideas and bells and whistles that the Founder may have been thinking about for years. There is an immense amount of enthusiasm and a desire to get the product finished quickly with all of the functionality.
• Product Users – The users have an expectation of getting their money’s worth for what they purchased and even if they are given a free trial, their time is valuable so they will only use, and continue to us, a product that is of value to them.
• CTO – All of this puts the CTO directly in the middle. The CTO is usually the person who has to come up with time and budget estimates for various pieces of functionality. This means the CTO will be the person responsible for giving the news that no one wants to hear and will ultimately be pressured into promising more functionality, and faster than is possible.

With these competing demands from the various stakeholders, it is imperative that the startup have a CTO who is not just technically strong, but also has the following strengths:

• Ability to listen to the needs and wants of the various stakeholders.
• Ability to estimate costs and timelines accurately so that various alternatives can be compared.
• Ability to look at the product from a business perspective. Ability to develop prioritized features and functionalities that can be used in conjunction with the estimated costs and timelines to put a ‘box’ around the complete list of product functionality. Ability to develop a strawman minimum viable product that can be further discussed.
• Ability to rationally and logically present the strawman MVP and an ability to compromise to change what is included in the MVP, including priorities for follow-on MVP development.
• Ability to effectively communicate that there will be justifiable changes during the course of development and that these changes could have time and budget impacts.
• Ability to effectively and efficiently manage the development of the MVP including the ability to incorporate changes with the least impact possible.

As a CTO, at times, it is very easy to get so involved with the product and the technology and wanting to do ‘cool’ technical things or a desire to make everyone happy that you can sometimes lose sight of what NEEDS to be done so that the organization actually survives. This principally includes keeping the budget and timeline (which usually means limiting the functionality) within business based parameters. Therefore, for many startups, they need a CTO who is not just a technical expert, but someone who has a combination of technical, business and project management experience. It is imperative that your CTO is able to work within the organization to contain functionality to the MVP box and serve as a true business partner and not exclusively a technical expert.