Minimum viable product

Arseni Mourzenko
Founder and lead developer
September 16, 2020
Tags: management 33 agile 10 productivity 36 communication 27

An in­ter­est­ing ques­tion on SE.SE got my at­ten­tion re­cent­ly. The ques­tion is about things that may hap­pen to a pro­ject, in a con­text of a pro­ject which is tar­get­ed to be de­liv­ered eight months af­ter its start. A dis­cus­sion that fol­lowed showed that the no­tion of min­i­mum vi­able prod­uct (MVP) may not be as clear as it should be. This ar­ti­cle at­tempts to clar­i­fy it.

A bit of back­ground. Over the years, I worked on pro­jects that used Wa­ter­fall, and the ones that used Ag­ile, and every­thing in the mid­dle, such as, you know, when you claim you're ful­ly Ag­ile, but your sprint is three months long. The ob­vi­ous dif­fer­ence be­tween all those pro­jects is the fre­quen­cy of de­liv­er­ies, the fo­cus on how reg­u­lar­ly the chunks of the pro­ject are de­liv­ered to the cus­tomer—not just shown, but ac­tu­al­ly de­liv­ered to pro­duc­tion. Al­though not the same as time-to-mar­ket (TTM), the fre­quence of those in­ter­ac­tions has a di­rect ef­fect on TTM: if you have two de­liv­er­ies per year, your max­i­mum TTM is more than six months. If you're do­ing sev­er­al de­ploy­ments per day, your TTM could be as short as a few hours (al­though in gen­er­al, it is much longer, due to all the process­es that hap­pen be­fore the de­vel­op­ment of a giv­en fea­ture starts).

While both TTM and the fre­quen­cy of de­liv­er­ies are im­por­tant, there are also two oth­er met­rics which are cru­cial as well, but of­ten for­got­ten: the time be­fore the first de­liv­ery, and the time be­fore the MVP.

The first deals with a sim­ple “Hel­lo World” which ends up in pro­duc­tion. This is a cru­cial step, in three ways:

  1. Only af­ter this step is fin­ished the team can know that the pro­ject can be de­liv­ered. As sur­pris­ing as it could sound, there are pro­jects which are de­vel­oped for months or even years, and only when they are con­sid­ered fin­ished by the pro­gram­mers, the ops are asked to make it work in pro­duc­tion. More of­ten than not, what hap­pens is that the ops find things that won't work, and start claim­ing that de­vel­op­ers didn't do a great job; the de­vel­op­ers claim that the pro­ject works on their ma­chines, and it's the ops fault to be un­able to make it work on the servers. Even­tu­al­ly, the pro­ject is re­leased months lat­er, and some pro­jects nev­er get re­leased.

  2. It puts the de­vel­op­ers on a good track, know­ing that any change they do can end up in pro­duc­tion and be seen by the stake­hold­ers. This means that the team has a con­tin­u­ous in­te­gra­tion (or con­tin­u­ous de­liv­ery) pipeline all set, and that if some­thing does work lo­cal­ly, but not in pro­duc­tion, it will be quick­ly dis­cov­ered ei­ther by the tests, or by the stake­hold­ers. Also im­por­tant is the fact that they are con­scious that the pro­ject should be build­able and runnable at all times, which pre­vents large changes which break most­ly every­thing and jeop­ar­dize the pro­ject.

  3. It in­creas­es the stake­hold­ers' con­fi­dence in the pro­ject. They can see the con­certe re­sult of the work of the per­sons they pay, as op­posed to some­thing which is some­where on the ma­chines of in­di­vid­ual pro­gram­mers.

The sec­ond, the MVP, is as cru­cial as the first one. A “Hel­lo World” is great, but it has no busi­ness val­ue. The MVP, how­ev­er, while miss­ing a lot of fea­tures the stake­hold­ers may want, is still pro­duc­ing some val­ue. From the mo­ment the MVP is re­leased, there are two in­ter­est­ing ef­fects:

  1. The con­fi­dence of stake­hold­ers in­crease even more. Es­sen­tial­ly, they can now de­cide to stop the pro­ject, and it will still bring val­ue to the busi­ness.

  2. The busi­ness may de­cide to en­list some per­sons to start us­ing the ap­pli­ca­tion. Maybe as beta testers, or maybe as or­di­nary users. Those users, in turn, pro­vide valu­able in­for­ma­tion about how they use the sys­tem, and what are their needs, which in turn helps pri­or­i­tiz­ing the changes.

