Chapter 2. Development Process Overview

Several categories of activities take place when creating a new product, including:

Each of these categories, of course, consists of many tasks and subtasks. All of these activities will absolutely be performed between the start of development and the time when we have a successful product on the market. Our job is to see that they can get done in an orderly and efficient way.

For example, we can plan well for FCC Part 15 approval (required of virtually all electronic products sold in the US), testing prototypes as we go along to make sure the final product passes its test. Or we can wait until product development is complete and hope that our product passes its tests; if it doesn’t, our product development isn’t complete, and we might have to go back and do substantial redesign. Or we can wait until we get a letter from the FCC alleging that we’re illegally selling uncertified devices. Obviously, the first of these options has the lowest potential for bad outcomes.

The difference between successful and failed products is largely in knowing, at the project-wide level, what to do and when to it. In this chapter, we’ll review the general activities performed during product development and the sequence that often is the most efficient. Note that the importance of sequencing cannot be overstated: following a reasonable sequence throughout a project saves time, money, and aggravation, and creates better odds of success.

Product Development Life Cycle Overview

The activities that take place in bringing a new product to market naturally fall into four phases:

  1. A cool idea

  2. Planning

  3. Design/Development

  4. Manufacturing

Figure 2-1 shows a flowchart of these phases broken into more detail.

Flowchart of a product development process
Figure 2-1. Flowchart of a product development process

Some of these steps are short, and some are longer. Some might take as little as a few minutes, such as in the case of some friends looking to build something cool to make a few bucks on Tindie, or many months or years in the case of large corporations building complex and/or high-risk devices. As mentioned earlier, some steps may be omitted as appropriate—each project (and project team) is different.

The flowchart in Figure 2-1 is used throughout this chapter as a map to remind us of where we are as we step though the process.

Preliminary Planning: Does This Make Sense?

Few things feel worse than spending substantial time on an effort that’s not enjoyable, goes nowhere, and/or could have been better spent doing something else. As the popular expression goes, “Well, that’s [fill in the amount of time] of my life that I’ll never get back.”

So that we can be smart about how we spend our hours, our first job once we have a cool idea is to do a reality check on whether it’s something that we really want to pursue. 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?”

Return does not necessarily equal cash, but money is usually one important part of the equation. Since time is precious, at this point we’ll spend as little time as possible to get a quick feel as to whether we’re poking in the right direction.

Image

In a sense, the product’s details begin to take shape even in the earliest parts of this feasibility planning because it helps to know what the product is (features and functionality) when guesstimating costs, markets, timelines, and so forth.

Ballparking

Before we spend a great deal of time with market research, detailed product plans, and other activities that we’ll eventually want to do before committing to developing our idea, part of the preliminary planning process is to get some quick, rough answers to basic questions to see if we even have a prayer of success. If chances of success are slim to none, then we can quickly move on without wasting more of our time.

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? 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, and 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?

This exercise can be as simple as sitting around a table and tossing ideas on a whiteboard with friends, family, and/or colleagues. But unless we’re experts in our product’s domain, it should probably involve brief interviews with technology and marketing experts, and prospective customers. Serendipity should be cultivated during these interviews: it’s often the case that our initial ideas aren’t quite world-beaters, but a little tweaking based on some new information might make a big difference.

While it’s natural to focus on our potential product at this point, there’s another important aspect that’s required for success, which we’ll consider next: what are the potential needs of the folks who’ll help bring our product to market?

Setting Stakeholder Ground Rules

The ground rules are the objectives of the project stakeholders, and these should be worked out during this preliminary planning phase so that we know how to keep everyone happy.

In the case of large companies, this includes an understanding of the resources that can be committed (people, money, etc.) and the return expected in exchange for investing resources (money, market share, prestige, experience with a new technology, etc.). There’s usually a person or committee that weighs a potential product’s costs versus benefits and decides whether to proceed or not.

On the other end of the spectrum, for smaller projects either done “on the side” and/or by companies that don’t (yet) exist, there are similar expectations to be met by multiple founders looking to trade their time and/or money for some sort of return. This can be tricky: whereas a larger company typically has a single list of criteria that they expect a new project to meet, within a “seat-of-the-pants” effort each participant might have different expectations, along with different resources (time, money, expertise) they expect to invest. Keeping everyone happy can be a challenge.

