Six Steps to a Successful Hardware Product

by John J. Smith on Sunday August 03rd, 2014 08:21 PM

I've often heard it said that successful hardware development is impossible in a startup environment. The usual complaints are "It's too expensive", "It takes too long", and "It's too difficult to manage". I can tell you from experience that none of this is true anymore. With the right team in place, there is no reason why hardware development should take any longer or cost any more than a comparable software project.

There was a time not long ago when hardware did suffer from all of these problems. However, recent advances in technology have helped to lessen, and often eliminate, many of these concerns. ECAD tools have added significant time-saving features like one-click generation of 3D board models, easy incorporation of FPGA code, and comprehensive device simulation. Advances in technology have also dramatically reduced the cost and delays of developing PCBs. Even chip manufacturers have contributed by lowering the power consumption and component count of designs.

The one thing that remains a problem is the approach to hardware development. Traditionally, hardware engineers cling to a time-honored "waterfall" model. In this methodology, you cannot begin a step until the previous step has been completed in it's entirety. Though it works, it has a profound affect on time to market. In reality, there are lots of tasks that can be performed in parallel, or at least in advance.

"Agile" methodologies, though effective for many types of projects, can actually make things worse in the hardware arena (please keep the "blasphemer" comments to a minimum). I once attempted to formulate a plan to fit hardware development into an agile model (as a certified Scrum Master and a hardware designer, I was eager to combine the two fields). However, I noticed that the results either injected unnecessary delays and expenses, or required some very "un-agile" approaches (i.e. 12 week sprints). Most of the trouble centered around the fact that many hardware tasks weren't easily broken into 2 week chunks. Any attempt to do so resulted in artificial results that confused the issue. Advice from my Scrum Trainer didn't help much. His proposals were well-intentioned, but unnecessarily expensive and lengthy. It's not all bad, though. I believe that Agile has a lot to offer if you interpret the concepts properly and use a common sense approach.

In the end, I set aside what I knew about development processes and took a fresh look at hardware development. I looked back on the history of products I had been involved with in the past. I considered what worked, what didn't, and what got me into trouble. I was able to extract a list of six tasks that should be completed in order during product development. Here's what I came up with:

  1. Develop a Concept and Business Case
  2. Assemble a Core Team
  3. Evaluate Available Technologies
  4. Develop an "Alpha" Product
  5. Manufacture a "Beta" Product
  6. Release to Manufacturing

These six tasks, or steps, should not be considered mutually exclusive or totally dependent on previous steps. There is no reason why you shouldn't work on more that one in parallel. However, I would caution against working on more that two at a time. This could put you way ahead of yourself, and lead to a lot of wasted time. It has the potential of forcing you to backtrack through the steps because you missed an important detail.

Obviously, none of this applies to basic research, and I've intentionally left this off of the list. If part of your specification will include something like "must be compatible with 6G-SDI", you should probably familiarize yourself with 6G-SDI before your evaluation step.

How you organize your team's time during each step is usually dictated by personal preferences. Whether you choose agile methodologies and their inherent reporting mechanisms or waterfall methodologies and their copious documentation trail is up to you and your team. Each has it's advantages and disadvantages.

The main point of these steps is that they should be completed in order. If you finish your alpha design before you have evaluated the necessary technologies, you have probably jumped the gun. Go back and finish your evaluation before you send the alpha design out for fabrication.

Lets take a look at the steps in greater detail. Many will look familiar because they are common to all technical projects. Others are just plain old common sense.

1. Develop a Concept and Business Case

The most important factor in the success of a design is, of course, the concept. During this step, you should decide on initial features, basic form factor, and unit cost. At this point, these should be expressed as targets, not absolutes. You will need to refine these in later steps, but they should be a little 'fluffy' for now. You should also avoid anything that looks like an implementation detail. These details will only serve to stifle creativity.

In parallel, you should evaluate your target audience and market size. This really isn't very different from the due diligence you would perform for a software product, a toy, or an ICBM. Some of the specifics will change, but the basic concept is the same... make sure that you have a good business case.

At the end of this step, you will have a preliminary product specification. It should contain a list of feature-oriented requirements, and may also include a list of desired items. It should be entirely devoted to answering the question "what are we building" and should avoid any mention of "how do we build this?". To that end, it should be as non-technical as possible. In addition, it should be brief. It should consist of one or two paragraphs of explanation and a list of features. If it is longer than a single page, go back and check for excess technical detail.

2. Assemble a Core Team

Now that you have a concept, you'll need to choose a core team, and transfer your vision to them. Be prepared for a lot of questions. Questions are a sign of interest. Choose your team based on their experience and attitude. For the most part, the same basic principles apply to hardware teams as they would to any other kind of design team.

At a minimum, your core team should have a Product Owner and a Technical Owner. The Product Owner performs the task of refining your vision of "what are we building?". The Technical Owner is responsible for tackling "how do we build this?". Since these tasks are parallel paths to the same goal, it is best that they be assigned to different individuals. More ambitious projects will require additional Subject Matter Experts (SMEs). These should be brought in as needed, but with an eye toward keeping your team at an efficient size. Since larger teams tend to take longer to come to an agreement, you will want to limit the team size to only what is warranted.

Now that you have your team assembled and briefed, it's time to turn them loose and watch them go.

3. Evaluate Available Technologies

