The Entrepreneur’s Guide to Product Development

So, what does it take to bring a new product to market? Find out in this light-hearted, entertaining introduction to product development for the entrepreneur in all of us.

INTRODUCTION

Epiphany! You’ve just had a brilliant idea for a hardware product that nobody in the history of the planet (you believe) has previously imagined. You call it the Gizmo, and it’s going to be revolutionary.

This grand idea quickly takes over your life. You begin to see every conversation, every meeting, every online post through the lens of the Gizmo. You’re self-motivated, not afraid to take risks, and clearly passionate about your idea. You begin to call yourself an “entrepreneur,” and you like the ring of it. You dip into your savings and try to scrape together funding from friends and family. Why won’t anybody return your emails or take you up on your generous offer to accept their donations to your venture? What is missing, obviously, is that you need to prove that the Gizmo is economically viable. You accept the challenge of turning your concept into reality and dream of selling your first Gizmos. You also recognize that time is your most sacred resource as an entrepreneur. You don’t want to get beaten to market, so better start selling Gizmos as soon as possible. As we’ll see, this obsession with getting to market fast, so central to entrepreneurship, can be a double-edged sword. Speed must be balanced by careful planning and taking time to go through all the proper steps.

GETTING STARTED

Until recently, conventional wisdom dictated that the first activity every entrepreneur must engage in is to create a business plan. The business plan forced the founders to figure out in advance the key unknowns of their venture, including the size of the opportunity, the solution provided, the value proposition, revenue models, sales strategies, and so forth. Particularly daunting were the five-year financial projections, often Excel spreadsheets that, when graphed, inevitably ended up as “hockey-stick curves” showing exploding adoption and growth.

The past decade has seen the rise of an alternative methodology, called the “lean startup ”, that rejects the traditional business plan. Instead, lean startups favor experimentation, customer feedback, and quick design cycles, always pivoting to better meet customer needs. While many tenets of the lean startup overlap with sound product development practices, these must be interpreted carefully.

One common misconception is that careful planning is archaic and no longer needed in product development. Like other parts of the business plan, a project plan is not particularly fun to produce. The project is rarely going to proceed as planned for very long. Assumptions need to be made, some of which will inevitably turn out to be false. Unforeseen factors, such as COVID-19, will suddenly become monumental. With so much uncertainty, why bother planning at all? The answer is that creating a detailed project plan pushes you to think through issues that are easy to miss otherwise.

From the outset, the plan makes you think carefully about the product’s chances for success by estimating (albeit incorrectly) the cost, timeline, and resources required to launch. You must try to answer, as objectively as possible, fundamental questions as to whether the return justifies the effort. The good news is that there is a well-established path for iterating on your design as you converge on the final, mass production-ready product.

Once you have created the project plan, gained an understanding of the product development process, and embraced the reality that the plan will change continuously, here comes the hard part: sticking to the product development process and not skipping steps. As an entrepreneur, you likely have scarce resources and a deep anxiety to see a prototype up and running. You may be tempted to cut corners, with the mistaken belief that you will be accelerating the product development process. The opposite is true. Defects that are introduced early on become increasingly expensive to modify or fix as development moves toward production. In the worst cases, the entire concept must be scrapped and re-engineered from scratch.

Armed with at least a basic understanding of the product development process, you head to your garage (you’ve heard that great businesses have been started in garages) and manage to cobble together your first prototype Gizmo using scavenged parts, foam core, and Krazy Glue.

You are elated to discover that it actually does something… if you hold it at just the right orientation and keep it away from direct sunlight. With some more effort, you assemble a prototype that you can show to real users. Take a page out of the lean startup and user-centered design playbook and immediately elicit customer feedback, ideally before you raise any capital. Be aware that early users will provide wonderful insights but may also get hung up on the poor look and feel of the prototype. To turn this monster into a real product, you realize that you need professional help.

Since you are not seasoned in hardware product development, you will want to find a team of experienced senior advisors and consultants. Since not every entrepreneur can afford to fund internal full-time engineers, outsourcing is a way to stay lean on employee headcount. If considering a product development partner, be aware that some firms specialize at making early prototypes but have never successfully transferred a product to production at a contract manufacturer (CM). You may also be tempted to choose a contract design manufacturer (CDM), a type of CM that additionally provides design support services at little or no cost. It’s tempting to think of CDMs as the lowest-risk path from concept to launch, as they tout their “end-to-end design,” “one-stop solutions,” or “turnkey capabilities.” Be aware, though, that CDMs are most interested in earning manufacturing revenue, and may provide an inexpensive (and mediocre) design as a way of locking clients in on the manufacturing business. Should you ever want to move to a different manufacturer, the CDM may hold the intellectual property hostage to dissuade you. In summary, consider your partner carefully.

THE PRODUCT DEVELOPMENT PROCESS

No matter which partner you choose, they will follow a product development process to bring your idea from early prototype to a fully manufactured product. An example of the phases of product development with the workflow volumes is shown in the graphic below.

