Last week I talked about ideating, which is the third phase in the product discovery process and is used to rapidly identify several solutions that would allow you to test your hypotheses.
Once you’ve landed on your one idea that you think will test your hypotheses, you’re ready to prototype and test.
The big question you must ask yourself before prototyping
Based on your hypothesis, what is the simplest, quickest prototype you can create to validate your idea?
It could be as simple as a sketch on a piece of paper. It might be a black and white digital image you can show customers on their phone. It could be a low-fidelity prototype using a tool such as Balsamiq or Proto.io.

A wireframe is one of the most basic artifacts you can create for testing your idea. It can be done by hand or with an app on your computer. Wireframes lack visual design elements and typically only contain the most basic elements needed in order for a user to interact with it. And when I say interact, I just mean figuratively. Wireframes are not clickable.
I love Balsamiq for its ease of use and library of standard OS assets. Balsamiq is a rapid, low-fidelity wireframing tool that reproduces the experience of sketching on a notepad or whiteboard but using a computer.
Regardless of how you create your prototype, it should be something you can literally throw out when you’re done testing it. In other words, it should not be something written in code that could be tweaked over time. This prevents teams from becoming too attached to their ideas. A big mistake teams make is continuing to invest in something once it’s created even if it didn’t test well (or, even worse, wasn’t tested at all)!
Remember our example in the previous articles based on Domino’s Pizza? In that example, our imaginary product manager formulated an assumption that customers are not completing orders via the mobile app because they want to know if there are any specials and they think the best way to find out about specials is by talking to a Domino’s employee.
Based on this assumption, you may develop a hypothesis such as “If a user launches the app and the first screen she sees is a list of today’s specials, she will be more likely to complete her order using the mobile app.”
From there, you could create a and load it on an iPhone or build a prototype, such as the one here, that you could quickly show to several customers to validate the solution.
You or someone on your team should be able to create a prototype in less than a day. If they’re taking longer than that, they are likely getting bogged down in the details that can be figured out later.
Validating the prototype
Validating your prototype is also something you should be able to do in a day. Find a few target users and show them your prototype. Better yet, have them hold it and attempt to use it. Collect feedback on your prototype, from usability issues to whether or not the prototype helps them do their job easier. Find out what’s working and what’s not working and then go back to the drawing board to refine your hypothesis until you’ve reached the desired outcome. You can do this by tweaking the original prototype or you can take one of the other solutions from your ideation phase and mock that up for testing.
As part of the product discovery process, you should be working towards the smallest, shippable “thing” that achieves the desired outcome.
Once you’ve successfully validated your solution, create a small backlog, not of features, but of the other hypotheses you’d like to explore that you uncovered during the earlier phases of the product discovery process.
Developing an experimental mindset that focuses on delivering outcomes and not features is the key to having the most impact on making your customers happy (as well as growing your company’s business). Tweet
Do you have a favorite tool for prototyping? If so, join the conversation below!
Have you tried using the discovery process before? Have questions about how to do this? Get in touch. I’d love to hear from you!