What Now? Product Release.

SpiderNet has been planning to release version 1.0 of its product in Q2 of this year. However, after the new VP of Engineering looks into the schedule and deliverables, he informs you that the product will be delayed, possibly by six to nine months, due to stability and feature completeness.

After discussion with the team, you determine that there are two options: Release on time with reduced features, or delay by six to nine months with the full 1.0 feature set. The company co-founder/CTO is adamant that eliminating any of the v1.0 features will result in an uncompetitive product and that releasing “a piece of crap” will undermine the credibility of the company.

Product management advocates releasing something in Q2, provided that the next release follows within nine months. Prior to now, everyone agreed that product management is responsible for release decisions. Your CTO team wants to make an exception to the rule, claiming that this is a strategic decision and can’t possibly be left solely to product management.

According to product management, while the first release will fall short of what was promised, the three most important customer-facing features are able to be released on time. In his view, the minimum viable feature set has been met, and getting something out sooner is the best approach.

SpiderNet still has about a year of cash in the bank, so could theoretically weather the delay, but getting any sort of customer traction before requiring additional funding will be very difficult. Do you side with your co-founder/CTO and wait six months, or do you press the company to release a minimally viable product by the end of Q2?

What now?

Product Release: The Minimally Viable Product

There’s not a technical team on the planet that does not wish to build the greatest product known to humankind — a product that has more features than all the incumbents, will truly revolutionize the market, and be released sooner rather than later, to catch the impending market demand for the technology. Rarely do such wishes come true.

The reality is that building and releasing a market-ready software product takes time and iteration to get right. Whether the product is SaaS or on-premise, the learning curve to get the feature set correct, understand the ideal customer and teach the company how to launch a product takes time, and it is extremely rare for a company to go from no product to ideal product in one grand motion.

While it is easy to advise a stepwise approach, the reality is much more difficult. Engineering teams want to release great and complete products, you don’t want the company to be embarrassed with a half-assed attempt, and the company vision often dictates a much more robust offering than you have the time or money to produce.

I am a huge advocate of the MVP. Having barely lived through the alternative — the uber, world-eating product that never releases — I believe that creating a viable yet less grandiose product of value along the path to something larger is a far more prudent approach. Releasing an MVP puts a product in the user’s hands for feedback, teaches the company how to release a product (which goes far beyond simply finishing the bits), and starts to create a value proposition within a targeted market segment. Two cases in point: Dropbox’s approach to product development and Zynga’s release of FarmVille. When a company tries to build its grand vision upfront, the result is often a broken Swiss Army knife of features that never gets traction because the product doesn’t work completely and can’t compete effectively.

That said, the MVP only works if the following conditions prove true:

• The product actually contains the top three to five compelling features required
• The product is bomb-proof and has the highest attention to quality

Fewer features, yet higher quality, usually wins. Low quality loses in all cases, regardless of the feature set.

SpiderNet
In the SpiderNet case, I would thus advocate taking the MVP approach, despite possibly upsetting the CTO. For all the reasons mentioned above, I would try to educate the CTO and engineering team that getting something out the door is important and critical for the company’s success: Important for feedback, important for the company, and important for SpiderNet to raise another round of funding. Furthermore, the six- to nine-month delay might turn into a year or longer, given the unknowns. Finally, I’d want to make sure that the three to five features are really the ones required by the customer and then, as a team, pick a release date that the company strives to meet. Full steam ahead.