davidbgk
/
larlet-fr-david-cache


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813
							<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang=fr>
<!-- Has to be within the first 1024 bytes, hence before the <title>
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset=utf-8>
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name=viewport content="width=device-width,minimum-scale=1,initial-scale=1,shrink-to-fit=no">
<!-- Required to make a valid HTML5 document. -->
<title>Making sense of MVP (Minimum Viable Product) - and why I prefer Earliest Testable/Usable/Lovable (archive) — David Larlet</title>
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/static/david/icons/favicon.ico">
<meta name="apple-mobile-web-app-title" content="David Larlet">
<meta name="application-name" content="David Larlet">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- That good ol' feed, subscribe :p. -->
<link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp">

<style>
/* http://meyerweb.com/eric/tools/css/reset/ */
html, body, div, span,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, address, big, cite, code,
del, dfn, em, img, ins,
small, strike, strong, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
  margin: 0;
  padding: 0;
  border: 0;
  font-size: 100%;
  font: inherit;
  vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section { display: block; }
body { line-height: 1; }
blockquote, q { quotes: none; }
blockquote:before, blockquote:after,
q:before, q:after {
  content: '';
  content: none;
}
table {
  border-collapse: collapse;
  border-spacing: 0;
}

/* http://practicaltypography.com/equity.html */
/* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */
/* https://www.filamentgroup.com/lab/js-web-fonts.html */
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');
  font-weight: 300;
  font-style: italic;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'ConcourseT3';
  src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),
       url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}


/* http://practice.typekit.com/lesson/caring-about-opentype-features/ */
body {
  /* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */
  font-family: "EquityTextB", Palatino, serif;
  background-color: #f0f0ea;
  color: #07486c;
  font-kerning: normal;
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: subpixel-antialiased;
  text-rendering: optimizeLegibility;
  font-variant-ligatures: common-ligatures contextual;
  font-feature-settings: "kern", "liga", "clig", "calt";
}
pre, code, kbd, samp, var, tt {
  font-family: 'TriplicateT4c', monospace;
}
em {
  font-style: italic;
  color: #323a45;
}
strong {
  font-weight: bold;
  color: black;
}
nav {
  background-color: #323a45;
  color: #f0f0ea;
  display: flex;
  justify-content: space-around;
  padding: 1rem .5rem;
}
  nav:last-child {
    border-bottom: 1vh solid #2d7474;
  }
  nav a {
    color: #f0f0ea;
  }
  nav abbr {
    border-bottom: 1px dotted white;
  }

h1 {
  border-top: 1vh solid #2d7474;
  border-bottom: .2vh dotted #2d7474;
  background-color: #e3e1e1;
  color: #323a45;
  text-align: center;
  padding: 5rem 0 4rem 0;
  width: 100%;
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
}
  h1.single {
    padding-bottom: 10rem;
  }
  h1 span {
    position: absolute;
    top: 1vh;
    left: 20%;
    line-height: 0;
  }
    h1 span a {
      line-height: 1.7;
      padding: 1rem 1.2rem .6rem 1.2rem;
      border-radius: 0 0 6% 6%;
      background: #2d7474;
      font-size: 1.3rem;
      color: white;
      text-decoration: none;
    }
h2 {
  margin: 4rem 0 1rem;
  border-top: .2vh solid #2d7474;
  padding-top: 1vh;
}
h3 {
  text-align: center;
  margin: 3rem 0 .75em;
}
hr {
  height: .4rem;
  width: .4rem;
  border-radius: .4rem;
  background: #07486c;
  margin: 2.5rem auto;
}
time {
  display: bloc;
  margin-left: 0 !important;
}
ul, ol {
  margin: 2rem;
}
ul {
  list-style-type: square;
}
a {
  text-decoration-skip-ink: auto;
  text-decoration-thickness: 0.05em;
  text-underline-offset: 0.09em;
}
article {
  max-width: 50rem;
  display: flex;
  flex-direction: column;
  margin: 2rem auto;
}
  article.single {
    border-top: .2vh dotted #2d7474;
    margin: -6rem auto 1rem auto;
    background: #f0f0ea;
    padding: 2rem;
  }
  article p:last-child {
    margin-bottom: 1rem;
  }
p {
  padding: 0 .5rem;
  margin-left: 3rem;
}
  p + p,
  figure + p {
    margin-top: 2rem;
  }