Un­for­tu­nate­ly, more of­ten than not, busi­ness­es don't un­der­stand the val­ue of reg­u­lar de­liv­er­ies, TTM, first de­liv­ery and MVP. Some pro­jects are de­vel­oped as a black box: the busi­ness thrusts the re­quire­ments and an ar­bi­trary dead­line at the team, then com­plete­ly for­gets about the pro­ject, and starts ask­ing ques­tions only when the dead­line is close. While this is how pro­jects were usu­al­ly man­aged thir­ty years ago, it's not the right way to man­age them, and it brings all sort of prob­lems, which is il­lus­trat­ed by many, many phe­nom­e­nal fail­ures in the IT in­dus­try.

One of the prob­lems is that busi­ness­es usu­al­ly be­lieve that an MVP is the same as the ful­ly-fea­tured prod­uct. “Nice to have” fea­tures are then con­sid­ered as some­thing es­sen­tial, with­out which the prod­uct can­not go live. I wouldn't ex­plain in this ar­ti­cle why this hap­pens, but when it hap­pens, it is in­dica­tive of a bad­ly man­aged pro­ject, with in­cor­rect in­ter­ac­tions be­tween the team and the stake­hold­ers.

In­stead, an MVP is sim­ply some­thing that can bring val­ue on its own, and just that. It is usu­al­ly far from ide­al, but it can be suc­cess­ful­ly used to at­tract cus­tomers and bring mon­ey. When a pro­ject is a fruit of evo­lu­tion, as it should be in Ag­ile, MVP be­comes quite clear, thanks to two of its as­pects: the pri­or­i­ti­za­tion and the reg­u­lar de­liv­er­ies. The fact that the fea­tures are pri­or­i­tized by the busi­ness means that the de­vel­op­ers work first on the most valu­able fea­tures. The fact that the changes are de­liv­ered reg­u­lar­ly to the stake­hold­ers means that those stake­hold­ers see a con­crete re­sult, and can guess when what they see can be used as an ac­tu­al prod­uct.

Let me il­lus­trate what the MVP is all about through a few ex­am­ples.

An e-com­merce web­site

Long time ago, I was work­ing on a very spe­cif­ic e-com­merce web­site. A com­pa­ny was sell­ing the au­to­mo­bile parts to their part­ners—the oth­er com­pa­nies, ob­vi­ous­ly. Their lega­cy process in­volved sales­men call­ing the part­ners and agree­ing on the spe­cif­ic or­ders by phone. This was a huge waste of time, and so they want­ed to low­er the cost of the process through the World Wide Web.

In or­der to do that, one need­ed to:

The cus­tomer had a lot more in mind, but it ap­peared that those three fea­tures were enough for the ba­sic needs. You may note that there was no ques­tion of reg­is­tra­tion of new cus­tomers (a fea­ture which was quite chal­leng­ing to do in terms of se­cu­ri­ty, in­volv­ing write per­mis­sions to LDAP), or even on­line pay­ing (also chal­leng­ing be­cause of a se­ries of con­straints), or an ad­min­is­tra­tion part which would al­low some­one from the com­pa­ny to mod­i­fy the prod­ucts or check the an­a­lyt­ics. All that was nice to have, but wasn't part of the MVP. The abil­i­ty to de­liv­er the MVP in a very short amount of time was a huge ben­e­fit for the stake­hold­er, since it al­lowed the com­pa­ny to dras­ti­cal­ly re­duce the time the sales­men spent on the phone. More­over, it cost­ed near­ly noth­ing in terms of the cost of soft­ware de­vel­op­ment.

An ETL in­stead of an over­ly-com­pli­cat­ed sys­tem

