Blog

We talk a lot about the benefits of prototyping, but we like it even more when thought-leaders in the interactive industry talk about it. This post was written by Marty Cagan of Silicon Valley Product Groupwhere he is a the Founding Partner. Cagan has over 20 years experience in executive-level roles responsible for defining and building products.

After 10 years as a software developer at HP, Cagan joined a then young Netscape Communications Corporation, where he had the opportunity to participate in the birth of the Internet industry. Cagan worked directly for co-founder Marc Andreessen, where he was vice-president for Netscape’s platform and tools, and later e-commerce applications. Prior to SVPG, Cagan was senior vice-president of product management and design for eBay, where he was responsible for defining products and services for the company’s global e-commerce trading site.

During his career, Cagan has personally performed and managed most of the roles of a modern software product organization, including product management, software development, product marketing, user interface design, usability engineering, technical writing, software testing, engineering management, and general management.

In several earlier articles I have talked about aspects of prototypes. I’ve talked about using them as the basis for your product spec, and how to use them to test out your ideas on target users, and why I prefer high-fidelity prototypes to their lower-fidelity cousins. In this article I’d like to highlight the top 10 major benefits of prototyping, and talk about some of the mechanics of building and using prototypes.

Benefits:

1. First and foremost, a high-fidelity prototype gives you something realistic enough to try out your ideas with target users and customers before making a significant investment. This lets you discover which ideas are good and which are not, and if the product has real value, and also discover if users can figure out how to use the product.
2. Doing a high-fidelity prototype helps you – even forces you – to think through your product to a much greater degree than paper specs.
3. A high-fidelity prototype enables and encourages the type of collaboration between product manager, interaction designer, and architect/engineer that is necessary to discover a valuable, useful and feasible product.
4. A high-fidelity prototype provides the level of information necessary for accurate engineering cost estimates, early in the process when these estimates are most useful.
5. A high-fidelity prototype provides the engineers and QA organization with a rich, interactive description of the product’s intended functionality and design to be used as a reference basis for implementation and test.
6. A high-fidelity prototype provides the rest of the organization – marketing, sales, customer service, business development, company execs – with a useful understanding of the product to come early enough in the process that they have time to do their jobs properly.
7. A high-fidelity prototype prevents the classic waterfall problem of doing design after the requirements, rather than realizing that functionality and user experience are inherently intertwined.
8. If you do a high-fidelity prototype and you test your ideas with users and you find significant problems, you will have saved your company the cost in terms of time and money of building something that would have failed. Not to mention the opportunity cost of what the team could have been building.
9. If you do a high-fidelity prototype and validate this with target users, you will significantly reduce the time it takes for your developers to build the product both because the product is better defined, and also because you will have been forced to resolve many of the questions early that otherwise throw a wrench into development.
10. A high-fidelity prototype helps keep the focus of the team on the user experience.

Notes:

• Prototyping tools have improved dramatically over the past several years. Whether you’re building a web-based application or installed client software, there are several excellent tools. The key is that you use something that lets you very quickly and easily create a realistic user experience.
• Because the prototype is just representing the user experience, and not the often much more difficult to write software running on the back-end, and because the prototype is not meant to be production quality software (reliable, maintainable, scalable, fault-tolerant), you can usually use a much less skilled resource to create the prototype. The key is that the prototyper must be very comfortable throwing away the work of the past few hours to try a new approach.
• Once the team moves from product discovery into implementation, the prototype should be version controlled and placed under change control. Any user visible changes to the product definition need to be approved by the product manager and engineering, and reflected in the prototype. The prototype serves as the key reference and master. It is the one artifact that the product manager, designers, engineers and QA use to reflect decisions made.
• It is perfectly fine for the prototype to use simulated data. The data should be realistic and plausible but does not have to be accurate. Generally, the prototype doesn’t access any other database or remote service.

For product teams using Agile methods such as Scrum:

Some Agile practitioners argue that the team should just consider the early sprints as the working prototype. And in fact, for custom software efforts where there really isn’t true product management and rarely user experience design, this is the essentially the best you can do. However, for product software organizations, you can and must do better than this, for three reasons:

First, a sprint is typically far too long to wait to try out an idea—an idea which will most likely be wrong. It is much faster to try that idea out with a disposable prototype in days rather than wait months for one or more sprint cycles.

Second, there are typically too many critical things for the engineering team to do to use them for the product discovery process. By taking their time for this prototyping work they are not able to do what they should be doing—building production software.

Third, while Agile methods do much to encourage the team to learn and respond quickly, it is still difficult and time consuming for a team to change directions significantly once they have begun down a path, and put long hours into a particular architecture or approach.

If you haven’t yet tried creating a high-fidelity prototype as the vehicle for discovering a product that is valuable, usable and feasible, I hope you’ll give it a try. It has never been easier to do so, and I find it one of the most powerful techniques for coming up with winning products.