You don’t (always) need a prototype
I was recently asked a question by one of my colleagues — “is there ever a time when we shouldn’t prototype something first?” The answer is of course ‘yes’ but I know what he was getting at.
When something’s hard you cling on to what works
Integrating design into an agile delivery team can be challenging. Working more inclusively within compressed timescales requires both patience and persistence from everyone involved.
Fortunately, over the last few years there’s been a lot more discussion around this topic. Lean UX and Google’s Design Sprint’s have helped popularise a set of tools and techniques that help cross-functional, agile teams synchronise better and learn faster.
Many of these new ideas and approaches extol the benefits of centering the product development process around low-investment prototyping. An influx of new tools that make creating prototypes even easier and more sophisticated have supported and profited from this line of thinking.
Because of these challenges teams have been quick to adopt behaviours and techniques that are generally regarded as best practice without necessarily questioning whether they are appropriate to their situation.
Choose the right approach
Prototypes are a cost effective way of testing if a solution is viable or not. So if you don’t know your market or users very well, your path to live is inefficient or the impact of getting a new product or feature wrong is high then creating and testing a prototype first might be the right thing to do.
However, if any of these factors aren’t true, which is often the case for more established products and services, then building and launching working code can be almost as efficient.
You may also be in a position where, despite your lack of knowledge about your end-users, there might be insuperable advantage to be gained over your competitors by being the first to market in a new product category.
But most importantly, no matter how sophisticated your prototype is, or how natural you’ve tried to make your testing environment, gathering data from unobserved users of a live product or service will always produce more reliable insights.
Challenge the process
When you’re working in a new or challenging environment it’s easy to take the validity of an approach for granted and so it’s important that we constantly challenge not only each other but the processes and techniques we collectively adopt.
To ensure your teams don’t fall into this trap of prototyping by default, get them to ask themselves these questions before your next product development cycle.
- How much effort would it be to just build it?
- What’s the impact of getting it wrong?
- How well do we know our users or target market?
- Is there a competitive advantage to launching first?