blockquote {
  background-color: #e3e1e1;
  border-left: .5vw solid #2d7474;
  display: flex;
  flex-direction: column;
  align-items: center;
  padding: 1rem;
  margin: 1.5rem;
}
  blockquote cite {
    font-style: italic;
  }
  blockquote p {
    margin-left: 0;
  }

figure {
  border-top: .2vh solid #2d7474;
  background-color: #e3e1e1;
  text-align: center;
  padding: 1.5rem 0;
  margin: 1rem 0 0;
  font-size: 1.5rem;
  width: 100%;
}
  figure img {
    max-width: 250px;
    max-height: 250px;
    border: .5vw solid #323a45;
    padding: 1px;
  }
figcaption {
  padding: 1rem;
  line-height: 1.4;
}
aside {
  display: flex;
  flex-direction: column;
  background-color: #e3e1e1;
  padding: 1rem 0;
  border-bottom: .2vh solid #07486c;
}
  aside p {
    max-width: 50rem;
    margin: 0 auto;
  }

/* https://fvsch.com/code/css-locks/ */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
  font-size: 1rem;
  line-height: calc( 1.5em + 0.2 * 1rem );
}
h1 {
  font-size: 1.9rem;
  line-height: calc( 1.2em + 0.2 * 1rem );
}
h2 {
  font-size: 1.6rem;
  line-height: calc( 1.3em + 0.2 * 1rem );
}
h3 {
  font-size: 1.35rem;
  line-height: calc( 1.4em + 0.2 * 1rem );
}
@media (min-width: 20em) {
  /* The (100vw - 20rem) / (50 - 20) part
     resolves to 0-1rem, depending on the
     viewport width (between 20em and 50em). */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );
    margin-left: 0;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
}
@media (min-width: 50em) {
  /* The right part of the addition *must* be a
     rem value. In this example we *could* change
     the whole declaration to font-size:2.5rem,
     but if our baseline value was not expressed
     in rem we would have to use calc. */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * 1rem );
    line-height: 1.5em;
  }
  p, li, pre, details {
    margin-left: 3rem;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * 1rem );
    line-height: 1.2em;
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * 1rem );
    line-height: 1.3em;
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * 1rem );
    line-height: 1.4em;
  }
  figure img {
    max-width: 500px;
    max-height: 500px;
  }
}

figure.unsquared {
  margin-bottom: 1.5rem;
}
  figure.unsquared img {
    height: inherit;
  }


@media print {
  body { font-size: 100%; }
  a:after { content: " (" attr(href) ")"; }
  a, a:link, a:visited, a:after {
    text-decoration: underline;
    text-shadow: none !important;
    background-image: none !important;
    background: white;
    color: black;
  }
  abbr[title] { border-bottom: 0; }
  abbr[title]:after { content: " (" attr(title) ")"; }
  img { page-break-inside: avoid; }
  @page { margin: 2cm .5cm; }
  h1, h2, h3 { page-break-after: avoid; }
  p3 { orphans: 3; widows: 3; }
  img {
    max-width: 250px !important;
    max-height: 250px !important;
  }
  nav, aside { display: none; }
}

ul.with_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_columns {
    column-count: 2;
  }
}
@media (min-width: 50em) {
  ul.with_columns {
    column-count: 3;
  }
}
ul.with_two_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_two_columns {
    column-count: 1;
  }
}
@media (min-width: 50em) {
  ul.with_two_columns {
    column-count: 2;
  }
}

.gallery {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-around;
}
  .gallery figure img {
    margin-left: 1rem;
    margin-right: 1rem;
  }
  .gallery figure figcaption {
    font-family: 'ConcourseT3'
  }

footer {
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
  border-top: 3px solid white;
  padding: 4rem 0;
  background-color: #07486c;
  color: white;
}
  footer > * {
    max-width: 50rem;
    margin: 0 auto;
  }
  footer a {
    color: #f1c40f;
  }
  footer .avatar {
    width: 200px;
    height: 200px;
    border-radius: 50%;
    float: left;
    -webkit-shape-outside: circle();
    shape-outside: circle();
    margin-right: 2rem;
    padding: 2px 5px 5px 2px;
    background: white;
    border-left: 1px solid #f1c40f;
    border-top: 1px solid #f1c40f;
    border-right: 5px solid #f1c40f;
    border-bottom: 5px solid #f1c40f;
  }
</style>

<h1>
  <span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>
  Making sense of MVP (Minimum Viable Product) - and why I prefer Earliest Testable/Usable/Lovable (archive)
  <time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>
