We know how the fable goes – slow and sure wins the race.
How does this stack up in product development?
The traditional approach involves lots of research and insights upfront to provide direction for the solution to be delivered – typically followed by a waterfall delivery approach – well defined and structured with lots of checks and balances on the way. Most of us in larger organisations are familiar with this approach and trust that the rigor of the process will not only deliver a solid outcome but will also protect stakeholders through the process. This is the tortoise slow but sure.
As we’re familiar with it, we’re also aware that it’s a source of constant frustration for some of the most valuable employees i.e. the enthusiastic ones with ideas. From their perspective why should they spend all that time, money and effort to confirm something ‘they know’, based on their extensive experience and knowledge, is right. This fight between enthusiasm to deliver and the seemly exhaustive validation processes designed to ensure good money isn’t thrown after bad can stifle the most creative minds.
Time to market can also be a significant impediment – market research, formal requirements documentation followed by detailed functional specifications and user experience testing all before any design or development starts can push the go live date out so far that the product might not even be relevant for the market when its finally launched.
What if there was a way that we could test our assumptions quickly and easily to both appease the powers that be and give us some personal assurance that our idea is worth pursuing?
The model above, the tortoise, is very much research led – insights gained from research give us the foundations and justification for a solution to solve our business problem. 500 years of science gives us another approach. The scientific approach is to start with a hypothesis and then design experiments to try and disprove it. If you can’t disprove the hypothesis then we take it as “accepted theory”.
This hypothesis led process can also be used in product development – whereby the experiments we design to test our hypothesis take the form of product prototypes.
Typically when we think of digital prototypes we think of some kind of scripted interface mimicking the entire finished product that is built and tested on similar machines that the intended audience will use the actual product on. These kinds of prototypes can require a significant investment in time and resource to develop.
If we’re going to shortcut our ‘research’ time we need to work with faster and more agile methods of testing. In order to do this we need pare our product idea back to its most basic component parts and test and test up from there e.g. If we’re wanting to build an email win back strategy for a particularly long registration form then the basic premise to test is whether or not your users will click on the email to resume their registration. This could simply be a survey question. The next test could be to find out what email messaging is most likely to make them want to resume their registration. Another test could be to find out the best place to capture their email address with appropriate permissions to re-market to them if they don’t complete the form. We might then want to test how best to re-engage users at the point that they left the form in the first place once they’ve clicked back from the email. As you can see the scenarios above are all quite separate and can be tested in isolation using either survey questions or simple diagrams (e.g paper prototypes).
As the ‘research’ progresses and we require more granular detail eventually we’ll need to move to more formal and structured test environments that provide a higher level of interaction detail. By then though, chances are that we’ve already developed enough test data to confirm our hypothesis and final user testing can be conducted as part of the development cycle.
This process type of rapid, low fidelity prototyping is increasingly being embraced by organisations wanting to speed up product development. With an appropriate test plan and prototype techniques being the ‘hare’ doesn’t need to be as reckless as the old fable would have us believe. Nor does prototyping need to be a technical task preformed after functional specifications have been defined.
Low fidelity paper and click-through prototyping are fantastic tools for sense checking the validity of just about any product idea. With an appropriate test plan, almost anyone in your marketing department can build and test them.
When to be a tortoise and when to be a hare
All this isn’t to say that the traditional research led approach isn’t still a valid option. It does have some advantages, although taking longer and costing more it does tend to produce more consistent results. A lot of staff also feel more secure in a highly structured and specialised environment.
Run correctly the hypothesis led process should be significantly cheaper but does have a consequently higher fail rate.
In general if your project is mission critical with significant business risks if it fails then the Tortoise is a safer option. It’s also easier to manage if your staff have limited experience or are sourcing development remotely
If your project is speculative in nature or a ‘value add’ to an existing platform then the Hare will provide more value and speed to market for initial releases. The Hare is also a good approach to foster and entrepreneurial spirit within an organisation, as evidenced by the fact that most start-ups use this process
Both methods are viable options – Flexible and innovative businesses run both options as well as hybrids of each to match projects based on their individual merits. Hare’s are good at some things tortoises are better at others.