In my experience, not understanding what each party is willing to invest and what they expect in return is a leading cause of projects that end in failure and hard feelings. Projects are a journey that usually lasts months or years. If the needs of team members, investors, and other stakeholders are not being met, then stakeholders will tend to become less helpful. And when they do, other stakeholders tend to become grumpy. So before starting any project, it’s best to have a good understanding of what each stakeholder is looking to contribute and what they expect in return, and to set up some rules around how to move forward if those contributions need to change (someone has a baby, gets a better job offer, runs out of money, etc.).

Once we understand commitments and expectations, there are two strategies for fitting together the project with the team’s needs: we can either adapt the project to the team or adapt the team to the project. In the case of projects that have a single contributor, the way forward is pretty clear: since (to paraphrase Frank Zappa) we are what we is, our best bet is to select a project that motivates us and to plan development so it meets our needs.

In the case of project teams larger than one, things can be more fluid: for example, we could pick a team based to a greater or lesser degree on what the project needs in total, and then plan the project development effort based on the needs and desires of team members.

First Reality Check

Most of our time in product development is spent on carefully growing lovely trees, but once in a while we need to pull back a bit and examine the forest: does the whole thing seem to hang together? At this point, all we have is a group of seedlings, but does it look like these seedlings have a reasonable shot of becoming a lush forest? Or are they already wilting?

Image

As we’ll see in a bit, getting to the point where we’re pretty confident in the technical and business success of a new product usually takes a fair bit of planning, certainly more than the surface scratching we’ve done so far. But before we do even that work, we should make a preliminary assessment as to whether we have a reasonable shot at success.

If the thing’s obviously a loser, we can cut bait now and move on to more promising ideas. If we do decide that our concept has a good chance of success, in our next phase we’ll go on to spend substantial effort filling in the details required to make a final decision on whether to go for it.

So given our first-order understanding of features, market, expenses, revenue, marketing, sales, and resources, does developing this product seem to make sense? Do the odds of success seem good, nonexistent, or somewhere in between? Does development seem like an adventure or a schlep? Can we keep stakeholders happy?

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. In fact, if we’re positive that our idea is a winner, we’re probably being dangerously optimistic. 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.

If things look good and we decide to proceed, our next step is to create a detailed set of blueprints for developing our product.

Detailed Product Definition, a.k.a. Surprise Management

Developing a product of any sophistication is a big deal. For projects that go beyond a labor of love, the folks investing resources into the venture would like to have a pretty accurate idea of what they’re building, and the time and cost to bring the product to market.

Image

In our preliminary planning phase, we did a basic sniff test: does the product have a reasonable chance of success? In the detailed planning phase, we’re looking to sharpen that preliminary planning exercise dramatically in order to cross out the unknowns. The overarching goal here is to make the project reasonably predictable so that we’re confident of what we’re building, and of the time and cost needed to bring it to market.

Boring can be good

In product development, surprises are rarely good. Detailed planning is about making the product exciting and the development effort as boring as possible.

Stated another way, the goal of detailed product definition is to minimize bad surprises. I sometimes think we should change the phrase detailed planning to surprise management; it sounds a lot less stuffy.

Whatever we call this phase, here’s what we’re looking to end up with:

  • A fairly detailed definition of our product: how it will look and function.

  • An in-depth plan of what needs to be done, when, and by whom. From this information, we can understand:

    • How much development will cost

    • How long development will take

    • The resources/expertise that we’ll need to have available

  • Solid financial models of how much our product will cost to build and sell.

  • An understanding of the major technical and business risks (i.e., what don’t we know that can burn us); even better, we’d like to minimize those risks before exiting this phase.

At the end of this detailed planning phase, we should have significant confidence that we know what the product and the project will look like moving forward.

Of course, detailed planning is difficult to do unless we have a pretty good idea of what we’re building, so at least a substantial piece of the product (particularly specifications/requirements and design) is performed during this phase. We need specific design information before we can reasonably estimate what the job will take; for example, the effort and costs to develop and manufacture a plastic enclosure are a good bit different than that for a sheet-metal enclosure.

