Throw your prototype in the bin07 September 2013
Posted by : Gareth Shapiro
Going from prototype to market is a pain.
This article is aimed at product owners, project managers, budgets holders and business executives. Technical people are probably going to nod and repeat "Yes, I know" as they read it.
Whenever the intended audience want to create a large amount of emotional turmoil in the hearts and minds of technical folk they ask questions such like :
"Why is it that a prototype can be produced quickly and the first release to market takes exponentially more time?"
"Surely a good portion of the work was achieved creating the prototype?"
These sorts of questions are asked all the time and this thinking is quite often the seeds of later unhappiness. A clear majority of the time the prototype is used to create the first version, whether it is a minimum viable product (MVP) or not. Money and emotional investment has been spent creating a prototype and apparently an efficiency can be realised by using it as the start point for the next phase.
I propose the chances of easier early, and also sustained, success can be promoted instead by engaging with the exact opposite idea. Once the decision has been made to move forward throw the prototype away and create the first production version from scratch.
First some definitions. What is the difference between a prototype and a MVP?
I am going to use an often employed metaphor that people use when talking about software which is a bricks and mortar building project.
Quite often it's obvious that non technical people consider the prototype to be the show flat. Once the prototype has been completed a small amount of superficial detail is all that stands between it and the market place.
It's more accurate to think of the prototype of a mobile app as an architect's model and the MVP is the show flat.
The reason for building a prototype is to start discussion. It's much easier to get people engaged with an idea if there is some way they can see it or even better interact with it. You can't live in an architect's model but you can pick it up in your hands and look at it. Your imagination can transport you in to what the corresponding space might be like in an actual building and more importantly you can do this with other people in real time. All from clever use of cardboard and glue.
Often you can describe a digital prototype as Powerpoint-ware. As long as you step through a series of interactions in a linear fashion, in the same way that you look at presentation slides, everything is fine. The effort expended creating the prototype is just enough to get this narrow set of features working, or just enough to look like they are working, start a conversation and no more. In order to create this illusion often many short cuts are employed.
What type of short cuts?
In software only a small fraction of development effort is spent making things work. Up to 70% of development effort is spent preventing software from doing what it shouldn't. Things that are easy to use, that "just work", take much more effort to design and create than products without a clear refined purpose. It doesn't matter if your prototype crashes, is inaccurate or (within reason) is unpredictable. You only require a small subset of features to have the discussions that are useful before scope begins to reveal itself. If prototypes contain more detail than those that enable discussion, time and resources have been wasted.
A very common approach to creating production software is to separate three essential concerns.
- User Interface
A short cut made by a prototypes developer may be to ignore this separation. This type of abstraction takes time and brain cycles to achieve. Performance and flexibility are always at odds with each other in software, even within very well designed sophisticated solutions. In prototypes they should not even be on the table. Dump all the aspects in one place and wire it up. Quickly. By Friday's meeting.
Even the language used when talking about prototypes betrays their nature; "rapid prototype", "quick / cheap / nasty prototype".
iOS, the technology native to Apple's iPhone, iPad and iPod devices has a culture about it that demands the discipline of experience. Objective-C the language used in iOS has been about for a long time, much longer than the iPhone, and like any programming language provides a few ways of skinning a cat. The quick, cheap and nasty way may work superficially but will not perform correctly when all but the most simple demands are asked of it.
The reason for building a prototype is not to test a market but to start a conversation and to learn early lessons.
The only way to really learn them is to throw the prototype away and create a brand new project. Perhaps some code may be copied and pasted from the prototype but it's not really important how much makes it across. The lessons are much more valuable than the lines of code.
It's frightening how seldom this happens. I am currently working on a product that is stubbornly remaining shy of the market place. A perfectly reasonable request to improve some of the usability and visual appeal meant an amount of unpicking was required. I pulled a thread and two thirds of the product fell apart. Ultimately I discovered the Logic was woven into both the View and the Data and it was impossible to change the user interface without effecting the integrity of the Data. All of this as a result of a request for a visual change! It is very difficult to explain to non technical stake holders why a superficial change meant the data is effected, it just doesn't make sense.
When prototype code is used this scenario all too common. Unused code that remained in place literally showed me the lessons the developer learnt as they went about creating the first version.
Throw the prototype away. Cardboard and glue is not the correct material to use as the foundation of your building. Often all digital 'material' is considered to have the same attributes. This is an incorrect stance, all digital 'material' is brought to life with electricity but often that's where the similarity with other digital 'material' ends.
Separate the early learning from the product that finds its way to the market. It doesn't matter how experienced developers / product designers are, there are always things that crop up only once you write code. Mobile development especially is a cutting edge market. Things are moving at pace and there is a shortage of genuine experience. People are often learning in situ. It is wise to isolate this learning as soon as possible and the point after the prototype and before version one is the perfect, and cheapest, place to do it.
Consider two positive post launch scenarios that benefit from a better foundation than a prototype.
Best case scenario. You get product to market and it is successful. Very quickly there is pressure to improve and / or extend the product. Stake holders are happy and excited and ideas are being generated by the team. Copy cats quickly appear and users are making suggestions in their online public feedback.
The better your foundations, the easier it is to react. This is where time and cost savings can really make the difference. In staying competitive. Banking savings earlier is doing so before you have really started competing. You've played that card too soon.
A less favourable scenario is one where the market responds favourably to your product but demands change. If the prototype was used to create the first version the legacy of the prototype remains in the code base in addition to some pieces of the first version. This technical debt will demand to be repaid sometime. Removing the prototype code from the equation means less debt when this sort of product pivot is made.
Either way, unless you fail outright it is very likely your team will need to grow. More chefs are not needed and a junior technical person arrives. There is always a dip productivity while new staff are trained. This is expensive. The new person is not productive and is costing money. More senior staff cost more and will also experience a dip in form for a while. Sure they could be pushed harder to make the difference up for the time it takes to get the team up to speed but this isn't working clever. A wiser choice is to get technology, not people, to do the heavy lifting.
Further more if you are not fighting fires you can cover new ground. Time can be spent documenting process and defining a cohesive project structure. These are the characteristics of mature, long term projects and if you want your product to be one the sooner the technical staff have forgotten about the early mistakes / learning (delete as applicable) the better.
Once you are happy with your prototype sit it down, thank it for its time, and throw it in the bin.