Prototype to Product: A Practical Guide for Getting to Market

by Alan Cohen

Product development is the magic that turns circuitry, software, and materials into a product, but moving efficiently from concept to manufactured product is a complex process with many potential pitfalls. This practical guide pulls back the curtain to reveal what happens--or should happen--when you take a product from prototype to production.

For makers looking to go pro or product development team members keen to understand the process, author Alan Cohen tracks the development of an intelligent electronic device to explain the strategies and tactics necessary to transform an abstract idea into a successful product that people want to use.


Learn 11 deadly sins that kill product development projects
Get an overview of how electronic products are manufactured
Determine whether your idea has a good chance of being profitable
Narrow down the product's functionality and associated costs
Generate requirements that describe the final product's details
Select your processor, operating system, and power sources
Learn how to comply with safety regulations and standards
Dive into development--from rapid prototyping to manufacturing
Alan Cohen, a veteran systems and software engineering manager and lifelong technophile, specializes in leading the development of medical devices and other high-reliability products. His passion is to work with engineers and other stakeholders to forge innovative technologies into successful products.

Genres: Business, Design, Engineering, Nonfiction, Technology

438 pages, ebook

First published May 22, 2014

Reviews

[Nicholas Su · Rating 4 out of 5]

Picked this book out mostly thinking it would be useful for my new job (hardware design at a tiny startup), but it ended up being a book I wish I had read way earlier in my career as a hardware engineer! For anyone doing hardware design (mechanical, electrical) or even software people working on hardware products, this book is a great overview on the breadth of topics that one should prepare to deal with in the hardware development space. This would have been incredibly useful at my last job (at a large, mature engineering organization) in understanding how so many different departments and parties are needed to bring hardware ideas from "prototype to product."

[Ante Rogosic]

This is the book to read if you are preparing yourself for a technical start-up (go to Look inside on Amazon to see the details). Here you will discover many details you do not know related to getting a product to market. After reading this 440-page book, there will not be much to ask. You will learn a lot about the equipment and materials you need, regulations and safety standards you have to comply with, analyzing the market, ways to avoid common pitfalls, and a lot more. Alan Cohen, a veteran systems and software engineering manager and lifelong technophile, specializes in leading the development of medical devices and other high-reliability products.

[Budi Arsana · Rating 1 out of 5]

The only great part is chapter one where it explained the deadly sins in product development, the knowledge in this chapter could be applied to most of product development principle.

Then the rest of the chapters goes too deep and too much into electrical engineering for mass production where it's a topic that did not interest me.

[Yk Chia · Rating 5 out of 5]

Prototype to Product: A Practical Guide for Getting to Market - Alan Cohen (Highlight: 43; Note: 1)

───────────────

◆ The Vice of Assumption

▪ There are two common deadly sins that fall under the vice of assumption: Assuming that we know what customers want Assuming that customers know what customers want

◆ Deadly Sin #3: Assuming That Users Know What They Want in a Product

▪ what potential users see in their minds’ eyes when envisioning a new product might be very different than their reality once a product is in their hands

▪ Finding out what users really want is largely a function of letting them try things out (features, prototypes, etc.) and seeing if they’re happy

▪ it follows that we should start giving them things to try as early as possible instead of waiting until the end and praying that our assumptions (or theirs) were correct

◆ Deadly Sin #6: Not Assigning Responsibility

▪ Simply creating a task on a project plan with a due date and a budget doesn’t ensure that the task actually gets done by its due date and within budget

▪ Adding an owner to each task greatly increases the odds of success

◆ Deadly Sin #8: The Sin of New-Feature-itis

▪ It’s best to pick a limited feature set at the start of a project, be skeptical about adding new features during development, and focus on making those few features work really, really well. Compared to implementing more features with less polish per feature, we’ll get to market faster and cheaper, and most customers will like our product more.

◆ Deadly Sin #9: Not Knowing When to Quit Polishing

▪ As long as our product sells well, we’ll use those thoughts to make our next-generation product even better for our customers

◆ The Vice of Hubris

▪ It’s easy (and important) to be confident at the start of the project

▪ We will fail early, we will fail often, and the measure of a successful effort lies largely in how failures are dealt with

◆ Deadly Sin #10: Not Planning to Fail

▪ We must plan to fail

▪ padded by 20%-30 to account for the inevitable bad surprises

▪ these instances, it’s good to have a list of significant project risks at hand to demonstrate why we should plan for the unknown

◆ Deadly Sin #11: Developing Technology Rather Than Developing Products

▪ We can choose to create technology for our product, or in many cases we can choose to integrate existing technologies. If the product can be developed quicker/cheaper/better by integrating existing technology (and it usually can be), then that’s the way to go.