And what about the technical unknowns? If our product needs a USB 3.0 port, and nobody on our team has ever designed that circuitry before, we could take a guess at how long the port design and testing will take, but it’s easy to be off by a factor of 10 or more on off-the-cuff guesses (USB is a particular culprit).

To narrow down the technical unknowns and thus increase predictability, technical risk reduction activities are usually run as part of this detailed planning phase.

Next, let’s take a closer look at what goes into the product design and risk reduction activities.

Product Design

As used in this book, product design is the science and art of creating specifications for how users will interact with a product. It includes color, size, ergonomics, screens, workflows, and virtually everything needed to describe how our product presents itself to the world.

At this stage, the design will likely live as:

  • 3D models carved from foam or printed on a 3D printer. These are useful for getting feedback from prospective users, and for helping the technology folks think about the mechanical and electrical challenges ahead. However, these usually don’t have all the detail we need—or the right colors.

  • 2D and 3D renderings on computer monitors that do have the right detail and colors. Less tactile, but great for visualizing what our product will look like.

  • Use-case diagrams in flowcharts for each task a user can accomplish and each interaction step between user and device.

  • Mockups of software screens that are displayed during the use-case diagram steps, which help the software folks understand and estimate their efforts.

  • One or more requirements documents detailing anything important that the product must achieve. For example, “The product must run for one year before requiring a battery change.”

Once we’ve defined the details of how our product appears to the world, we create a boundary around what our product needs to achieve, removing one important category of unknowns that can bite us later on. In reality, there will be design changes as we go along based on new information, but now we have an agreed-upon baseline.

The other big class of unknowns at this stage is typically around the technology needed to turn our design into reality. Next, we’ll take a look at knocking these risks down to size.

Technical Risk Reduction

Technical risk reduction is all about turning big technology unknowns into smaller technology unknowns. Big unknowns are usually those things that haven’t been done before by our team or (even more scary) haven’t been done by anyone, ever. These are the kind of unknowns that can totally derail a project if they turn out to be far more challenging than anticipated or even impossible (e.g., we need to do something that violates the laws of physics as they’re currently understood).

The best way to reduce risk related to a big unknown is to implement it, usually on a smaller scale, to demonstrate that it functions. The resulting design, often called a proof of concept or proof of principle, typically isn’t the final design but rather the simplest implementation that gives us confidence around knowing what the final design process will require.

For example, suppose we’re designing a battery-powered glass-break sensor for a home alarm system. The sensor communicates its status wirelessly to a base station, which might be several rooms away. Such a product, of course, requires a very reliable RF communications link. Marketing wants our sensors to be the tiniest on the market. Since the battery’s the largest part of the circuit, tiny sensor means tiny battery, and tiny battery means tiny power draw, and the circuitry that draws the most power will be for RF communications. So for our purposes, tiny sensor is synonymous with tiny-power RF circuit.

Nobody on our team has ever designed an RF circuit with these characteristics, so how do we estimate the effort to implement such a thing? We could simply guess that a tiny battery will work out because, you know, high tech does amazing things these days so why not? But what if we start design/development using a tiny battery, then find out that this requires us to develop very complex circuitry and software that takes way more time and money than we anticipated (and have available)? Or what if we find out we simply can’t use a tiny battery at all because it just can’t supply enough energy to run the sensor for very long? Big surprises are what happens.

To gain some confidence that our plans are reasonable, we’ll probably want to build an actual RF circuit powered by a tiny battery and test it carefully, either in a bunch of homes (to check RF connectivity in a variety of environments) or in some sort of lab mockup that simulates the worst RF conditions that we want to accommodate.

Instead of building and testing the actual circuit, in theory we could review for RF chip datasheets to find one that offers the low power consumption that we’re seeking. That might work, but as philosopher Alfred Korzybski wrote, “The map is not the territory.” What works on paper might not work in real life. It happens all the time. It’s usually best not to take a chance.

By retiring potentially derailing uncertainties early on, we’ll have a lot more confidence around our estimates of the scope of the development effort. At the end of this detailed planning process, if we’re smart and diligent at the effort, we’ll have about as good a guess as we can get as to what we’re creating, and how much it will cost to develop, manufacture, and sell.

Second Reality Check: Go or No Go?

