The false promises of prototyping

Know your tools, so you can build the right thing, in the right way.

With all the buzz around digital transformation, and more and more consultancies jumping on the bandwagon of throwing tech buzzwords around to convince their clients to spend huge sums on some new digital initiative, there seem to be more silver bullets than ever before to tackle the challenges of digitization.

One of these silver bullets that’s overly hyped is the prototyping and the promises behind it. The promises associated with prototyping cover a broad range: deliver fast results (who doesn’t want to be fast?), have something tangible to convince your internal stakeholders (who doesn’t want to have sth fancy to climb up on the career ladder?), to visualize an idea (who doesn’t want to have something fancy to put on that next slidedeck?), a clickdummy to play around and define your future product (clickdummies are easy to explain and sell, so why not?), or a showcase to have a nice new addition to your corporate museum (called innovation lab). So it starts to happen that the prototype becomes a product in its own, and more often than not, this mentality then leads to prototypes that are expensive, time consuming and no longer serve an important purpose: maximise your learning.

When dealing with complex problems in the age of digital, you have to deal with uncertainty. The world changes faster than ever before, and technology is becoming a commodity which allows more and more founders to start a new business on the budget of their credit card limits. In order to deal with the uncertainty and the associated risk, it is paramount to have early market feedback. This is well explained in a lot of places, e.g. the build-measure-learn cycle by Steve Blank. Only with this early market feedback, you can change direction by measuring and deriving learnings from it.

With this in mind, the prototype becomes one tool in your toolbelt to reach the goal of maximising your learning. Therefore it is important to start with a clear set of hypotheses and an idea about your business model. Identify the riskiest parts of it, and the parts where you see the highest uncertainty. Only if you test the riskiest assumptions, you can maximise your learning. By doing that you risk, that the customer feedback is negative. So it is not about creating a prototype to please your users or stakeholders, it is not about building something to visualise your idea, it is about running an experiment.

In order to run an experiment, you should have your question and hypothesis prepared. You use the prototype to measure and test the market. For that you have to get out of the building and talk to real users and customers. Some people recommend specific amounts of people you shall talk to, others even prepare questionnaires which are then religiously followed in customer interviews, and even worse: by asking them if they like what they see. By doing this you run the risk of just getting confirmation of your pre-conceived opinion, and won’t get the learning. Asking good (open) questions is well described by Rob Fitzpatrick in ‘The Mom Test’. For each iteration, for each hypothesis, you should decide individually how many people to interview, and when to dig deeper, and ask more people. For example you might decide to ask 10 people from your target user group, and decide that if at least 5 face the problem you are trying to solve, to then dig deeper and ask more users. This process cannot be planned upfront, and has to be decided upon in each iteration.

Ideally you engage with these potential early adopters and early users on a personal level and continue the dialogue and experiments as these might actually become the first paying customers for your service or product. Also it allows you to learn a lot about how users interact with your product, and prevents you from making a pre-mature investment into an unnecessary self-service onboarding process.

Recommendations when prototyping

• know your business model, or at least, have a set of assumptions of how it might look like. Do not start with just an idea.
• identify the riskiest part of your business model
• have a clear goal in mind, know your hypothesis, and decide how you are going to measure the results
• go from lo-fi to hi-fi prototypes, try to test fast and early
• get out of the building and test it yourself, ask open questions, learn about the problem the customer is facing
• keep track of the results, and your learnings, try to challenge your assumptions and be ready to discard your initial assumptions and ideas