The Oxford online dictionary defines a prototype as:
A first or preliminary version of a device or vehicle from which other forms are developed.
I have created a special version of this definition for product managers:
An early version of a product experience built to generate learning that informs later versions of the product.
Setting a goal for your prototyping project
The best approach to a prototyping project is to set a goal in advance.
In order to set a prototyping goal, you should consider:
Desired Outcome : understand your reason for prototyping
Company Context: consider the wider context of what your company values
Target Audience: who you need to to learn from
Scope: what you want to learn
Before embarking on a prototyping project, a good question to ask is, "Why prototype?" Why do we not just build a full product as soon as we can?
Building a prototype could help you to:
Evaluate whether a value proposition or product resonates with target customers and if they understand and like it.
Decide where to put UI elements (wireframing).
Frame discussions and communication with the team building the product (developers, testers, etc.)
I particularly recommend a prototype if you are starting a product from scratch. If you make substantial changes after building a full product, then this will cost significant time and money. But if you build a prototype and learn that customers do not like or do not understand something, you might be able to build another prototype in a few days and see if that version works better.
In this way, you can go through several cycles or versions of your prototype until you discover exactly what works in days rather than years. Then your team will build the product with a higher degree of certainty. In this case, your "why prototype" answer is "to see if it is worthwhile to spend more time on this project."
Companies tend to either want to avoid risk or to move fast. For example, a mature company making large profits will generally want to avoid taking huge risks (i.e., upsetting customers, losing revenue, being sued, negative publicity, etc). Companies that are not yet making significant revenue tend to want to move fast and capture a market before their competitors do or to prove a concept before their available finances run dry.
Consider whether your company needs to:
Avoid risk. The main priority is to avoid risk: examples include medical devices, anything involving health or safety, high volume products, or products with mission-critical functionalities.
Move fast. The main priority is to outrun a competitor or find a successful business model and achieve break-even (where revenues = costs) before finances are depleted.
Who are you going to learn from? There are many times where you will want to get feedback on a prototype from potential customers, and then the challenge becomes figuring out who exactly is a target customer and how you can reach such customers.
It is possible, however, that the audience could be:
Developers: Even if you have reasonable certainty of how to solve a problem with your product, then significant architecture and development decisions need to be made. You may want to ensure that everyone in the team has a similar understanding of the problem and solution. Building a prototype for the team means that you can "show, not tell," and you will elicit excellent feedback in this way.
Clients: With existing customers, you may want to explain some potential future features to check if the value resonates and/or if they need to and are willing to change their behavior in order to use a new product. If there are changes to the client's workflow, you will want to understand if such changes seem reasonable (or traumatic!) to the client.
Designers: Whether the product manager and designer need to communicate together or the designer needs to communicate with other designers on the team, building a prototype is a great way to see how the product "flows" and whether the integration of a new features causes any negative impact on the flow or navigation of the existing product.
One principle of prototyping (which we will see in the next chapter) is that you should only prototype that which you want to get feedback on. Another way of thinking about this is to try to build "just enough" prototype to get the feedback that you want.
The problem with building a really significant prototype is that when the audience sees it, then they will give you feedback on everything that they see. If you want to achieve consensus with a group of people on how to move forward, then the best approach is to try to get consensus on a narrow set of changes first. If you want to get feedback on a new way of uploading images, then don't show a prototype that has a new way of logging in!
Having fewer screens in the prototype will focus what the audience comments on and will allow you to generate consensus within your team more quickly.
Prototype Goal Format
A prototype goal should incorporate the four elements mentioned above and should take the format:
As our company is ____CONTEXT____, we want to get feedback/learning about ____SCOPE____ from ____AUDIENCE____ because ____REASON____.
One example could be:
As our company is moving fast, we want to get feedback about booking babysitters through an app from parents that need a babysitter at the last minute because we want to validate if a real-time babysitter booking app is a project worth further research and investment.