EXPLORATION – PHASE 0

Depending on the maturity of your idea, a product development partner may recommend a Phase 0 effort to fully prove the technical feasibility of your idea. It can consist of research, concept work, exploring initial architecture, performing feasibility studies, and basic prototyping and testing. Let’s assume that your Gizmo is technically feasible, in which case you are ready to move to Phase 1, requirements and planning.

REQUIREMENTS AND PLANNING – PHASE 1

To communicate your vision to a partner, you will need a product requirements document (PRD) to define the product’s purpose, features, and capabilities. The temptation is to compile an al-encompassing “wish list”, but your zeal to create a ground-breaking product must be balanced by your finite budget and the necessity to make compromises early. While it’s terrific to believe that your team can accomplish what seems impossible, be careful that your requirements don’t, for example, defy the laws of physics. In short, every requirement will add cost to the development, and you will at some point have to determine if you really want to pay for that requirement.

Along with writing appropriate requirements, you must fill in details to your plan in Phase 1. The detailed project plan forces you to consider dependencies, and how the project milestones interact with other company objectives, such as exhibiting at a trade show or raising the next round of investment.

This is also the time to consider New Product Introduction (NPI) requirements, which will define the process whereby a product is transferred to production. The alternative to project planning is to simply figure things out as you go and “fail fast.” This attitude almost sounds like the startup’s objective is to fail repeatedly. Instead, you should employ the right amount of planning so you can “take your best shot,” understanding that you will still make mistakes along the way, and will need to recover from them quickly to survive.

EXAMPLES OF POOR REQUIREMENTS

Keep in mind that a set of requirements is usually tied to a specific prototype build. Requirements for a minimum viable product (MVP) will naturally be less stringent than for the final, mass-produced product. Learning to write good requirements takes practice. Requirements should be specific, measurable, attainable, realistic, and timely (SMART). Below are examples of actual requirements we have seen that do not measure up to the SMART standard, as they do not make clear the desired outcome.

1. “Gizmo must be easy to use.”

This is a classic unmeasurable requirement. A product with ease of setup and use is wonderful; it will make a difference for early adoption of your product and allow you to have more distribution options. As written, however, the requirement is impossible to verify. If you are serious about usability, you will need to recruit users to test your prototype. To gather metrics around usability, you could measure the time it takes a tester to complete a given task or ask the tester to fill out a short survey. Base your requirements around quantifiable measures. From observing as few as 5 – 8 testers, you should get a feel for whether your product is working as intended.

2. “Ensure robustness of Gizmo.”

Robustness is another desirable quality in a product, but this requirement is not measurable as stated. Instead, consider quantifying robustness by subjecting your product to drop tests, life tests, and environmental tests and specifying at which conditions it is allowed to break. These requirements may be limited in early prototypes but will become increasingly important as the design matures.

3. “The Gizmo should be IP67.”

This could be a well-written requirement, or it might not be realistic, depending on the context. IP (or Ingress

Protection) ratings are used to define levels of sealing effectiveness against moisture and other contaminants. The “6” means that there is no dust ingress under a test duration up to 8 hours. The “7” means that there is no water ingress when the device is submerged at a depth up to 1 meter for 30 minutes. Clearly, designing for and verifying an IP67 rate is an expensive undertaking that might be appropriate for a new wrist-worn electronic device, but unnecessary for an electric kitchen appliance. Only select the rating that you truly need, since the stricter a requirement is, the more it will cost to design the product to meet it.

4. “When the user presses the button, the Gizmo should immediately turn on.”

Another requirement that is not specific and not measurable. Indeterminate measures such as “immediately” (or “fast” or “always”) cannot be verified and should be replaced with specific values, such as 50 milliseconds.

5. “Accuracy of Gizmo: 100%”

This requirement is not measurable and not attainable. Accuracy refers to the closeness of a measured value to a known value, and is usually reported in applicable units of length, weight, etc. Although the inclusion of a quantitative statement gives the appearance of legitimacy, this requirement is equivalent to writing, “the product will always work perfectly.” Flawless function over an undefined time is highly improbable. A better approach would be to create requirements with permissible error rates, such as “Length must be 10 ± 0.5mm.”

ITERATIVE, DETAILED DESIGN – PHASE 2

With the requirements and project plan defined (they will keep evolving) begins the iterative process of “design – build – test.” The number of iterations and duration of each cycle depend on the complexity of the product and factors such as available resources and funding. It is important to realize that the team will need two or three iterations of the full design to really dial in the design. You should use each iteration of your prototype to get more user feedback and help achieve your company milestones. That could mean launching your pre-order campaign, landing a deal with an early launch partner, or raising capital. In this context, it’s useful to briefly examine the product validation stages.

