In our last post we talked about moving from ideas to prototypes by testing our assumptions and hypotheses. It’s important not to skip these steps because those assumptions provide the context for the prototype you will be building.

To be as valuable as possible, the prototype stage needs to meet a few key objectives. The first is to understand what customers find valuable and are willing to pay for.

The prototype should be a minimum viable product (MVP) so that it can be created quickly and inexpensively. This also makes it much easier to create a cause-and-effect relationship when users test out features or concepts. The goal is to understand what is causing the behaviour and why, which ultimately reduces the risk of new product development.

Other objectives include running design experiments to test concepts; exposing new customers to your product; and exposing your team to new technologies.

Let’s run through each of these objectives and find out how the prototype helps achieve these.

The goal is to understand what is causing the behaviour and why, which ultimately reduces the risk of new product development

Companies often see innovation as a risk. Leaders are often asked to predict the future about projects they are embarking on and pay a lot of money for reports and focus groups to help understand the business case for the new project. This thinking is all wrong. Don’t spend the money up front and guess; spend a little money on experiments to build the business case in real time.

In the last Nimble Hippo post, we talked about running experiments to prove hypotheses and test assumptions. The way to test those hypotheses is to build prototypes and measure the outcome of the tests. There are two really important parts to remember when building your prototype for an experiment:

  1. Don’t make the prototype do too much. Test one assumption or hypothesis each time to make it easier to interpret the results. This is your MVP.
  2. Design the prototype to measure the interactions.

Here’s an example. If you are designing a new mobile app to find the hottest new restaurants in town, it would be good to know how your prospective customer currently looks for restaurants.  Who is your target customer? How do they use their phone? How do you know for sure? You build the feature that tests the assumption.

Assumption: Your target customer will value positive reviews over location when choosing a restaurant.

Test: Build a prototype and have a number of customers try to find a new restaurant using the app. They should have a few different ways to find the restaurant. Three possibilities are GPS (location), style (Italian, French, etc.), and best reviews.

Protocol: The target customers get to use the app on their own and are asked to find the best restaurant for them. The app measures the clicks and an independent interviewer observes.  Once the user has finished, the interviewer asks a few open-ended questions to help identify why certain selections were made and provide an opportunity for these users to add suggestions for other features, etc.

The way to test those hypotheses is to build prototypes and measure the outcome of the tests

The development group uses this strategy over and over again, building a priority list of features that users have verified they would use and find valuable. This will either prove or disprove the assumptions the team was using when designing the app, providing real data to build the business case for new product development.

In this example, both objectives are met: The MVP prototype is targeted and completed quickly and inexpensively to create real data points, and potential customers are exposed to a product that may exist in the future, so they become early and important beta customers during the launch.

Remember this strategy during product development:

  • Lay out all the assumptions and hypotheses ahead of time to ensure you are testing them in a systematic way.
  • Build your prototypes using a minimum viable product strategy so the prototypes are done quickly and inexpensively.
  • Don’t test too many things at the same time. Keep tests targeted and focused, and objectively measure the results.
  • Apply those collective results to the business case as the product progresses and needs more resources to be completed.

These approaches will ultimately lower the risk of innovative product development and give your company a better chance of success.

Photo: Hippopotamus by Lukas is licensed under CC BY-NC 2.0.

The Nimble Hippo looks at how large organizations can build innovative cultures and disruptive strategies by taking the best lessons from startup ecosystems and applying them in a big-company context.

About The Author

Craig Haney
Director, Corporate Innovation, Communitech

Craig is leading the charge for corporate innovation in Canada. His work with Canadian Tire Innovations helped launch the LeanLab project at Communitech, helping large, non-tech companies become faster and more innovative by engaging with startups. As Director of Corporate Innovation at Communitech, his focus is to grow the ecosystem by exposing small companies to big problems they can solve for some of Canada’s largest players. Craig has an undergraduate degree from the University of Western Ontario and a Masters of Business, Entrepreneurship, and Technonogy (MBET) from the University of Waterloo.