Before we make a commitment to the substantial effort and cost of development, it’s time to take another bird’s-eye look at the entirety of what we now understand to see if things look good. Do the numbers work? Do we still feel good about the road ahead and the odds of reaching our destination? Should we do this?

Image

At this point, based on all of our planning, we should now have a pretty good idea of:

  • What our product will do

  • What it will look like

  • What effort will be needed to create it

  • What it will cost to manufacture

  • How we’ll market and sell it

  • The potential return for our efforts

These will all be guesses, but they will be far better guesses than we had when the product concept first popped into our heads. In my experience, even these detailed estimates will be low when it comes to cost and time: the real numbers will usually end up 20%–30% worse than even careful estimates by experienced estimators, because surprises happen no matter how hard we try to prevent them. So it’s best to pad cost and time estimates up to give ourselves room for error.

Making the decision on whether to move forward should be made with some care. It can be quite useful to pull in some experienced outside people (e.g., advisors or a board of directors) to help us make this decision. Hopefully, they’ll have good input, and having to make our case to others is a great incentive to do a thorough job of researching and articulating a good, succinct case. We like our idea and want to convince others, so we anticipate and respond to gaps in our thinking, things we’ve overlooked, or problems/risks we haven’t been willing to acknowledge. In convincing others, we often convince ourselves.

The decision process will look very different in different situations, particularly with regard to the trade-off between certainty and potential upside. In the case of a few friends looking for adventure, certainty will be low (i.e., there’s a high chance that things will go substantially differently than planned), but the product’s potential upside will (hopefully!) be high to compensate. Large corporations, in most cases, are looking for high certainty with the understanding that potential upside (i.e., revenue) is more limited (although still substantial).

If we decide to move forward, we now have blueprints for what to build (the product design) and how to proceed (the project plan). With these as our guide, we’ll next begin the true development part of product development.

Detailed Development

While development of various types has been taking place prior to this phase, here’s where we dig in and turn our detailed product definition into a manufacturable product. We’ll create and test iterations of prototypes that increasingly resemble the final product until we have something that we’re ready to move into production. Because this is probably the part of the process that most readers of this book are already familiar with, I won’t dwell at length on this phase here (but, as with the rest of the info in this chapter, I do provide more details throughout the remainder of this book).

Image

There are three areas of activity during development that warrant some discussion at this high level: prototyping, testing, and purchasing. The first of these is obvious; the latter two are often overlooked when thinking about development so I’m breaking them out to give them a little attention.

Prototyping

When describing prototypes, product developers often refer to them as works-like and/or looks-like prototypes. Works-like refers to a prototype that functions like the final product. Looks-like refers to (of course) a prototype that looks like the final product. Not surprisingly, a works-like/looks-like prototype both functions and looks like the final product.

Initial looks-like prototypes are usually created as part of a detailed product specification, described earlier. As we develop our product, we might want to change the design because of engineering issues or feedback from further market research, and looks-like models will be updated.

The initial works-like electronics prototype is typically a precarious-looking breadboard of electronics parts and development kits, along the lines of Figure 2-2, which serves several purposes:

  1. We can test and debug a great deal of our circuit design before going through the effort of designing and building custom PC boards.

  2. Breadboards are typically easier to test and debug than PC boards, because breadboards don’t need to be miniaturized. There’s lots of room for test points and so forth.

  3. Software folks can quickly have something to start development on that incorporates much of the final electronics design; they don’t have to wait for PC boards to be designed, manufactured, and populated.

An electronics breadboard prototype (courtesy Wikimedia Commons)
Figure 2-2. An electronics breadboard prototype (courtesy Wikimedia Commons)

Breadboards are followed by works-like/looks-like prototypes that increasingly embody the final product. Because breadboards are unwieldy, works-like/looks-like prototypes normally must use custom-printed circuit boards, but initial prototypes might have their enclosures and other mechanical parts created by a 3D printer. Later prototypes will use final (pending testing) materials, typically injection molded, so we can test the product’s true mechanical properties and inspect color, fit, finish, and so forth.

Each works-like/looks-like prototype is tested and debugged, and results are fed back into an improved works-like/looks-like prototype. This process is repeated until we have something we decide is ready to move into production. Simple devices might only require one or two works-like/looks-like prototypes, whereas a small and sophisticated device with many parts and tight tolerances like a new cell phone might require dozens of prototypes to get everything right.