The first major design – build – test cycle is Phase 2A, which results in proof-of-concept prototypes. The purpose of Phase 2A is to identify the greatest risks to success and eliminate them. One typical activity at this stage would be to take a systems approach, describing the product architecture in a way that accounts for interplay between mechanical, electrical, and software/firmware elements. Another activity would be to breadboard a high-risk subsystem with 3D-printed parts and off-the-shelf chip development boards, if possible. Results are presented with a description of the pros, cons, and key tradeoffs for each scenario.

Assuming that the architecture is set and design reasonably de-risked, the engineering team then begins the detailed design work of Phase 2B. This is typically the largest effort in the product development process, where the specific implementation for all relevant disciplines occurs. You will be getting input and introductions from your advisors and product development partner regarding sourcing the most appropriate contract manufacturing partner.

At the conclusion of Phase 2B – or Phase 2C or 2D, depending on product complexity – engineering will have produced a design that it believes satisfies the PRD. New iterations of mechanical hardware have been built, predominantly using rapid prototyping methods, but also considering design for manufacturing (DFM). A custom printed circuit board (PCB) will likely have been designed, leveraging learnings from the earlier breadboard. The assembled board (PCBA or PCA) will reflect best practices for electromagnetic interference (EMI) but is not yet expected to pass any regulatory tests. Another good practice for products with radio frequency (RF) components is the FCC pre-scan, a great way to reduce the risk of failing tests down the road that would delay FCC certification. Additionally, preliminary firmware will have been written and released. While not production-grade yet, the firmware has already been thoroughly tested and contains the framework for additional features, if needed. The project cannot exit Phase 2 (Detailed Design) until testing confirms that every functional requirement is met. If a test fails, engineering must adjust and refine the design, then retrofit the prototypes until they do pass the tests.

DESIGN VERIFICATION AND TRANSFER – PHASE 3

As exciting it is to see the first serious attempt at a Gizmo coming together during Phase 2, you as the entrepreneur must think several steps ahead. You might want to bring on someone with operations and supply chain expertise, either as a full-time employee or a consultant. In addition to keeping your eye on the cost of the full bill of materials (BOM) and considering build options, you need to get estimates for tooling costs. “Tooled parts” contrast with rapid-prototyped parts in that they are made using mass production technologies. Whereas a plastic part might be 3D-printed early in Phase 2, it is likely going to be injection molded in a later build. Tooling is a major expense, usually hundreds of thousands of dollars, and has long lead times, typically 8 – 10 weeks. Your operations lead should gather quotes and ask qualifying questions of potential suppliers.

Phase 3 will include an important build, because design validation and testing will signal the transition from your product development partner to the CM. Typically, the Phase 3 prototypes will be produced in limited quantities, using mostly tooled parts, and assembled at the CM. The molds and other tools may have to be adjusted slightly to make sure the assembly comes together and functions as intended. At this stage, the objective is to ensure that these Gizmos will satisfy additional non-functional requirements pertaining to appearance, usability, and robustness. Extensive testing will reveal how the Gizmos perform when dropped from a certain height, exposed to extreme temperatures, submerged in water, and more. You must also pay attention to applicable certifications such as FCC and UL.

PRODUCTION

The hand-off from the product development partner’s NPI team to the CM takes time and effort. Throughout Phase 3 and into Production, a strong NPI team can assist the CM with important tasks such as supporting process validation, tracking unit builds, reviewing manufacturing schedule and budget, and verifying quality metrics. To avoid problems later, your startup will want to retain control of the intellectual property that the production development partner generated for you. For tracking, you should have an internal revision control process in place that outlines what was changed, when it was changed, and why. There should be an agreed-upon documentation change and release process that you know and agree to. Good documentation is crucial, and all parties share responsibility.

The last iteration will finally take the Gizmos to Production. The contract manufacturer will set up a pilot production line to check for failures at any stage of the process. The assembly of the product will also be optimized to make the process as smooth and reliable as possible. Additionally, factory testing will be established to make sure that defective boards or assemblies are removed prior to shipping. The product development partner might be engaged to design and build test fixtures, create special test versions of the firmware, and continue to monitor quality metrics.

LAUNCH

At long last, the day has come when your Gizmos are assembled, tested, packaged, and shipped to excited customers. This is the culmination of many months or even years of hard work. You are grateful for the support you received from your team, your advisors, your product development and manufacturing partners, your Beta testers, and of course your family. It also feels good to prove the naysayers wrong, most notably the little voice inside your head that kept telling you to quit. Investors kept pushing for revenue, people who ordered Gizmos during the pre-launch campaign got impatient, your own team threatened to quit. Through it all, you hired the talent you needed, raised the rounds that kept the venture afloat, contracted the right product development and manufacturing partners, talked to users often, kept updating the plan, and didn’t cut corners. A couple times along the way you even paused to reflect. The resulting clarity helped you make important decisions that ensured the success of the Gizmo. Clarity also allowed a brand-new idea to take shape in your mind. You call it the Thingamajig, and it’s going to be revolutionary.

Download a copy of our white paper: