On building failing digital products.

Photo by Simson Petrol on Unsplash

The one major pitfall in digital development that nearly all organizations make is:

Wanting to create a perfect product in one go.

This is true for both larger, multinational companies, small start-ups and everything in between. Even in lean and agile development environments, organizations more often than not use sprints to chop-up a waterfall approach, with big research-, strategy-, and design-sprints (sprint zeroes) before actually building something, releasing a finished product at the bottom of the waterfall in one big splash.

While the generally applauded original goal of agile and the scrum framework is to release early and often. An approach which is apparently difficult to follow.

MVP misnomer

I believe that it is difficult to follow because agile methodologies assume that even in complex environments you can release a value-adding Minimal Viable Product (MVP) after one sprint. Which is true, but unfortunately most people understand ‘Viable’ as a first version of a product that is good enough to perform well in an professional environment.

This is incorrect. ‘Viable’ is the first version of a product which is advanced enough to fail.

Artistic creation as example

An illustration. In my free time I like to create digital artworks and I avidly follow contemporary art practices of both famous and unknown artists. One crucial thing I’ve learned in creating art is that you need to create a lot of art! In order to develop your technique, your own style, to figure out what you like and what you don’t, to figure out how people respond on various expressions it is crucial to create a lot of artworks. And even more importantly you have to create a lot of ugly, miserably failed artworks to reach a state of good work. For each great artwork hundreds of failed works are needed. Rembrandt didn’t wake up one morning and decided to paint the Nightwatch and then did it, it took a gazillion drawings and experiments to get to that point.

The visibility of failure

For digital products, where the price of failure is generally low and adaptability high (compared with for example construction work or aviation engineering), the same process can apply. In order to reach a brilliant product you have to create a lot of (partially) failed ones. And in order to know if a product, feature or expression failed, you have to expose it to the world at some point. And rather sooner than later, as captured in famous motto’s like ‘fail fast, fail often, fail better’ etc.

This visibility of failure takes a lot of guts and perseverance, but is worth it in the end. It not only makes the product better in the long run and stimulates innovation, pushing boundaries and creativity, but also creates an air of learning, transparency and open communication with stakeholders & customers. Tapping in to the core power and raison d’être of the internet.

I believe transparent learning & failing is preferable over a closed, monolith-like, unrealistic perfection image that a lot of organizations try to convey. And in their desire for perfection, fall short, right into an uncanny valley and as a result express sloppiness or worse, repulse stakeholders and potential customers.

The MFP

So, instead of aiming at the misleadingly named Minimal Viable Product, let’s aim for a Minimal Fallible Product (MFP). A product with enough elements of your hypothesis in it to let it fail. After that, rinse and repeat. (This is where the motto’s ‘kill a feature every day’ or ‘kill your darlings’ come in handy.)

Stressing public failure and transparent learning will relieve pressure to succeed and will achieve a more effective and quicker classic cycle of building, measuring, learning and building again. Even for bigger organizations the realization that the product is learning on the go, will relieve pressure on internal stakeholders to get ‘their feature’ developed immediately. After all, there are many rounds to get that feature in there (and get it wrong and then kill it again.)

To be clear, I am not saying anything new here. This is what lean startup and agile are all about and many ‘guru’s’ have been advocating. And it is quite successfully applied in for example open source communities or the gaming industry. Through platforms like Steam, indie game development studio’s release bug-ridden alpha-versions of their games very early and iterate quickly in order to learn from actual players what works and what doesn’t, while in the meantime establishing a loyal fanbase and visibility.

My MFP mnemonic is just a reminder to actually do this in all sorts of digital development projects.

Walk the walk

So to put my money where my mouth is, my new personal website will be created according to this principle. Here’s the first MFP version. Designed and coded by me (a non-designer / non-coder) in one afternoon. Tell me what it conveys to you? And how can it be made better according to you? Think about any perspective you want: technical, design, business, user experience, accessibility etc. Be brutal.

From this first iteration I hope to create my next version soon and write another essay on the lessons learned about the process and the product. So feedback and stay tuned.

Also, do you have or know of failing projects running publicly right now? Let me know! I’d love to see and contribute to what is happening.