Extreme value delivery

Link to this section Legendary

Recently I watched Gary Bernhardt’s talk about the The Mother of All Demos as presented by Doug Engelbart in 1968. It’s the stuff of legend and for very good reason, just look at a high level list of what it debuted:

  • the mouse
  • the modem (I only just recently learned that the computer Doug was using was 48km away)
  • hypertext
  • collaborative editing
  • raster graphics

… and that is just at the high level - it was jam packed with new ideas and it’s effect on the attendees was overwhelmingly shocking - by the end he was showered with superlatives after a standing ovation and even was described as “dealing with lightning with both hands” .

On watching Gary’s talk, I was also alerted to how long Doug had been working on the system before presenting it - 18 years, the first 8 before anyone else even pitched in. 18 years?

Link to this section Enter the MVP

So this got me thinking about the modern day concept of the MVP or Minimum Viable Product. For the uninitiated, the MVP is essentially the idea of creating the simplest version (and no simpler eh Hemingway?) of a product so that it shows whether or not a product would be viable for it’s intended purpose i.e. to be sold. One of the main purposes being to minimise the effort wasted in case the product is inherently flawed / untenable as well as get feedback on an idea as soon as possible to direct further effort (MVP is quite the darling of Agile software delivery). With this in mind, I wonder the following:

  • If Doug had followed an MVP way of thinking what would he have demoed?
  • By focusing on the MVP is there a level of impact that is unattainable?
  • Doug demoed after 18 years - what societal mechanisms can support similar yet important flights of fancy?
  • We are also going to get some hits and misses, how can we build risk management into these mechanisms?
  • When is MVP appropriate, when is the Doug level of value appropriate or when is something in-between appropriate?
  • Following on, is there a metric to determine the level of value to deliver?

Link to this section Extreme value delivery

Perhaps the opposite of MVP, let’s call it Extreme Value Delivery (or Extremely Valuable Doug?), EVD for short, is worth considering when we consider the MVP. It reminds me of that story about AirBNB from the Masters of Scale podcast and the “11-star experience”. AirBNB dreamt up what an 11-star experience would look like for a customer e.g. Elon Musk would meet the would be guest at the airport after which they would get sent off into space via a shuttle. They then walked backwards from that experience to a level that they could possibly deliver in a reasonable amount of time. AirBNB probably isn’t the best example in this case, but just think what it would be like if they went away and actually could deliver something like that or closer to 11 stars? Imagine if they “Doug’d” it?

Something else to consider is how great it can feel to go all out on something beyond the practical as opposed to the MVP. For an immediate example of this, have a look at how much effort people spend on modifying things like cars , their desktop computer setup or their editor colour scheme . Time just flies (18 years!) when you are getting lost creating, no matter how crazy (Doug was literally considered a “crackpot” by contemporaries) the thing you are working on seems from the outside.

There are also other ways to think about MVP vs EVD including:

  • Multiple MVPs could be considered an EVD if released simultaneously
  • Is there a minimum level of value for an EVD? What does extreme equate to?
  • Perhaps there is also a maximum level after which it overloads the brain?

Link to this section Wrapping up

So that’s nice an’ all but what to take away? Personally I think one wants the best of both worlds - MVP for when speed is of greatest importance, EVD for passion projects and perhaps everyone should have at least one passion project going at all times. That’s what I will be trying to get more consistent on this year.