Testing

It’s easy to fall into the mistake of thinking of testing as the thing that comes after development: develop it, test it, manufacture it. This is a bad way to think. Testing is how we find out about problems, and problems are always cheaper to fix if found early. So testing should occur throughout the development process. As we’ll see, it even continues on into manufacturing. There are several broad categories of testing that are somewhat related in practice:

  • Design verification

  • Certification test

  • Design validation

  • Manufacturing test

Design verification testing (DVT), sometimes called engineering testing or bench testing, is the type of testing associated with the development phase. DVT demonstrates that the product’s engineering design is correct (i.e., that it meets its requirements). DVT is usually extensive, sometimes incredibly extensive for products that are either complex or which must be highly reliable. On the bright side, full engineering testing is usually only performed once (perhaps on several units) when a design (or an update) is thought to be ready to release to manufacturing.

Certification testing can be thought of as a part of DVT, although I like to break it out separately as it tends to come in one clump at the end of development. Almost all products that contain electronics must be tested to ensure that they meet relevant regulations and standards. Examples of typical regulations and standards include US FCC Part 15 regulations for RF emissions (mandatory), and UL safety standards (optional). For devices that will be sold in other countries or devices that must be highly reliable, many other standards can come into play. For example, most electronic medical devices sold in the US and EU must comply with at least 18 different standards and regulations, and most of these require tests to prove compliance.

Certification testing usually involves handing our finished (or nearly so) device (along with a purchase order) to an impartial test organization that will test against the appropriate regulations and standards for safety and performance. If we pass the tests, we’re certified. If we fail any of the tests, we’ll need to update the design and try again. Because passing certification testing is so important, we’ll later discuss steps that we can take early in the process to reduce the possibility of failure and redesign.

Finally, manufacturing testing  assumes that the engineering design is correct, but checks to ensure that each device is manufactured properly. Testing is performed at one or more points during the manufacturing process to help ensure that we don’t ship a defective product.

To better see how DVT and manufacturing testing differ, let’s look at an example. During DVT we might try to test every last feature and function of our embedded software to check that the software is written correctly. But during manufacturing test, we assume that the software is written correctly: we only want to make sure that the software image was loaded correctly (e.g., by reading back a checksum after the load).

The good news is that manufacturing testing is usually largely a subset of DVT, so the efforts overlap. But DVT and manufacturing testing are quite different in several respects. DVT is performed only once in a while (e.g., when a new prototype is built), and usually by trained, skilled engineers and/or skilled technicians who can figure out what to do if a test doesn’t go as planned. Manufacturing tests, by contrast, might be performed by factory workers on every single device that’s manufactured, perhaps thousands each day, without a design engineer nearby to help if anything unexpected happens. So manufacturing tests must be quick, robust, and easy to run.

For unsophisticated products, a manufacturing test can be as simple as turning on a finished device and punching a few buttons to see if things seem to work. On the other end of the spectrum, for certain sophisticated products (often medical, automotive, defense, and aerospace applications), the cost of developing automated manufacturing test systems can be as high as the cost of developing the product itself!

Purchasing

Purchasing for prototypes and purchasing for production are two types of purchasing activities that are different, but linked.

It’s pretty obvious that purchasing for production requires a good bit of thought and effort; quantities are typically far larger than for prototypes, and there are many other considerations, such as maintaining a steady pipeline of parts, managing inventory, payment terms, etc.

Purchasing for prototypes is often pretty informal: order a few parts over the Internet, give a credit card number, then parts appear at the door in a day or two. No worries, right?

Well, 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. Two issues are often overlooked:

  1. The prototype parts we use should also be acceptable for production, which requires diligence and research. When we order parts for our first production build, we don’t want to hear that the nice LCD display used for our prototypes is no longer available; that would likely drive a significant redevelopment effort.

  2. Many parts have significant lead times, sometimes months between order placed and arrival, particularly for custom or semi-custom parts. So it’s often necessary to order long-lead-time parts as soon as we’re reasonably sure that they’ll be used rather than waiting until development is complete. Otherwise there might be a delay of weeks or months between the end of the development phase and the start of manufacturing while we wait for parts to arrive.