▪ Apple and Microsoft, two companies that have been extraordinarily successful at developing products. It could be argued that neither has developed revolutionary technology, they’ve only developed revolutionary products. Both Apple and Microsoft snagged from Xerox the concept of an operating system which uses windows and a mouse

▪ They’re quite content to purchase or otherwise adopt existing technologies if that’s what will do the best job of getting great solutions to their customers

▪ adopt the Apple/Microsoft mindset: “What’s best for our customers

◆ Supply Chain

▪ Supply chain folks can work out various deals with vendors to ensure we have parts to build with while maximizing financial health

◆ Building Circuits: PCB Assembly

▪ PC board assembly (PCBA

◆ A Great Idea

▪ A great idea for a product is the intersection of a cool idea and a need that wants to be fulfilled

▪ In some instances, successful projects are an exercise in simply copying what someone else has done, and using an uncreative advantage to profit from it

▪ turns out that making cool ideas work well is even more challenging than coming up with the cool idea

◆ Preliminary Planning: Does this make sense?

▪ The fundamental question we want to answer is does this idea make any sense at all? In other words, is there a reasonable possibility that the return will be greater than the effort

▪ The fundamental question we want to answer is does this idea make any sense at all? In other words, is there a reasonable possibility that the return will be greater than the effort?

◆ Ballparking

▪ Before we spend a great deal of time with market research

▪ it’s good to get some quick, rough answers to basic questions to see if we even have a prayer of success

▪ Questions that we’ll want rough answers to include: What will our product do? What will it look like? How many people might want the product we’re thinking of making? How much might they pay for it? How much effort will be required to develop it? How much will it cost to manufacture and ship? What are some good ways to market and sell it? Have others tried to do this? Have they succeeded or failed? Why? Why is our idea or execution different/better? Who could participate in design, development, perhaps also marketing and sales? What will they be looking for in return? Will we need external funding for this? What are the potential sources for any funding we need? What will they be looking for in return? What’s the likelihood that these sources would commit to funding this effort

▪ it should probably involve brief interviews with technology and marketing experts, and prospective customers

◆ First Reality Check

▪ If the thing’s obviously a loser, we can cut bait now and use move on to landing bigger fish

▪ In many cases, we’ll see obvious problems and it will be easy to decide to move on to something else. On the other hand, it’s rare that a new product development is a slam dunk (Dealing with opportunities and risk)

▪ Optimism is best when tempered with a good dose of worry

▪ In most cases, there’ll be a mixture of opportunities and dangers. How to decide? A venture capitalist once told me something that’s helpful: “If I declared that every new idea was a loser and passed on investing, I’d be right 80% or 90% of the time. I’d have an amazing track record of being right! But I’d never make any money, either

▪ Every new opportunity has a good bit of risk, so my suggestion is to look for big potential upside, and risks that seem manageable

◆ Prototypes

▪ works-like and/or looks-like prototypes

◆ Testing

▪ Testing is how we find out about problems, and problems are always cheaper to fix if found early

▪ Certification testing

▪ design validation testing

▪ includes exercises like giving prototypes or finished units to prospective users to see if they can use the product to do accomplish the tasks they’re intended to perform

▪ factory testing assumes that the engineering design is correct, but checks to ensure that each device is manufactured

◆ Purchasing

▪ purchasing for prototypes requires more care than might be obvious, and being too casual about purchasing during the development phase can lead to getting stung pretty good down the road

▪ The prototype parts we use should also be acceptable for production, which requires diligence and research

▪ Many parts have significant lead times

◆ Marketing Requirements

▪ Lists of high-level wants like these are sometimes called marketing requirements, because they ultimately encompass the claims that marketing folks will make that can be understood by typical users

◆ Requirements vs. Goals vs. Specifications

▪ Requirements are quantifiable things that the product must do

[Jonathan · Rating 4 out of 5]

This is a comprehensive book. It covers everything a person needs to know about starting a product (focusing on physical hardware devices). It gets appropriately in the weeds, and has appropriate levels of detail on how and why one should make decisions in their product process.

Perfect for my needs.

[Sammy · Rating 5 out of 5]

This book is a must for any electrical or software engineer trying to create a product. The content doesn't only give advice about the technical details but also covers the management and systems engineering details.

[Jeff Patterson · Rating 5 out of 5]

Very interesting and full of information that I hadn't considered.

[Jonathan · Rating 5 out of 5]

An amazing book on product development.

[Dominic · Rating 5 out of 5]

Rapid Prototyping. Need to spend more time to really get into this book. Might be a good winter project/read to tie to my Second Brain.

[Delhi Irc]

DL027805-6 GG7

[Jon · Rating 4 out of 5]

Very thorough, perfect for someone looking to build a physical consumer electronics product.

[Jeff Patterson · Rating 5 out of 5]

Insightful and easy to read and follow.