Today I Learned

Should a proof of concept be treated as a MVP?

| 2 min read

One of the most common mistakes companies make when creating a Proof of Concept is treating it as a little MVP. This results in prioritizing incrementalism over validation, in the long term, leading to building functionally flawed products because, despite formally saying yes, we have tested it development is based on assumptions prior to verification, because we don’t want what we've already done to go to waste (sunk cost fallacy bias).

And here's a descriptive, real-life example:

There’s a desk. I’ve designed it myself and the design includes two holes on the side - I saw it done in some other desk and wanted to transfer it to my own. One is for storing handy things, the other is a basket for used post-its and other paper scraps. I want to fill these holes with felt inserts – that I’ll sew myself as well.

I already have the fabric. Until yesterday, I also had assumptions about making these inserts (it's not only the dimensions, but also material plasticity behavior, etc). To verify them, I made a PoC of paper – I’m attaching the making of.

Zrzut ekranu 2022-09-30 o 10.42.43.png Zrzut ekranu 2022-09-30 o 10.42.58.png Zrzut ekranu 2022-09-30 o 10.42.50.png Zrzut ekranu 2022-09-30 o 10.43.06.png

What did I learn?

  • I can cut the whole thing out of one piece of fabric = confirmed hypothesis
  • I need to adjust the dimensions = discovery
  • I need to change the approach to turn-out the spine = discovery
  • I need to add appropriate folds on the sewn surfaces = confirmed hypothesis
  • I need to prepare for a small pivot should the turn-out not work = risk consideration

If I hadn’t done this, I would be ordering another piece of felt worth 40 złotych.

Summing up - the prototype that was created within the PoC has no use value - so it is not a product - neither full nor minimum deliverable one. The only thing that’s gonna be transferred to the target product is the concept after tweaks.

Of course, while working with digital products, it is possible to translate some of the code, designs, etc. produced during PoC into the target product, from an MVP, through the subsequent stages of its development. But making such assumptions from the beginning is like embracing a sunk cost fallacy.