A year ago, a col­league asked me for ad­vice. He was asked to work on a new pro­ject which was col­lect­ing data from a lot of data­bas­es and APIs, and ag­gre­gat­ing it, in or­der to gen­er­ate the re­ports. The orig­i­nal pro­ject spec­i­fi­ca­tion was four hun­dred pages long, and the pro­ject was ex­pect­ed to be done in one year by a team of five de­vel­op­ers.

The col­league was ask­ing how I would ap­proach the prob­lem from the per­spec­tive of ar­chi­tec­ture. We tried to mod­el it as an ETL, and it worked well. Then, I talked to him about the im­por­tance of pri­or­i­tiz­ing the fea­tures. He talked in turn to the busi­ness, and was so con­vinc­ing, that this was the first Ag­ile pro­ject done by the com­pa­ny.

Orig­i­nal­ly, the idea was to do every­thing from scratch. What they did, in­stead, is to grab an ex­is­tent ETL, with an in­ter­face which was sim­ple enough to be used by busi­nessper­sons to en­hance the trans­form step of the ETL, or even add new sources of data. This re­duced tremen­dous­ly the com­plex­i­ty and the cost of the pro­ject. They got their pri­or­i­ties right, and two months af­ter the pro­ject start­ed, the MVP was de­liv­ered. The busi­ness was amazed at how much val­ue it brings, and how flex­i­ble it was com­pared to the orig­i­nal con­cept. The team (of three per­sons in­stead of the orig­i­nal­ly ex­pect­ed five) was asked to do a few en­hance­ments, and worked for three ad­di­tion­al months. Then, the pro­ject was con­sid­ered a huge suc­cess; it was also the only pro­ject, among hun­dreds of oth­er in­ter­nal IT pro­jects, which was not late.

Who needs a data­base, when there are text files?

For my per­son­al needs, I start a lot of per­son­al pro­jects. Some end up be­ing valu­able tools that I use for years. Oth­ers are aban­doned. Un­til a few years ago, a new pro­ject which had per­sis­tence in it usu­al­ly meant that I would de­ploy a new data­base. But more re­cent­ly, I stopped do­ing that. When I need to store in­for­ma­tion, I use plain text files on an NFS share.

Tech­ni­cal­ly speak­ing, that's not a great long-term so­lu­tion. Per­for­mance is a con­cern. Con­cur­rent ac­cess could cause a lot of trou­ble. Se­cu­ri­ty is ques­tion­able. That's ob­vi­ous­ly not the so­lu­tion you would think about for pro­duc­tion ma­chines. Nev­er­the­less, the so­lu­tion ap­peared to work quite well for a few pro­jects.

One pro­ject is an API which stores val­ues from the sen­sors. By stor­ing the data plain-text in the files, I can post­pone the de­ci­sion of a type of data­base un­til the mo­ment where I would have enough in­sight to un­der­stand how much data there would be. Right now, I have no idea if I need to use Elas­tic­search, or In­fluxDB, or some­thing else. A few months lat­er, I would pos­si­bly have a bet­ter idea.

What is also im­por­tant is that by stick­ing with the most sim­ple stor­age so­lu­tion, I can de­liv­er the MVP in a mat­ter of days or some­times hours, start us­ing it, and fo­cus on oth­er pro­jects. Un­like a pro­to­type, though, those pro­jects weren't throw-away code: the per­sis­tence lay­er was clear­ly sep­a­rat­ed from the re­main­ing ap­pli­ca­tion, in or­der to swap the cur­rent mech­a­nism with a data­base lat­er on.


Work­ing for cus­tomers, it's not al­ways easy to ex­plain them the dif­fer­ence be­tween an MVP and a ful­ly-fea­tured prod­uct. Those who haven't used Ag­ile or used it wrong imag­ine that the very first re­lease should con­tain all the fea­tures they imag­ined. This, of­ten, re­sults in low cus­tomer sat­is­fac­tion, de­lays and missed dead­lines, fea­ture creep, and can­celled pro­jects. There­fore, great care should be tak­en to en­sure the stake­hold­ers un­der­stand what an MVP is, and why is it im­por­tant.