ORGANIZE: from Prototype to Knowledge


The TUNING Toolkit has three sections: BELIEVE, CREATE, and ORGANIZE. In the BELIEVE section, we set goals. In the CREATE section, we collaborated and brainstormed. ORGANIZE is the third and last section of the toolkit. In this section, we will think strategically about what to create and how to launch what you create into the world.


When developing a new product, your team will likely find it difficult to transition from brainstorming and research to prototyping and testing. I’m not sure why this is but it might be a manifestation of fear. While talking about an idea is fun and easy, when we go to build it we are confronted with potential failure. As a mentor I’ve seen it time and again: teams hit a roadblock here. All I can say is know the roadblock is coming and push through it. (You can jump back to the post about “Reclaiming Your Energy” to find tips on managing fear).

The kind of research you did at the beginning, which involved mostly throwing around ideas, will get you only so far. At some point, you’ll need to build a prototype and put it in the hands of the people you are trying to help with it.


The initial prototypes you build provide you a cheap and easy way to decipher which of your  ideas work and which don’t. As you figure this out, your prototype will get more refined and more expensive. But to begin, it’s best to keep your prototypes cheap and pliable.

If you are making an app, you can start with paper. If you are making a physical product, you can start with modeling clay and wire. The point here is to start with materials that are quick and cheap, to allow you to explore and test a lot of options. When you test options, you will gather data. Your ultimate goal is to turn that data into knowledge that will, in turn, inform each round of prototypes, so that over time they get better and more focused.


Once you make your first prototype, then you can test it with other people. While early prototypes might be in the hands of testers for an hour or two, later on your more refined prototypes may be in the hands of testers for weeks at a time.

But what are you testing for? You’re testing to find out if your customer is receiving the benefits you set out to deliver.

That all sounds abstract, so let’s walk through an example.

Say I’m designing a new food processor and I’ve decided on a FEATURE I want to build, say, “lightweight.” To turn the DATA I get from testing a lightweight prototype into KNOWLEDGE that informs my next prototype, I need to go into the test with the following points articulated:

  1. FEATURE: Lightweight
  2. BENEFIT: Product is easy to move, perhaps less expensive
  3. ASSUMPTION: “Easy to move” is a benefit my ideal customer cares about more than other benefits
  4. TRADEOFF: To make it lightweight, the design will require a smaller, less powerful motor 

When I take off my inventor hat and put on my customer hat, I can tell you that I buy a food processor to process food and I want the motor to be powerful enough to do the job. The tradeoff I make as a customer for a heavy machine is counter space–I sacrifice counter space for a powerful motor. I leave the processor out on the counter so that I don’t have to deal with its weight when I want to use it. My lightweight hypothetical prototype, on the other hand, is trading power for maneuverability.

Putting my inventor hat back on, I’ll ask, how do I find the right features for my customer? This process requires a good dose of humility and a lot of testing. Test your prototypes with customers and the truth will emerge. If you watch your customers use your product, you will see the rough spots where the features you’ve designed don’t support the experience you hope to create. And then you can adjust your design accordingly.