Customer Development is a Sequence of Prototypes

Key take-aways from “Eight Rules for Prototyping” by John Hanks and Todd Dobberstein. A prototype is used both to assess technical feasibility and to provide a demonstration to a customer to get feedback. Customer development is a sequence of prototypes.

Customer Development is a Sequence of Prototypes

John Hanks and Todd Dobberstein of National Instruments have written an outstanding article “Eight Rules for Prototyping” (hat tip to Andrew Hargadon’s “Prototypes ‘R’ Us” ) that apply to hardware, software, and systems companies. Here are my top four from the list, but the entire article is worth reading.

There is a path to success. If you can demonstrate or, better yet, put a prototype into the customer’s hands and get real feedback on the value of your innovation, the probability of business success greatly increases. If you want to be an entrepreneur and move your idea out of your head, develop a prototype…

Show don’t tell. Give a prospect something that can be marked up, or better you can take turns marking up or modifying.

1. Recognize That Ideas Are Cheap. […] The expense lies in testing and verifying what has economic value. A great prototype is often the best way to start a dialogue with potential customers and test your idea’s value.

Perspective is valuable. Yours…and more importantly the customer’s.

2. Start with a Paper Design. […] For a user interface or Web software prototype, a paper design is efficient and effective for quickly working through the functionality. You can get peers and, hopefully, customers to give feedback on where images, text, buttons, graphs, menus, or pull-down selections are located. Paper designs are inexpensive and more valuable than words.

These days Microsoft Office and HTML count as paper. But the best first prototype is a single sheet of paper that helps shape a conversation over a cup of coffee. But John Gall‘s observation from 30 years ago in Systemantics are still true: “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

3. Put in Just Enough Work. […] There are two good reasons to prototype: the first is to test the feasibility of a hardware or software architecture, and the second is to create a demonstration and gain customer feedback so you can price and put a value on your innovation. Keep these objectives in mind and be careful not to fall in love with the process…

Prototypes can help you assess both technical feasibility and market risk (if you will let them leave the Bat Cave so that prospects can play with them).

6. Avoid Focusing on Cost Too Early. Initially, focus on proving the value of your innovation, and design with modularity in mind. While frustrating, your design may follow many paths that do not ultimately lead to value. Focus on securing your first set of customers and then work on cost optimization.

There are a variety of “premature optimizations” that should be postponed until you have real customer feedback. It’s a good article, my only fault would be that it will normally take a sequence of prototypes to bring a product to market and the article seems to imply that one is enough. It can be but you are better to “go ugly early” and get feedback than waiting to develop the one demo that will wow them into submission.

Summary of 8 Rules For Prototypes

1. Recognize That Ideas Are Cheap.
2. Start with a Paper Design:
3. Put in Just Enough Work.
4. Anticipate for Multiple Options: Design your prototype with modularity in mind.
5. Design for Reuse in the Final Product.
6. Avoid Focusing on Cost Too Early.
7. Fight “Reversion to the Mean” Stay true to your vision and make sure your prototype captures the original thought of your innovation.
8. Ensure You Can Demonstrate Your Prototype.

Related Blog Posts

• We Already Have a Prototype, Can We Still Do Customer Development?
• Pretotyping: Techniques for Building the Right Product
• Checklist for Successful Products
• Seven From Skip Walter’s Laws Of Software Development
• Balancing Engineering Vision vs. Customer Expectation