Prototype to Product

Preface

Product development is the magic that turns circuitry, software, and materials into a product. The word magic here is not used by accident; for most folks who design and develop technology as a hobby or even professionally, creating new products is unknown territory—or magic—as far as they are concerned.

This book’s 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—in particular, intelligent products with embedded electronics and software—and to supply strategies and tactics to make that “stuff” go more smoothly.

Creating an intelligent product is complex. It’s 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 I’ve 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 of 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, which become necessary because product needs were not well known early in development. In my experience, these overruns and surprise re-development efforts often 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 failure to realistically plan for productization “stuff” early in the process, and a 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 desirable 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 Apple’s Newton, and all had bombed. Couldn’t be done.

The Palm Pilot proved the technology biz wrong: it was a raging success. Much of this success came from a 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 (we’ll touch on the Palm’s process a bit more in Chapter 5). While Palm failed to stay ahead of its competition, its paradigm for pocket computing lives on in today’s 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, usability, and mechanical engineering. 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 that’s what I hope to do with this book.

Why I Wrote This Book

Even though 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. We’re commonly the technology people who lead the effort to produce an actual product, rather than circuits and software in an enclosure. In a sense, we could be called holistic engineers, because we’re responsible for the whole system working together as a product.

At the purely technical level, we systems engineers lead the effort to plan, at a high level, how a desired set of properties (requirements) can be broken down into subsystems that efficiently get the job done, with an eye toward minimizing time, cost, and risk. Once these subsystems and their functionality are defined, we try to make sure that development continues to proceed in a way that enables all of the subsystems to work together in the final product.

On a day-to-day basis, my job normally consists of bringing together groups of people with varying backgrounds, and helping us all to move toward our common goal. I typically work with engineers from various disciplines (electronics, software, mechanical, etc.), 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 (along with project managers, whose role we sometimes fill) 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:

1. Helping team members to understand a bit about what other members do in their jobs. This helps members work together more efficiently because they have a deeper understanding of one another’s needs. It also builds respect: everyone else’s job seems easy compared to ours until we understand some of the many details of what they do.

2. Helping to ensure that the cracks are filled between the knowledge and skills 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 we’re 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’ve found that there are a number of topics that I get to teach about pretty regularly to technologists and non-technologists alike.

The why behind this book is simple and selfish: it’s a book I’ve wished I had for years. Something that I can hand to team members, customers, and vendors to review those topics that come up time and time again, and to do it in an orderly and comprehensive way that gets everyone on the same page, and hopefully the right page.

Who Should Read This Book?

This book is intended to be useful to a wide range of folks who want (or need) to learn about the product development process:

• Makers thinking about taking the next step and creating a product, perhaps funded by a crowdfunding campaign on Kickstarter, Indiegogo, or similar.

• Members of product development teams who want to understand how they can work better within their team to build better products, have fewer surprises, and have more fun.

• Management types looking to understand the total scope of product development so they can do a better job of planning costs and timelines, and of supporting the technology folks.

Not all chapters will be useful to all of these groups: for example, management types probably won’t want to read about the details of power path management in Chapter 9. However, when these folks have questions such as “Why does developing something as simple as the circuitry and firmware to power a device and charge its battery takes months of work?”, they can skim that chapter and get a feel for the surprising number of problems to be solved in that seemingly simple task.

Who Might Be Disappointed by This Book?

You might not get much out of this book if:

• You’re a technology expert in the category of product development and you’re not interested in (or already know) how other technology experts contribute to product development

• You’re looking for in-depth information on a particular aspect of product development, particularly mechanical engineering or design (e.g., industrial design, user experience design, etc.)

What’s Covered? What’s Not?

This book will not teach you how to be an engineer, industrial designer, or project manager. There are plenty of other good sources of information on how to do those things, as evidenced by the many people who do those jobs well. Rather, this book is intended to help people to do their jobs better within the context of developing a product.

It’s a practical book, based on my own real-world experience and the information that’s proven most useful to most people involved in product development. The topics covered address the issues that I see come up in virtually every product development effort, and which are often addressed nonoptimally.

My first goal is to give a sense of the many different activities involved in getting a product to market, and how those activities can be fitted together in a way that optimizes efforts and increases chances of a successful outcome.

My second goal is to fill in the gaps between the information that’s easily available from other sources and the knowledge needed to have a smooth journey through development. This gap varies tremendously by activity. For example, there’s (more than) plenty of good material available in the world that generally covers Linux as an operating system, so there’s no need for me to add to that general knowledge.

But there are little bits of knowledge that are tougher to find about using Linux in an embedded system, or that designers/developers sometimes don’t even think to look for until they get stung by problems, and these are the types of things that are covered here. Examples include dealing with boot loaders, and the challenges in keeping device drivers functional with new kernel releases; these are types of details that I cover to fill in the gaps. The book’s slant is decidedly toward electronics and software. Mechanical engineering and design (e.g., industrial design and user experience design) are not covered in as much depth in part because I have less background in these fields, and in part because these have tended to not cause big technical headaches in the product development efforts that I’ve been involved with. That’s not to say that these are not important: great design and mechanical engineering can add tremendous value to products.