</h1>
<section>
  <article>
    <h3><a href="http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp">Source originale du contenu</a></h3>
    <p>A couple of years ago I drew this picture and started using it in various presentations about agile and lean development:</p>

<p><a href="https://blog.crisp.se/wp-content/uploads/2016/01/mvp.png"><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-.jpg" alt=""/></span></a></p>

<p>Since then the drawing has gone viral! Shows up all over the place, in articles and presentations, even in a book (Jeff Patton’s “<a href="http://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909">User Story Mapping</a>”  – an excellent read by the way). Many tell me the drawing really captures the essence of iterative &amp; incremental development, lean startup, MVP (minimum viable product), and what not. However, some misinterpret it, which is quite natural when you take a picture out of it’s original context. Some criticize it for oversimplifying things, which is true. The picture is a metaphor. It is not about actual car development, it is about product development in general, using a car as a metaphor.</p>

<p>Anyway, with all this buzz, I figured it’s time to explain the thinking behind it.</p>

<p><span id="more-7646"/></p>

<h2>First example – Not Like This</h2>

<p>The top row illustrates a common misconception about iterative, incremental product development (a.k.a Agile).</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-1.jpg" alt=""/></span></p>

<p>Many projects fail badly because they do Big Bang delivery (build the thing until 100% done and deliver at the end). I’ve lost count of the number of failed projects I’ve seen because of this (scroll down for some examples). However, when Agile is presented as an alternative people sometimes balk at the idea of delivering an unfinished product – who wants <em>half</em> of a car?. Imagine this:</p>

<p>“Here sir, here’s our first iteration, a front tire. What do you think?”</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-2.jpg" alt=""/></span></p>

<p>Customer is like “Why the heck are you delivering a tire to me? I ordered a CAR! What am I supposed to do with this?”</p>

<p>(By the way, I’m using the term “customer” here as a generic term to represent people like product managers, product owners, and early adopter users).</p>

<p>With each delivery the product gets closer to done, but the customer is still angry because he can’t actually use the product. It’s still just a partial car.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-3.jpg" alt=""/></span></p>

<p>And finally, when the product is done, the customer is like “Thanks! Finally! Why didn’t you just deliver this in the first place, and skip all the other useless deliveries?”.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-4.jpg" alt=""/></span></p>

<p>In this example he’s happy with the final product, because it’s what he ordered. In reality, that’s usually not true. A lot of time has passed without any actual user testing, so the product is most likely riddled with design flaws based on incorrect assumptions about what people need.  So that smiley face at the end is pretty idealistic.</p>

<p>Anyway, the first row represents “bastardized agile”. Technically it might be incremental and iterative delivery, but the absence of an actual feedback loop makes it very risky – and definitely not agile.</p>

<p>Hence the “Not Like This” heading.</p>

<h2>Second example – Like this!</h2>

<p>Now for the second row.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-5.jpg" alt=""/></span></p>

<p>Here we take a very different approach. We start with the same context – the customer ordered a car. But this time we don’t just build a car. Instead we <strong>focus on the underlying need the customer wants fulfilled</strong>. Turns out that his underlying need is “I need to get from A to B faster”, and Car is just one possible solution to that. Remember, car is just a metaphor, think any kind of customized product development situation.</p>

<p>So the team delivers the smallest thing they can think of that will get the customer testing things and giving us feedback. Some might call it an MVP (Minimum Viable Product), but I prefer to call it Earliest Testable Product (more on that further down).</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-6.jpg" alt=""/></span></p>

<p>Call it what you like (some even call their first release the “the skateboard version” of the product, based on this metaphor….).</p>

<p>The customer is unlikely to be happy with this. This is nowhere near the car he ordered. But that’s OK! Here’s the kicker – <strong>we’re not trying to make the customer happy at this point</strong>. We might make a few early adopters happy (or <a href="http://ericsink.com/Act_Your_Age.html">pragmatists in pain</a>), but our <strong>main goal at this point is just to <em>learn</em></strong>. Ideally, the team explains this clearly to the customer in advance, so he isn’t too disappointed.</p>

<p>However, as opposed to the front wheel in the first scenario, the skateboard is actually a usable product that helps the customer get from A to B. Not great, but a tiny bit better than nothing. So we tell the customer “don’t worry, the project is not finished, this was just the first of many iterations. <strong>We’re still aiming to build a car, but in the meantime please try this and give us feedback</strong>“. Think big, but deliver in small functionally viable increments.</p>

