How to avoid protoduction fails

How to avoid protoduction fails

“Protoduction: a prototype that ends up in production.”

Disclaimer first, this term isn’t new and appeared on the internet™ in 2011 already. And as you already might suspect, the term has a negative connotation. But why is that? After all, prototypes are built so that the solution will eventually end up in production, aren’t they?

What’s the problem?

“A prototype is a simple experimental model of a proposed solution used to test or validate ideas, design assumptions, and other aspects of its conceptualization quickly and cheaply so that the designers involved can make appropriate refinements or possible changes in direction.” - interaction-design.org

So, while a prototype is a perfect tool to check if an idea works out, many technical and requirements for running in production are skipped during the prototyping phase. Typical examples are security-related, such as authentication and authorization concepts, role-based access controls, proper logging and monitoring. But also non-functional requirements like performance are often not a priority at first. This is not a weakness of the prototyping methodology. It is intended to speed up the initial development process.

Based on the aforementioned points, it seems obvious that there is some work to do to transform a prototype into a production ready application. The protoduction term has its negative connotation because it refers exactly to those apps, that did not (or not sufficiently) go through this transformation process and still have their prototype character while being in production already.

Why prototypes end up in production

You can find various reasons that can cause the problem: Exhausted budget, time schedule changes or doesn’t work out, scope changes, but also wrong expectations caused by insufficient communication and many more.

There are tons of standards, best practices, and methodologies to address each reason. It’s too much to be covered in a single blog post. But here are some low hanging fruits to make prototypes a success.

How to avoid it

The guidance below is neither a comprehensive list nor an officially validated set of best practices (you’ll find masses of these on the web). They are just my personal top three measures that have paid off in the past.

1. Fail fast

It sounds simple. But what does it mean and why is it so important? At KION (my employer) the time from initial idea to prototype is just seven days. As a rule of thumb, do not invest more than two weeks of effort. Off-topic: this is not only relevant for software development. I’d apply the same when evaluating new products in a pilot for example.

Limiting efforts has different advantages for the different stakeholders.

• Management: The higher the effort put into an experiment, the higher the expectations of its success. If the effort is not limited and weeks or even months are put into it, it becomes hard to stop and throw it away. The result is a solution that is far from being the perfect fit for the original problem. It is a product that is somehow promoted and put into production because it is needed as a success story so that the efforts made in the beginning were not a waste of time.

• Developers/Designers: Have you ever create something with great passion only to be told that it will be thrown away again? Feels bad, right? But it is part of the concept when working with prototypes and design thinking methodology. As a creator, I easily overrate my own work which is a pretty normal psychological effect. And this investment bias gets worse the more effort was invested.

Both effects reinforce each other. The more effort goes into the prototype, the more the management puts pressure on it to be a success. Meanwhile, the creators tend to like their prototype more and more, the longer they work on it. The chance that someone will pull the emergency brake is constantly decreasing.

If it turns out that a solution doesn’t work and it cannot be adjusted easily, then let it die. Move on to the next try.

2. When it comes to mockups, use pen and paper

Digital versions of pen and paper are also allowed. The important thing is to use sketches. Skip your fancy visual mockup tools and just draw (or at least use your mockup tools as late as possible in the process).

• Speed: It’s just fast.

• Focus: Does the following sound familiar?

  Looks good, but that button in the upper right seems to be a little too big. Does this color even meet our corporate identity?

  It happens, that discussions drift into details here and there which can cost a lot of time. Looking at just sketches, everyone keeps in mind that it’s about the big picture and details will be added later. It is easier to stay focused on really important topics.

• Expectations: As (ideally) there are many parties involved in the design process, there will be stakeholders without tech background: customers, business departments, management. When you introduce a realistic visual mockup or even a working HTML click dummy in an early stage, it fosters the expectation that the product is almost finished. This can lead to tough discussions with those stakeholders, as it can be hard to argue why so much additional effort is needed to transform a prototype into a product. When everybody is looking at just sketches instead, these wrong expectations won’t even come up.

3. Make fails a success

My last point is somehow referring to 1. again. If your work is trashed, if a prototype “fails”, it is easy to have a bad feeling about it. It can be a discouraging experience. And this is dangerous! People have to take risks when they develop new ideas. And when you are blamed for failure, the way of thinking changes. The willingness to take risks decreases, which ultimately kills ideas and creativity.

Embrace fail! You don’t have to organize a party and celebrate the whole night, but you have to reduce the negative experience as much as possible and take fails as what they are: A valuable source of information. When a prototype fails, you can gain tremendous knowledge about what to avoid in future iterations. Of course, this way of thinking needs to be present in the whole team - doesn’t help a lot if it’s your own way of thinking, but you are still blamed after all if your stuff fails. So as always, communication is key. And again, this point is much easier to apply if 1. (Fail fast) is also implemented.

Hope this makes sense. If you have similar or opposite experience, and points to add, please drop a message!