Coding For MVP

This is an old tale...

A big combat between enthuatistic developer with superior technical knowledge and a product owner with super short, critical deadlines. A combat that never ends...

Let’s go deep into real life examples rather than tales. I think most of you already know what is MVP (Minimum Viable Product). To remember:

Product owner: We will create a new product. By using it, users will make phone calls, send SMS, surf on internet, install different applications, even they will be able to listen to music!

Developer: Wow this is fantastic.

Product owner: Yes! We call it as "smartphone". But, I need this product in 6 months.

Developer: That is impossible. We need minium 12 months to complete those tons of features!

Product owner: Ok lets work on MVP. What about a product that only has phone call feature? By that way, we can create value for our customers earlier.

Developer: Yes that sounds good and would take much less time.

Ok this sounds like a happy ending story. Whenever we talk about MVP, you hear until that stage. Just like marriage of Princess and Prince at the end of fairy tales. But all marriages are not happy, specially, if couples do not follow some critical rules.

First of all, MVP is not a name of "product part", "feature set" or a "project phase". It is a product transformation philosophy. That starts from product design and ends on release. The most critical aspect of this philosophy is “technical”.

According to my experince as a developer and manager, the most of developers tend to develop for tomorrow needs. Let’s flash back to the smart phone sample. If a developer knows that he will develop a phone calling product that will have internet surfing feature one day, he definitely will try to build and integrate a large colorful screen into the phone calling MVP. This is a typical reflex that emerges through spinal cord. An idea like, “lets put just a monochromatic tiny screen, later we can replace it by a large colorful LCD screen” is very diffucult to accept by developers, because of these counter arguments:

• I would rather integrate an LCD now, because, we already know we will replace it one day. That means rework!
• Nobody using old fashioned monochrome screen technology anymore. If we include a fancy LCD to our product now, whenever you want advanced features, we can develop them much easier.

Yes, both of them sounds reasonable. But sometimes, “reasonable” one is not “right” choice.

Both of the arguments are about “possible” feature needs. But, by investing on these "possible" needs, you are delaying your MVP launch time (i.e. time to market). As a user, do you prefer to get an ordinary phone on time, over getting a product that has same functionality but some different technology (that you do not have any idea), 1 month later?

And yes, possibly rework will be needed for upgrading to LCD someday.

Wikipedia calls that technology perception as "Minimum Viable Technology" by referring Jeff Bezos's words:

Engineers should be fast acting cowboys instead of calm clear-headed computer scientists?—?Jeff Bezos, Founder & CEO, Amazon

For today’s fast pacing business environment, 1 day late delivery of a value for a product, causes money or business benefit loss that mostly covers weeks of rework cost. Continuous and on-time value streaming is almost everything today.

Besides, each new technology or feature included in your development bucket boosts your product complexity. For the first release, less complexity leads to much less problematic SDLC. Therefore, keeping each iteration as simple as possible dramatically decreases your MVP risk. For two features, lets say your complexity is 1 unit: Combination(2,2). For three features, your complexity will be C(3,2)=3. For 4 features, It will be 6. Realization of a risk likely results in later product delivery.

Transforming technical teams to MVP based development is a big cultural change. Just like transforming to Agile philosophy. If you do not care enough, you would have an MVP with minimum feature set and lots of “possible feature preperation” in much longer time than your estimation.