<blockquote><p><em>We might learn some really surprising things. Suppose the customer says he hates the skateboard, we ask why, and he says “I hate the color”. We’re like “uh…. the color? That’s all?”. And the customer says “Yeah, make it blue! Other than that, it’s fine!”. You just saved *alot* of money not building the car! Not likely, but who knows?</em></p></blockquote>

<p>The key question is “<strong>What is the cheapest and fastest way we can start learning?</strong>” Can we deliver something even earlier than a skateboard? How about a bus ticket?</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-7.jpg" alt=""/></span></p>

<p>Will this help solve the customer’s problem? Maybe, maybe not, but we’ll definitely learn something by putting this into the hands of real users. <a href="http://theleanstartup.com/book">Lean Startup</a> offers a great model based on listing your actual hypotheses about the users and then working systematically to validate or invalidate them.</p>

<p>You don’t need to test the product on all users, and you don’t need to build a product to test something. <strong>Testing a prototype on even a single user will teach you more than nothing.</strong></p>

<p>But OK, back to the skateboard example.</p>

<p>After playing around with it in the office, the customer says “OK, kind of fun, and it does get me to the coffee machine faster. But it’s unstable. I fall off too easily”.</p>

<p>So the next iteration we try to solve that problem, or at least learn more about it.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-8.jpg" alt=""/></span></p>

<p>Customer can now get around the office without falling off!</p>

<p>Happy? Not really, he still kind of wants that car. But <strong>in the meantime he is actually using this product, and giving us feedback</strong>. His biggest complaint is that it’s hard to travel longer distances, like between buildings, due to the small wheels and lack of breaks. So, next release the product morphs into something like a bicycle.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-9.jpg" alt=""/></span></p>

<p>Now the customer can zoom around campus. Yiihaaa!</p>

<p>We learn some things along the way: The customer likes the feeling of fresh air on his face. The customer is on a campus, and transportation is mostly about getting around between buildings.</p>

<p><strong>The bicycle may turn out to be a much better product than the car originally envisioned</strong>. In fact, while testing out this product we may learn that the paths are too narrow for a car anyway. We just saved the customer tons of time and money, and gave him a better product in less time!</p>

<blockquote><p><em>Now you may be thinking  “but shouldn’t we already have known that. via up-front analysis of the customer’s context and needs?” Good point. But in most real-life product development scenarios I’ve seen,<strong> no matter how much up-front analysis you do, you’re still surprised when you put the first real release into the hands of a real user</strong>, and many of your assumptions turn out to be way off.</em></p>
<p><em>So <strong>yes, do some up-front analysis, discover as much as you can before starting development. But don’t spend too much time on it and don’t trust the analysis too much</strong> – start prototyping and releasing instead, that’s when the real learning happens.</em></p></blockquote>

<p>Anyway, back to the story. Perhaps the customer wants more. Sometimes he needs to travel to another city, and the bike ride is too slow and sweaty. So next iteration we add an engine.</p>

<p> </p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-10.jpg" alt=""/></span></p>

<p>This model is especially suitable for software, since software is, well, Soft. You can “morph” the product as you go, as opposed to hardware where you essentially have to rebuild every time. However, even in hardware projects there is a huge benefit to delivering prototypes to observe and learn from how the customer uses your product. It’s just that the iterations tend to be a bit longer (months instead of weeks). Even actual car companies like Toyota and Tesla do a lot of prototyping (sketches, 3d models, <a href="http://www.toyota-global.com/showroom/toyota_design/voice_of_design/03.html">full-scale clay models</a>, etc) before developing a new car model.</p>

<p>So now what? Again, maybe the customer is happy with the motorcycle. We could end the project earlier than planned. Most products are riddled with complexity and features that nobody uses. The iterative approach is really a way of delivering less, or <strong>finding the simplest and cheapest way to solve the customer’s problem</strong>. Minimize the distance to Awesome. Very Zen.</p>

<p>Or, again, the customer could choose to continue, with or without modifications to the requirements. We may in fact end up with the exact same car as originally envisioned. However it is much more likely that we gain vital insights along the way and end up with something slightly different. Like this:</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-11.jpg" alt=""/></span></p>

<p>The customer is overjoyed! Why? Because we learned along the way that he appreciates fresh air in his face, so we ended up with a convertible. <strong>He did get a car after all – but a better car than originally planned!</strong></p>

<p>So let’s take a step back.</p>

