Prototype to Product
by Alan Cohen
Copyright FILL IN YEAR Alan Cohen. All rights reserved.
Printed in the United States of America.
Published by OReilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.
OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles ( http://safaribooksonline.com ). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .
- Editors: Mike Loukides and Meghan Blanchette
- Production Editor: Melanie Yarbrough
- Copyeditor: FILL IN COPYEDITOR
- Proofreader: FILL IN PROOFREADER
- Indexer: FILL IN INDEXER
- Interior Designer: David Futato
- Cover Designer: Karen Montgomery
- Illustrator: Rebecca Demarest
- January 2015: First Edition
Revision History for the First Edition
- YYYY-MM-DD: First Release
See http://oreilly.com/catalog/errata.csp?isbn=9781449362294 for release details.
While the publisher and the author(s) have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author(s) disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
978-1-449-36229-4
[FILL IN]
Preface
Product development is the magic that turns circuitry, software and materials into a product. The word magic here is not used by accident even for most folks who design and develop technology as a hobby or even professionally, developing new products is unknown territory, or magic as far as they are concerned.
This books goal is to help the reader to gain a better understanding of the stuff that happens along the way when great ideas metamorphose into great products, and to supply strategies and tactics to make that stuff go smoother.
Creating an electronic product is complex, much more than developing some circuits and software, plopping em into a case, and hanging out a for sale sign. Numerous activities must be performed to turn components and cool prototypes into a desirable, usable, reliable, manufacturable, and salable product.
In part because of the complexity, new product development is a risky undertaking. According to Harvard Business School Professor Clay Christensen, 95% of new products fail. A number of factors play into this high rate, but Ive experienced firsthand that many or most new product failures stem from failures in the product development process.
For example, notoriously, most product development efforts end up being late and over budget - often by substantial amounts, 25% or more -- even a 100% overrun is not unusual. Sometimes overruns are caused by simply not estimating effort correctly. They often also come from surprise re-development efforts needed because product needs were not well known early in development. In my experience, these overuns and surprise re-development efforts stem from flaws in the productization process, not from the fundamental technology involved.
Budget and timeline surprises in the product development process are usually quite avoidable. They normally come from a lack of knowledge about the process, particularly the failures to realistically plan for productization stuff early in the process, and the lack of complete and clear requirements.
But proper product development is about more than avoiding overruns: it can also play a key role in refining a great concept into a desireable product. For example, when the Palm Pilot was released in 1996, most folks in the technology biz knew that the concept of a computer-in-your-pocket was a dog. A slew of pocketable computers had come and gone, including Apples Newton, and all had bombed. Couldnt be done.
The Palm Pilot proved the technology biz wrong: it was a raging success. Much of this success came from smart product development process where the right kinds of testing were done at the right stage of the process, to ensure that the technology Palm developed solved real problems and fit into real lives - well review Palms process later in a later chapter. While Palm failed to stay ahead of its competition, its paradigm for pocket computing lives on in todays smart phones, which look much more like a Palm Pilot than, say, an Apple Newton.
Many books do a great job of covering parts of product development, such as electronic design, software development, industrial design, mechanical engineering, and so forth. There are a handful of books that cover product development at a business level, reviewing topics ranging from market research to financial forecasting to team dynamics. But very little has been written that covers, holistically, the nuts and bolts of efficiently moving from good ideas to manufactured product, and thats what I hope to do within this book.
Why I wrote this book
While my formal education and background is in electronics and software, my role in projects is generally as a systems engineer. Systems engineering is a field that considers how the different parts of complex systems work together to accomplish their purpose. Were commonly the technology people who lead the effort to produce a product, rather than circuits and software in an enclosure. In a sense, we could be called holistic engineers, because were responsible for the whole system working together as a product.
On a day-to-day basis, my job consists of bringing together groups of people with varying backgrounds and helping us all to move towards a common goal. I typically work with engineers from various disciplines (electronics, software, mechanical,...), industrial designers, management, marketing, sales, regulatory, finance, manufacturing, and others. Successful product development requires all of these folks to work together effectively for months or years, and systems engineers tend to act as the lubricant to keep things running smoothly.
There are two tasks that tend to catalyze these disparate groups of people into a cohesive team:
- Helping team members to understand a bit about what other members do in their jobs. This helps members to work together more efficiently because they have a deeper understanding of each others needs. It also builds respect: everyone elses job seems easy compared to ours, until we understand some of the many details of what they do.
- Helping to ensure that the cracks are filled between the knowledge and skills that that various technology folks bring to the party. Technologists tend to know their own field, but are much less likely to know how to work with others on distributed problems. For example, suppose that were looking at how to prevent an LCD display from overheating in a product with a small, watertight enclosure. Electronics, mechanical, software, industrial design, and perhaps supply chain will likely all need to work together to find the optimal solution out of the many possible ones.
Ultimately, both of these top-level tasks are about education, and much of what I do in my role is to educate others. And over time, I find that there are a number of topics that I get to teach about pretty regularly, to technologists and non-technologists alike.
The