Once we do have all the parts that we need in hand, we can begin the next adventure in our journey: assembling units that we can sell.

Manufacturing

Folkswho are new to product development tend to think of factories as magic product copiers: we send our final prototype to manufacturing and exact copies start pouring out.

Nope. No magic, just lots of hard work!

As we’ll see in Chapter 3, manufacturing is complex, with lots of steps and lots of things that can go wrong, and which will go wrong, particularly as we ease into production and find the kinks we need to straighten.

Image

To facilitate kink discovery and straightening, production begins with two activities that we’ll discuss next: Factory New Product Introduction and pilot build.

Factory New Product Introduction

Factory New Product Introduction (NPI)  is the process of creating and proving processes to ensure that our wonderful final prototype, which was lovingly hand-built and tested by skilled technologists, will be reliably reproduced in the factory at high volumes and reasonable cost, by machines and workers with moderate training, and often halfway around the world.

(What could possibly go wrong?)

In the simplest case of low-volume production, the folks doing the manufacturing are the same folks who developed the product. They know all of the tricks for assembling and testing their product, and can change procedures on-the-fly as they find better ways to do things. NPI in this case is really not very new: rather, manufacturing looks more like building prototypes in higher volumes, which is why it’s sometimes dubbed protoduction.

When manufacturing is outsourced, the game changes, big time. There’s lots of new in NPI: new people, new processes, perhaps even a new language. This is where things can get pretty interesting, as it can require significant effort to turn all of the things that the designers/developers just kinda know how to do into explicit, clear, and easy-to-follow instructions and processes that work reliably.

Depending on the complexity of a product’s assembly and test, NPI can be quite extensive and require a good bit of interaction between designers/developers and factory staff. For example, NPI for a product comprising a single circuit board in a simple snap-together enclosure might take a day. In the case of a complex and critical electromechanical product such as a heart-assist device (which augments a weak heart with a pump), NPI can take weeks or even months; there are lots of ways to make mistakes when fabricating and assembling such intricate systems, and these problems need to be discovered and worked through for obvious reasons. In this case, it’s really bad to find out about a process problem through product failures in the field.

Once we’ve developed a manufacturing process that we’re confident will create quality devices with a minimum of effort, we’re finally ready to build our first units!

Pilot Production

The first manufacturing build of a product is often referred to as the pilot build. A pilot build is a “normal” build in that it’s performed against the manufacturing process that we expect to be standard, and it (hopefully) produces a salable product. But pilot build is different from other builds in that it’s done with extra care and quantification to evaluate the quality of the production process, and the quality of the product it produces.

The production process is closely examined to look for inefficiencies and the potential to produce nonconforming products (i.e., products that fail test).

The first products off the line are inspected with meticulous care. Beyond testing for functionality, we’ll check all mechanical tolerances, examine the quality of soldering (e.g., any solder flux residue left on the board), and so forth. This process is often called first article inspection.

Also, certain types of testing are better performed on production units rather than on prototypes; the two common ones being reliability and certification testing.

Reliability test results from manufactured units might be quite different from results obtained using units assembled in the lab due to subtle differences in assembly, including even little things like differences in the reflow temperature profiles used in soldering.

In the case of certification testing, third-party test houses may insist on doing their final testing on a product that’s been produced through our standard manufacturing process. They might also need to inspect the manufacturing process itself.

Final Thoughts

While the product development process flowchart that we’ve been using has nice boxes and lines, no project ever has crisp boundaries around activities and clean transitions from one phase to the next (even if the paperwork to management claims otherwise). Things happen, and they need to be dealt with. But by making a solid effort to plan for the right phases and tasks, and trying to sequence these in the most efficient way, we’ll reduce effort, expense, and anguish. Process will never eliminate the bad stuff, but it can definitely make the difference between an overall fun experience versus a death march.

Now that we know what the boxes are and how they link together, our next four chapters cover the broad phases of:

  • Preliminary planning

  • Detailed definition

  • Detailed development

  • Manufacturing

Rather than moving through these in strict chronological order, we’re going to mix them up a bit by starting at the end, with manufacturing; a bit of knowledge of the manufacturing process and the manufacturing world can be tremendously helpful during the rest of the design/development process. After our review of manufacturing, we’ll cover the other phases in order.