<h2>What’s your skateboard?</h2>

<p>The top scenario (delivering a front tire) sucks because we keep delivering stuff that the customer can’t use at all. If you know what you’re doing – your product has very little complexity and risk, perhaps you’ve built that type of thing hundreds of times before – then go ahead and just do big bang. Build the thing and deliver it when done.</p>

<p>However, most product development efforts I’ve seen are much too complex and risky for that, and the big bang approach all too often leads to huge expensive failures. So the key question is <strong>What’s your skateboard?</strong></p>

<p>In product development, one of the first things you should do (after describing what problem you are trying to solve for whom) is to identify your skateboard-equivalent. <strong>Think of the skateboard as a metaphor for the smallest thing you can put in the hands of real users, and get real feedback</strong>. Or use “bus ticket” if that metaphor works better.</p>

<p>This will give you the vitally needed feedback loop, and will give both you and the customer control over the project – you can learn and make changes, instead of just following the plan and hoping for the best.</p>

<p>Let’s take at some real-life examples.</p>

<h2>Example 1: Spotify music player</h2>

<blockquote><p><em>“With over 75 million users, it’s hard to remember a time without Spotify. But there was. A time when we were all mulling the aisles of Target for new CDs. A time in our lives where we all became thieves on Napster. A time when iTunes forced us to buy songs for $2/piece. And then came Spotify.”</em> –<a href="http://techcrunch.com/gallery/a-brief-history-of-spotify/">Tech Crunch</a></p></blockquote>

<p><a href="http://www.spotify.com">Spotify</a> is a pretty fancy product now. But it didn’t start that way. I was lucky to be involved pretty early in this amazing journey (and still am).</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-12.jpg" alt=""/></span></p>

<p>As a startup in 2006, Spotify was founded on some key assumptions – that people are happy to stream (rather than own) music, that labels and artists are willing to let people do so legally, and that fast and stable streaming is technically feasible. Remember, this was 2006 when music streaming (like Real Player) was a pretty horrible experience, and pirate-copied music was pretty much the norm. The technical part of the challenge was: “Is it even possible to make a client that streams music instantly when you hit the Play button? Is it possible to get rid of that pesky ‘Buffering’ progress bar?”</p>

<p><strong>Starting small doesn’t mean you can’t think big.</strong> Here’s one of the early sketches of what they had in mind:</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-13.jpg" alt=""/></span></p>

<p>But instead of spending years building the whole product, and then finding out if the assumptions hold, the developers basically sat down and hacked up a technical prototype, put in whatever ripped music they had on their laptops, and started experimenting wildly to find ways to make playback fast and stable. The driving metric was “how many milliseconds does it take from when I press Play to when I hear the music?”. It should play pretty much instantly, and continue playing smoothly without any stuttering!</p>

<blockquote><p><em>“We spent an insane amount of time focusing on latency, when no one cared, because we were hell bent on making it feel like you had all the world’s music on your hard drive. Obsessing over small details can sometimes make all the difference. That’s what I believe is the biggest misunderstanding about the minimum viable product concept. That is the V in the MVP.” </em>-Daniel Ek, co-founder and CEO</p></blockquote>

<p>Once they had something decent, they started testing on themselves, their family, and friends.</p>

<p><span><img class="" title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-14.jpg" alt=""/></span></p>

<p>The initial version couldn’t be released to a wider audience, it was totally unpolished and had basically no features except the ability to find and play a few hard-coded songs, and there was no legal agreement or economic model. It was their skateboard.</p>

<p>But they <strong>shamelessly put the skateboard in the hands of real users</strong> – friends and family – and they quickly got the answers they needed. Yes, it was technically possible. And yes, people absolutely loved the product (or more like, what the product can become)! The <strong>hypotheses were validated</strong>! This running prototype helped convince music labels and investors and, well, the rest is history.</p>

<h2>Example 2: Minecraft</h2>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-15.jpg" alt=""/></span></p>

<p><a href="https://minecraft.net/">Minecraft</a> is one of the most successful games in the history of game development, especially if you take development cost into consideration. Minecraft is also one of the most extreme examples of the release-early-and-often mindset. The first public release was made after just <a href="http://minecraft.gamepedia.com/Version_history">6 days of coding</a>, by <a href="https://en.wikipedia.org/wiki/Markus_Persson">one guy</a> ! You couldn’t do much in the first version – it was basically an ugly blocky 3d-landscape where you can dig up blocks and place them elsewhere to build crude structures.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-16.jpg" alt=""/></span></p>