How This Book Is Organized

The book is organized into three basic sections.

The first section is a single-chapter introduction that hopefully sets the stage by revealing the single most important rule of product development, and discussing the 11 most common pitfalls that derail development efforts.

The second section, Chapter 2 through Chapter 6, discusses the development process for intelligent products from a nifty product idea all the way through to manufacturing.

The third section, Chapter 7 through Chapter 12, contains deeper dives into specific development topics that are of particular importance in the development of intelligent products, and which I’ve found that other available sources do not cover well, cohesively, or at the right depth.

A Word on Nomenclature

Design, designer, develop, and developer are words with ambiguous meanings, yet they’re impossible to avoid in a book such as this.

For example, a person who figures out how to create a new circuit to accomplish a task is usually called an electronics designer. Yet a person who does the same kind of task, but in software, is usually called a software developer. The folks who specify a product’s aesthetics are also referred to broadly as designers.

The context in which these words are used usually clarifies the intended meaning, but not always. For example, if I pick up a product and ask “Who designed this?”, I could be asking for the identity of only the people who created the aesthetics, or the identities of the technical folks as well.

To avoid confusion, we’ll try to stick to the following conventions:

• Creating software will be referred to as software development, which is performed by software developers

• Creating electronics will be referred to as electronics design, which is performed by electronics designers

• Creating mechanical parts will be referred to as mechanical design, which is performed by mechanical designers

• Developing aesthetics (look and feel, and usability) will be referred to generically as industrial design, which is performed by industrial designers

• The totality of the work done prior to development (i.e., creating the recipe that we’ll hand to manufacturing) will be referred to as design/development, which is performed by designers/developers

A Word on Jargon

Technology tends to cultivate jargon—words, phrases, and acronyms only understood by a small group of cognoscenti. Because the following are true:

• Product development encompasses several fields of engineering and design, and often multiple specialized technologies

• The jargon itself can be fuzzily defined; i.e., a bit of jargon can mean different things to different people (it happens all the time!)

Things can seem like a Tower of Babel on occasion. For this reason, I’ve generally tried to stay away from specialized jargon, although I do define commonly used bits (and point out when their meanings are not always agreed upon). In some instances, this might lead to using expressions that are a little different than what an expert in that field might use, in an attempt to keep concepts clear.

As I’ll emphasize throughout the book, the most important thing when it comes to jargon is that all team members use the same words in the same way. If you’re not sure how to use a word, or hear a word that’s unfamiliar, it’s best to be up front about it with everyone who’s part of the conversation and make sure that everyone’s on the same page. I’ve been doing this stuff for a while, and still rarely have conversations in which I don’t ask “What exactly do you mean by X?”

Keeping in Touch

One of the wonderful things about publishing these days is that books can be updated fairly regularly. If anything is unclear or there are additional topics that you’d like to see in this book, please let me know via email at [e-mail]. Or visit my blog, which I’ll try to keep updated with material relevant to this book.

Safari® Books Online

Safari Books Online (http://safaribooksonline.com) is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business. Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.

Safari Books Online offers a range of product mixes and pricing programs for organizations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and dozens more. For more information about Safari Books Online, please visit us online.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

• O’Reilly Media, Inc.
• 1005 Gravenstein Highway North
• Sebastopol, CA 95472
• 800-998-9938 (in the United States or Canada)
• 707-829-0515 (international or local)
• 707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/prototype-to-product.

To comment or ask technical questions about this book, send email to [e-mail].

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments

Ultimately, I owe a debt of gratitude to the many people who’ve taught me many things over my years of developing electronic products. The full list might double the size of this book yet still be incomplete, so I’ll stick to those directly associated with this tome.

A huge thank you to...

The good people at O’Reilly, particularly to Mike Loukides, Meghan Blanchette, Gillian McGarvey, and Melanie Yarbrough, who gave me the opportunity to write this book and guided my coarse keyboard meanderings into something that looks like something, all with great patience.

My reviewers, who helped keep me honest and technically coherent: Alan Walsh (who also contributed photos), Bill Nett, Chuck Palmer, Johnson Ku (who also helped on MicroPed), Kipp Bradford, Liz Llewellyn, and Pete Scheidler (who also helped on MicroPed).

My MicroPed team: Erik Schofield, Evan Gelfand, and Jon Goldman (who also created the 3D drawings in Chapter 6).

Alec Chevalier at Liberty Engineering and Rich Breault of Lightspeed Manufacturing, for providing the opportunity to take manufacturing photos.

Adafruit, Digi-Key, Paul Boisseau at Pyramid Technical Consultants, SparkFun, SPEA, and WikiMedia for providing or otherwise being a conduit for photos.

And most of all, to Marian and Ben, who’ve put up with more than two years of my scratching this itch. I love you guys very, very dearly.