This part of the process is heavily weighted toward the Technical Owner. The Technical Owner will be acquiring evaluation hardware that is technologically similar to the final product. Often this consists of a handful of small PC boards sold by the chip manufacturer for this very purpose. The end result of all of this activity should be a device that performs most or all of the product's functions, but may look like a technological nightmare (aka 'Frankenbox'). Don't be too concerned about the appearance just yet. The next step will take care of this.

Meanwhile, the Product Owner is considering the user experience. He should engage potential customers as an advisory resource. He should be developing the final appearance and assessing the technologies required to achieve it. His output from this step should be a refinement of the initial product concept that includes sketches, requirement modifications, and performance metrics.

If your product includes any resident software development, this would be a good time to bring in your software team. They will want to look at the basic architecture of the system and make recommendations for software tools. You may even want them to develop a proof-of-concept application at the direction of the Technical Owner.

At the end of this step, all of your core team members should be comfortable with the final direction of the project. Relevant technologies have been identified and understood, the original concept has been refined into an architecture, and the desired user experience has been refined to a product specification. All of the fuzzy concepts have been refined, and you are confident that you will turn your dream into a reality.

4. Develop an "Alpha" Product

The alpha development step is when your Product Owner and Technical Owner will bring in additional resources. These can be members of the core team, but they don't need to be. If you have the required resources in-house, use them. If not, you will need to develop a strategy for bringing in outside help.

One strategy for less ambitious projects is to divide the project into three groups: "inside the box", "outside the box", and "the box". "Inside the box" includes any COTS or custom components that are hidden by the enclosure, as well as any OS or driver software. Finding resources for this would be the task of the Technical Owner alone. "Outside the box" consists of everything that the user can see, including the appearance of the box, the user interface, and the packaging. Finding resources for these falls into the realm of the Product Owner. The final, and (hopefully) smallest group would be "the box" and is made up of grey areas that the two leaders should collaborate on. This includes things like box size and connectors (i.e. standard USB or micro USB).

For more ambitious projects, you should consider a design firm that specializes in this stage of development. This is the stage that engineers enjoy the most, so there are many good firms out there ready, willing, and able to help. As always, perform your due diligence on the firm before signing anything.

Your software team should inherit 'Frankenbox' from the evaluation step and use it for initial development. Though final debug may not be possible, it's likely that they can develop a large majority of the necessary software.

As the alpha design starts to take shape, you should start researching Contract Manufacturers (CMs) to produce your hardware. Ask a few CMs to give you a budgetary estimate based on your pre-alpha BOM (Bill Of Materials) and mechanical drawings. Make sure they include labor rates, profit percentages, and fees. Everything else will just be a guess.

At the end of this step, you will have a working model of your device. You can demo it to customers, board members and family members. You should crow about your design success... you deserve it. You have chosen a manufacturer for your product, and have all of the financial data you will need to go into production. However, you aren't quite done yet.

5. Manufacture a "Beta" Product

Beta development is when all of the prior design work comes together to form a manufactured product. You may need to make a few adjustments to your design to optimize the manufacturing process, but these should be small and focused. You should look at this as a dress rehearsal for your hardware release. To that end, your CM should take over as many of the tasks required for the completion of the product as possible. This will allow for a smooth transition to the manufacturing step

Your core team has finished it's design responsibilities, and can shift into preparation for manufacturing. They should be looking at how to test the device on the manufacturing floor. They should also investigate any tests required for hardware certification by a nationally recognized laboratory. Your CM can be an invaluable resource for these tasks, and can often be persuaded to perform them (for a fee, of course)

If you have any resident software, your software team should inherit your alpha units for development. This will allow them to complete their debugging efforts, and to integrate the device with the rest of your system.

At the end of this step, you will have a small number of units (usually between 20 and 100) that you can confidently show to prospective customers and use for final system development. The design is finished, the production process has been optimized, and you are ready to take orders for your ground-breaking product. All certifications are complete, and you are approved for launch. Congratulations! You only have one more step to take.

6. Release to Manufacturing

Release to manufacturing is the only step that (usually) requires a formal sign-off. Your CM will require an approval from you for just about everything. This is normal. It is primarily there to make sure that all parties know what to expect from the manufacturing process. Read through the document and sign it when you are comfortable. Congratulations! You're done!

At this point in time, the core team you assembled is no longer needed for this product. You can release them from their responsibilities and move them on to bigger and better projects. The remaining activities are what you would expect from the release of any type of product. These are better handled by sales and logistics experts.

Now would be a good time to come up with your next hardware product. Don't forget to start from the beginning!

There are 2 comments

Sunday August 10th, 2014 01:58 AM by John J. Smith

Please forgive the mammoth post. There was a lot of material to cover and I wanted to get through as much as I could. I'll try to avoid such tomes in the future.

Sunday August 17th, 2014 03:57 PM by John J. Smith

I've gotten a request to make an executive summary of this page. Sounds like a good idea to me. While I'm at it, I'll add a few things to this post that I omitted in a vain attempt at brevity.

Add Your Comment

Note: This is an anonymous comment page, so we've taken drastic measures to eliminate spamments. Any comment that looks like it contains a link (href=[anything]) or a URL ([anything]://[anything]) will be shunted to a secondary page, where you will have the opportunity to remove the unallowed text.

General references to web sites or pages that would not result in an SEO-friendly link (i.e. are allowable. All tags will be automatically stripped

Name (optional) :

Email (optional, not publicly displayed, but available to post author for offline discussion):