<p>That was the skateboard.</p>

<p>The users were super-engaged though (most developer-user communication happened via Twitter, pretty funny). Among the early users were me and my four kids.  <a href="http://minecraft.gamepedia.com/Version_history">Over hundred releases</a> were made during the first year. Game development is all about finding the fun (some game companies I’ve worked with use the term “Definition of Fun” instead of “Definition of Done”), and the best way to do that is by having real people actually play that game – in this cases thousands of real people who had actually paid to try the early access version and therefore had a personal incentive to help improve the game.</p>

<p>Gradually a small development team was formed around the game (mostly 2 guys actually), and the game became a smash hit all over the world. I don’t think I’ve met any kid anywhere who doesn’t play Minecraft. And last year the game (well, the <a href="https://mojang.com/">company</a> that was formed around the game) was sold to Microsoft for $2.5 billion. Quite amazing.</p>

<h2>Example 3: Big Government Project</h2>

<p>Around 2010 the <a href="https://polisen.se/">Swedish Police</a> started a big initiative to enable police to spend more time in the field and less time at the station – PUST (Polisens Utrednings STöd). A fascinating project, I was involved as coach and wrote a book about what we did and what we learned (<a href="https://pragprog.com/book/hklean/lean-from-the-trenches">Lean from the Trenches</a>).</p>

<p> </p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-17.jpg" alt=""/></span></p>

<p>The idea was to put laptops in the cars, and customized software to give police access to the systems they need in real-time, for example while interrogating a suspect (this was the pre-tablet age).</p>

<p>They had tried to build similar systems in the past and failed miserably, mainly because of Big Bang thinking. They told me that one of their previous attempts took 7 years from inception to first release. SEVEN YEARS! By then of course everything had changed and the project was a total failure. So this time they wanted to do it differently.</p>

<p>The 60-person project (later referred to as “PUST Java”) succeeded surprisingly well, especially for being a big government project (it even came second in CIO Awards “<a href="http://cio.event.idg.se/event/awards2011/">Project of the Year</a>”). One of the main success factors was that they <strong>didn’t try to build the whole thing at once</strong> – they split the elephant along two dimensions:</p>

<ul>
<li>By Region. We don’t need to release to ALL of Sweden at once, we could start by releasing to just one region.</li>
<li>By Crime type. We don’t need to support ALL crime types initially, we could start by just supporting 1-2 crime types.</li>
</ul>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-18.jpg" alt=""/></span></p>

<p> </p>

<p>The first version, 1.0, was their skateboard.</p>

<p>It was a small system, supporting just a couple of crime types, and it was field-tested on a handful of cops in Östergötland (a region in Sweden). Other crime types had to be dealt with the old way – drive to the station and do paperwork. <strong>They knew they were guinea pigs, and that the product was nowhere near finished</strong>. But they were happy to test it, because they knew the alternative. They had seen what kind of crappy systems come out of processes that lack early user feedback, and now they <strong>finally had a chance to influence a system while it was being built</strong>!</p>

<p>Their feedback was harsh and honest. Many of our assumptions flew out the window, and one of the big dilemmas was what to do with all the carefully crafted Use Case specifications that were getting less and less relevant as the real user feedback came in (this was an organization with a waterfall history and a habit of doing big upfront analysis).</p>

<p>Anyway, long story short, the <strong>early feedback was channeled into product improvements</strong> and, gradually, as the those cops in Östergötland started liking the product, we could add more crime types and spread it to more regions. By the time we got to the big release (1.4), with nationwide rollout and training of 12000 police, we weren’t all that worried.<strong> We had done so many releases, so much user testing, that we slept well on the night of the nationwide release.</strong></p>

<p>Unfortunately the victory was short-lived. A follow-up project (PUST Siebel) <a href="https://blog.crisp.se/2014/02/21/henrikkniberg/pust-lardomar">botched it</a> and went back to waterfall-thinking, probably due to old habit. 2 years of analysis and testing without any releases or user-testing, followed by a big-bang release of the “next generation” of the product to all 12,000 police at once. It was an absolute disaster, and after half a year of hemorrhaging they shut the whole thing down. The development cost was about €20 million, but Internal studies estimate that the cost to Swedish society (because the police were handicapped by the horrible system) was on the order of <a href="http://www.blaljus.nu/nyhetsartikel/kostnaden-pust-siebel-10-miljarder">€1 Billion</a>!</p>

