Prototyping is a key activity of the Validate Phase. Have a look at how we think about prototyping in general in this article and dig deeper in our following articles about prototyping of physical products, software, IoT, processes and services.
Building prototypes is an essential activitiy in Business Design. In Business Design, we have a very wide definition of a what a prototype is following the basic ideas of Herbert Stachowiak ("General Model Theory"). For us, a prototype is a visual and reduced representation of an idea or concept built for a purpose. We build many different prototypes throughout the Business Design process to either
support our thinking on specific problems (e.g. technical feasibility) or
support social interactions between different stakeholders (e.g. project team and customers, see illustration).
"Thinking Tool": Prototypes are often built to stretch the boundaries of a project team's imagination in creativity processes or to get answers concerning critical questions. In many cases, prototypes as learning tools can help clarify questions of the technical feasibility or "performance" of ideas. This is the traditional way of looking at prototypes.
"Interaction Tool: Prototypes may also help to communicate new ideas by aligning different perspectives (= mental models). As human beings usually think in visual models, a prototype as a visual representation of a new idea facilitates the translation process that usually happens when people are talking about new ideas that do not exist yet. We have coined the term "social prototyping" to emphasis the importance of prototypes in supporting social interaction processes. Be very clear about the purpose of a prototype before you build it!
We differentiate between a prototype and lean offerings / MVP. The first is usually build to learn something before we have the first product on the market. The latter, in contrast, is the first product on the market that allows the team to charge customers ("earn and learn"). We don't distinguish, though, between the terms "model" and "prototype" as many disciplines do. We haven't found a reason yet why we should do it.
5,5 weeks (see Validate Phase)
Keep in mind that more advanced prototypes require more than 5 weeks to build. Sometimes, a prototyping activities spans more than one iteration.
3. Key Activities
Before we start building a prototype we always go through the following steps:
Define the purpose: Ask yourself why you want to build a prototype. The answer to this question will define how you build prototype and what tools will help you build the prototype. If you have a questions regarding certain performance parameters of a new technology, you build a technical demonstrator that allows you to observe these parameters. If you need feedback from customers you may be better off wrapping your idea into a well designed sales brochure explaining the "magic moments" of your product in a simple language.
Set the attributes: Based on the purpose of the prototype, we define essential attributes of the prototypes, particularly the scope (see below), resolution, functionability, lifetime and flexibility. Depending on theses attributes, we pick a suitable prototyping tool to actually build the prototype. A physical form prototype, for instance, is often a visual representation of a product idea with a wide scope, low resolution, almost no functionability and medium flexibility, which means that you can't change the prototype that easy due to new requirements. A role play mapping a service process may have a different setting with a mode detailed resolution, functionability and flexibility.
Build the prototype: The purpose and attributes define the way we build the prototype with prototyping tools. We recommend to hire special prototyping engineers who are familiar with prototyping tools and the specific nature of Business Design processes. They are able to build prototypes in a couple of hours - not days - and know what functions our components have to be part of the prototype and what can be left out. It is magic!
4. Tools & Materials
Functional prototype (TRL 1-9*)
LEGO model (with metaphorical expression)
Template (e.g. Business Model)
P&L statement (not very visual but a representation of an idea)
*TRL = technology readiness level
Some examples may sound strange, but they are all in line with the definition above. They are just designed for different purposes in the Business Design process.
6. Attributes of Prototypes
Building the "right" prototype for a defined purpose is key in Business Design. There are not many frameworks out there that can guide us to define and describe prototypes. This is why we have put our heads together and fleshed out our own framework that offers a set of attributes describing a prototype as a visual representation of an idea (= original) in the context of Business Design:
...defines how many functions or components of an idea or concept is mapped into the prototype. We often describe the scope with "user stories".
...defines how detailed the functions or components are mapped into the prototype.
...defines whether the prototype will "work" the way it is intended.
...defines how quick and easy a prototype can be adapted to new insights and requirements.
...defines whether we use the original material to build the prototype - or not.
...defines how long the prototype should be usable for the given purpose.
By defining the purpose of a prototype and setting the attributes before you start building, this may help building the "right" prototype and not just something visual. This exercise also helps to pick a suitable prototyping tool for your product, software or service / process prototype. Try it out! It will save you time and money!
7. Instructions for Coaches
Always ask the "Why?" (= purpose) question first, before you start building something. Without a clear purpose prototyping is waste of time!
Keep in mind that prototyping can unleash many fears: A prototype is a brutally honest and transparent representation of developed ideas and uncovers ruthlessly strengths and weaknesses of the idea and the project team.
Building a prototype is often part of the preparation for first customer feedback. The same here: Be aware that feedback is not always appreciated by all stakeholders in the project. It may be considered as perilous, since some answers might uncover things that has been protected by them.
Teams tend to build too much. Make sure that the team builds only what they need to test their hypotheses. Not more!
Building a prototype is only half of the work. To learn the right things we need to measure. That's why we need to collect the right data with our prototype. Make sure, the team does that.
It's often the case that the team forgets that they are building a prototype. Make sure that they are aware that they don't build the final product. For most of the questions we need to get answered, we don't need too much details within the prototype.