<p>Pretty expensive way to learn!</p>

<h2>Example 4: Lego</h2>

<p>I’m currently working at <a href="http://www.lego.com">Lego</a>, and I’m amazed by their ability to deliver new smash-hits, year after year without fail. I hear lots of interesting stories about how they do this, and the common theme is prototyping and early user testing! I often see groups of kids in the office, and designers collaborate with local kindergartens and schools and families to field-test the latest product ideas.</p>

<p>Here’s a recent example – <a href="http://www.lego.com/nexoknights/">Nexo Knights</a> (released Jan 2016):</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-19.jpg" alt=""/></span></p>

<p>When they first started exploring this concept, they did paper prototypes and brought to small kids. The kids’ first reaction was “hey, who are the bad guys? I can’t see who’s good and who’s bad!”. Oops. So the designers kept iterating and testing until they found a design that worked with the kids. I bet even you can see who’s good and who’s evil in the picture above…</p>

<p>Not sure exactly where the skateboard is in this story, but you get the idea – <strong>early feedback from real users</strong>! Don’t just design the product and build the whole thing. Imagine if they had built the product based on their original design assumptions, and learned about the problem <em>after</em> delivering thousands of boxes to stores all over the world!</p>

<p>Lego also has it’s share of hard-earned failures. One example is <a href="https://en.wikipedia.org/wiki/Lego_Universe">Lego Universe</a>, a massively multiplayer online Lego world. Sounds fun huh? Problem is, they got overambitious and ended up trying to build the whole thing to perfection before releasing to the world.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-20.jpg" alt=""/></span></p>

<p>About <a href="http://250 people worked for 4-5 years">250 people worked for 4-5 years</a> (because of constant scope creep due to perfectionism), and when the release finally came the reception was… lukewarm. The finished game was beautiful, but not as fun as expected, so the product was shut down after 2 years.</p>

<p><strong>There was no skateboard!</strong></p>

<p>Why not? Because skateboards aren’t Awesome (at least not if you’re expecting a car), and Lego’s culture is all about delivering Awesome experiences! If you work at Lego HQ in Billund, Denmark you walk past this huge mural every day:</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-21.jpg" alt=""/></span></p>

<p>Translates roughly to “Only the best is good enough”. It has been Lego’s guiding principle ever since the company started 80+ years ago, and has helped them become one of the most successful companies in the world. But in this case the principle was misapplied. <strong>The</strong> <strong>hunt for perfection delayed vital feedback</strong>, which meant mistaken assumptions about what the users like and don’t like. The exact opposite of Minecraft.</p>

<p>Interestingly enough the Lego Universe teams were actually using Scrum and iterating heavily – just like the Minecraft guys did. But the releases were only internal. So there was most likely a skateboard, and a bicycle, and so on, but those products never reached real users. That’s not how Scrum is intended to be used.</p>

<p>It was an expensive failure, but Lego learned from it and they are constantly getting better at early testing and user feedback.</p>

<h2>Improving on “MVP”</h2>

<p>And that (deep breath…) brings me to the topic of MVP – Minimum Viable Product.</p>

<p>The underlying idea is great, but the term itself causes a lot of confusion and angst. I’ve met many customers that are like “No Way do I want an MVP delivery –  that’s the last delivery I’ll get!” All too often teams deliver the so-called Minimum Viable Product, and then quickly get whisked away to the next project, leaving the customer with a buggy, unfinished product. <strong>For some customers, MVP = MRC (Minimum Releasable Crap).</strong></p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-22.jpg" alt=""/></span></p>

<p>I know, I know, this comes down to bad management rather than the term MVP, but still… the term invites misunderstanding. “Minimum” and “Viable” mean different things to different people, and that causes problems.</p>

<p>So here’s an alternative.</p>

<p>First of all, replace the word “Minimum” with “Early”. The whole idea behind releasing an MVP is to get early feedback – by delivering a minimum product rather than a complete product, we can get the feedback earlier.</p>

<p><strong>Few customers want “minimum” but most customers want “early”</strong>! So that’s our first change:</p>

<p>Minimum =&gt; Earliest</p>

<p>Next, remove the word “Viable” since it’s too vague. <strong>Your “viable” is my “horrible”</strong>. Some people think Viable means “something I can test and get feedback from”, others think it means “something the customer can actually use”. So let’s be more explicit and split it into three different things:</p>

<p> </p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-23.jpg" alt=""/></span></p>

<p> </p>

<p><strong>Earliest Testable Product</strong> is the skateboard or bus ticket – the <strong>first release that customers can actually do something with</strong>. Might not solve their problem, but it generates at least some kind of feedback. We make it very clear that learning is the main purpose of this release, and that any actual customer value will be a bonus.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-24.jpg" alt=""/></span><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-25.jpg" alt=""/></span></p>

<p> </p>

<p><strong>Earliest Usable Product</strong> is perhaps the bicycle. The <strong>first release that early adopters will actually use, willingly</strong>. It is far from done, and it might not be very likeable. But it does put your customers in a better position than before.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-26.jpg" alt=""/></span></p>

<p> </p>

<p><strong>Earliest Lovable Product</strong> is perhaps the motorcycle. The<strong> first release that customers will love, tell their friends about, and be willing to pay for.</strong> There’s still lots to improve, and we may still end up with a convertible, or a plane, or something else. But we’ve reached the point where we have a truly marketable product.</p>

<p><span><img title="" src="https://blog.crisp.se/wp-content/uploads/2016/01/Making-sense-of-MVP-27.jpg" alt=""/></span></p>

<blockquote><p><em>I considered adding an even earlier step “<strong>Earliest Feedbackable Product</strong>”, which is basically the paper prototype or equivalent that you use to get your first feedback from the customer. But four steps seems too many, and the word Feedbackable….. ugh. But nevertheless, that is also an important step. Some would call a paper prototype the Earliest Testable Product, but I guess that comes down to how you define Testable. Check out <a href="https://www.crisp.se/mvpguide">Martin’s MVP Guide</a> to learn more – he’s got plenty of super-concrete examples of how to get early feedback with minimum investment.</em></p></blockquote>

<p>Of course people can still misinterpret Earliest Testable/Usable/Lovable, but it’s at least one step more explicit than the nebulous Minimum Viable Product.</p>

<h2>Takeaway points</h2>

<p>OK time to wrap it up. Never thought it would get this long, thanks for sticking around! Key takeaways:</p>

<ul>
<li><strong>Avoid Big Bang</strong> delivery for complex, innovative product development. Do it iteratively and incrementally. You knew that already. But are you actually doing it?</li>
<li><strong>Start by identifying your skateboard</strong> – the earliest testable product. Aim for the clouds, but swallow your pride and start by delivering the skateboard.</li>
<li><strong>Avoid the term MVP</strong>. Be more explicit about what you’re actually talking about. Earliest testable/usable/lovable is just one example, use whatever terms are least confusing to your stakeholders..</li>
</ul>

<p>And remember – the skateboard/car drawing is just a metaphor. Don’t take it too literally :o)</p>

<p>PS – here’s a fun story about how my kids and I used these principles to win a <a href="https://blog.crisp.se/2015/10/06/henrikkniberg/how-2-kids-and-adult-rookies-won-a-robot-sumo-competition">Robot Sumo competition</a> :o)</p>

<p><em>Thanks Mary Poppendieck, Jeff Patton, Alistair Cockburn, Anders Haugeto, Sophia, colleagues from Crisp, Spotify and Lego, and everyone else who gave tons of useful feedback.</em></p>
  </article>
</section>


<nav id="jumpto">
  <p>
    <a href="/david/blog/">Accueil du blog</a> |
    <a href="http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp">Source originale</a> |
    <a href="/david/stream/2019/">Accueil du flux</a>
  </p>
</nav>

<footer>
  <div>
    <img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">
    <p>
      Bonjour/Hi!
      Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>
      Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).
    </p>
    <p>
      Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.
    </p>
    
    <p>
      Voici quelques articles choisis :
      <a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,
      <a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,
      <a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,
      <a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,
      <a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,
      <a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,
      <a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,
      <a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,
      <a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,
      <a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,
      <a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,
      <a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,
      <a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,
      <a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,
      <a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,
      et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>
    </p>
    <p>
      On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.
    </p>
    <p>
      Je ne traque pas ta navigation mais mon
      <abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>
      conserve des logs d’accès.
    </p>
  </div>
</footer>
<script type="text/javascript">
  ;(_ => {
    const jumper = document.getElementById('jumper')
    jumper.addEventListener('click', e => {
      e.preventDefault()
      const anchor = e.target.getAttribute('href')
      const targetEl = document.getElementById(anchor.substring(1))
      targetEl.scrollIntoView({behavior: 'smooth'})
    })
  })()
</script>