Hey Friends,
Today we deep dive into zero to one, business concept to technical execution framework for developing physical products.
1. The Problem
During my time in the physical product development space I was surprised to see how often teams lacked context to each other’s problems.
Whether it was product, supply chain, engineering, or business ops - teams were usually detached and misaligned. This problem wasn’t unique to these companies but is something which persists in physical product industries as a whole, more so than software because of longer development timelines, regulatory requirements, manufacturing limits, and physical constraints with scaling.
You simply can’t have all teams involved in a common forum regularly.
This problem is also compounded by instances of when searching how to make a hardware product online you come across articles which only focus on the engineering side (design, prototype, manufacturing) or MBA blogs on the business side (pricing, market, user personas).
This lack of overall context leads to product development with misinformed decision making. Lets look at some implications below.
Product Side Implications
Product Managers may spend hours defining vision, pricing, revenue, and product requirements but then lack awareness of the difficulty to execute on design, engineering, and manufacturing. This inability to gauge technical feasibility results in delays and non viable product scope.
Some examples:
An automotive car seat PM makes cost and material weight savings a hard requirement to satisfy a user persona but is unaware that the steel frame needs to be a minimum thickness to comply with frontal crash loading regulations and structural requirements.
An electronics PM makes revenue projections based on selling 300K units of cameras per year but does’t realize the manufacturing process is gated by a 15 micron particle lens cleanliness spec which makes it impossible to yield more units annually.
A smartphone PM is inspired by Apple’s AR/VR device and wants eye tracking features on their new headset but doesn’t realize their team lacks the expertise to architect the circuitry and processing for the required inward facing cameras.
Should be PMs be engineers? No, but mistakes in clearly defining product scope have non trivial implications.
Hard ramp deadlines and strict component sourcing life cycles even for prototypes make it necessary to align on holistic feasibility months and years before launch.
Engineering Side Implications
Engineers may spend hours on detailed design but lack context and awareness of why they are making that they are. What is the user problem that’s being fixed? Why is this feature important to the end customer? And so on. This inability to connect with business viability results in products which customers don’t want.
Some examples:
A part is cracked in production and the ME proposes an ML inspection machine to catch defects because manual visual inspection is subjective. While it’s innovative, this complex equipment spend will add to the per unit product cost, resulting in missing profit margins
The industrial design team at your AR/VR headset company loves premium materials and engineers love cutting edge machining. They come together to propose a headset out of glass and stainless steel. While this is aesthetically pleasing, the added weight is nightmare for end user ergonomics and comfort
An electrical engineer designing a new tablet chooses an advanced chipset to optimize device performance but these new power requirements make replacing batteries difficult for users and require costly repairs
What’s more unfortunate is that these engineers go on to make startups without knowing their target market and if the product solves genuine user problems.
Learning from mistakes is great but it’s not so fun when hardware development costs are so capital intensive. Just getting samples alone can cost thousands in tooling.
2. The Solution
The following is an attempt to document an overall hardware development process which is inspired by best practices from automotive and consumer electronics.
What I learned was that Tesla encouraged scrappiness while Apple was meticulous and calculated. While both philosophies were catered to each company’s maturity in the market, they followed a comparable high level process for bringing hardware products to market.
Keep in mind that build volumes and development timelines obviously vary by industry. In automotive a new product cycle usually takes 5 years from concept to launch, while consumer electronics is about 18 months.
This is assuming however your new product is a major model change on an existing product, not a new product category entirely. For example going from a Honda Civic 10th gen to an 11th gen or an Samsung galaxy s9 to s10.
New product categories require much longer development times, some up to 8-10 years. An example would be Apple Vision Pro.
Anyways, getting back to the framework, I’ve found the process below to balance speed while providing a path to development with systemic phase gates.
None of this is groundbreaking or new, just an attempt to organize and simplify the overall grand scheme of things.
3. Hardware Product Development Process Explained
Phase 1 - Concept
This is a rough ideation stage led by product managers which focuses on the what, why, and who of a new product
It usually start by understanding the industry (where’s it going, what’s the YoY growth, what are the trends), competitors (strengths and weaknesses of the big players), and market (Total addressable market and Serviceable addressable market)
The goal here is to find a sweet spot between company vision, market gaps, and user problems
Product Marketing Managers also help scope general pricing, revenue, and margin targets
This stage cumulates with a press release (PRFAQ) draft document which is an artifact that looks back from the customer experience to help articulate the vision for a new product
PRFAQs are basically a product business case and can take weeks to months to write. They’re supposed to create excitement but also balance that by answering difficult stakeholder questions (technical and financial). The how isn’t needed at this stage.
Phase 2 - Definition
The definition phase refines and details out the what, why and who of a product
This is where product managers are talking to customers, defining user problems, turning problems into stories, and those user stories into a set of crisp product requirements
The overall team is also working to cultivate an official business case, high level technical architecture, and manufacturing/supply chain risk assessments
This phase cumulates with a product requirements document which is an artifact that clearly conveys the attributes of your product
The key outcome in this phase is a dev commit from your entire team to start detailed design, engineering, marketing, sales, and supplier work
Its important to remember that product requirements are not engineering specifications. It seems obvious but this is important context which I, and many former engineers, missed early in our careers so I feel it’s important to highlight here.
Phase 3 - Development
This is the how. It’s where industrial design, mechanical, electrical, firmware, manufacturing, and supply chain teams take over to do their magic
The goal here is to go from concept to execution and it is undeniably the most difficult part of the product development process
Product teams use the development phase to gain key customer insights and validate assumptions through alpha and beta testing
Marketing, business ops, and sales are also busy here but for this article we’ll focus on engineering and product
The development phase is divided into sub phases or engineering builds shown below
Prototype (PT)
In PT Industrial design starts ideating on their shapes, colours, materials, and form factor concepts
Engineering teams test initial product architecture through bench top experiments, lab tests, & fit checks assuming proof of concepts made earlier were trending well
The goal is to validate the initial functionality of key features and not necessarily the entire system at once - not all modules need to be working at the same time
For example, you can have a new phone prototype where camera modules work but displays don’t at this stage
Supply chain and engineering also initiate supplier sourcing and capability studies
Engineering Validation Test (EVT)
Teams come back from prototype stage and really focus their efforts on detailed design to achieve specifications
The goal here is to validate the design and functionality of entire systems, not just modules like it was in the PT stage
These are lower volume builds with initial tooling, fixtures, and reliability testing
EVT cumulates with a “pencils down” which means design and engineering should, in theory, be locked
Design Validation Test (DVT)
At DVT teams usually produce engineering designs with different suppliers for the first time to help de-risk the supply chain
These are medium volume builds with higher throughput to refine and finalize tooling, test fixtures, and production processes
Teams also continue reliability testing & lock product quality specs
This is also where regulatory compliance (think FMVSS, FCC, etc) and certification testing is usually done, although sometimes it trickles into PVT
Production Validation Test (PVT) & MP (Mass Production)
This is the production ramp phase where you stress the assembly line to evaluate peak volume, max throughput, and process capability
Teams need to hit yield, quality, and capacity targets at scale but definitely need to be prepared for things to break and fast action
Ramp is often the litmus test of many engineering and process assumptions
PVT cumulates with “OK2ship” reviews which tell the org that your product is ready for launching to customers
Alpha User Testing
While EVT → PVT above focus on engineering development, there is user testing done in parallel to provide feedback loops on user experience
Led by product managers the alpha phase is typically the first time you can gain any user feedback of a semi mature product and it typically coincides with EVT
Its conducted with employees, versus actual customers, who are more forgiving and can provide feedback to engineering on usability and defects
Beta User Testing:
This coincides with DVT and PVT as the product matures
The goal here is to validate real-world customer usage flows and get more robust feedback
Responses from users here are more unbiased as customers obviously have lower tolerance for issues vs employees in the alpha stage
This requires detailed scoping from the product manager including a systemized experimentation plan, confidentiality clauses, and more
Remember this is hardware development so you need your contract manufacturer to ship actual finished goods to customers. These quantities need to be accounted for when planning build volumes
Do not rely on just a landing page or video to assume user feedback. Customers need to feel, interact with, wear, and physically test your product
Phase 4 - Launch & Post Launch
This is it. Your customers can finally get their hands on your product
Some key items which need to be ticked off from product teams are execution of marketing/coms, having onboarding and post purchase processes, return SOPs, customer support mechanisms, and distribution channel readiness
From the product side teams need to be vigilantly monitoring user satisfaction metrics, reviews, social media posts, and overall user feedback
From the technical side engineers should be prepared for FFA (field failure analysis) to address issues which slipped through development (for example, the iPhone 6 bend gate)
From a supply chain stand point inventory needs to be monitored to address demand
There’s alot which can still be said as each of these phases needs to have separate articles given the nuances.
Of course while there’s no one cookie cutter approach, I feel that this was a relatively sufficient introduction to the hardware product development process. Let me know your thoughts!
Hi. This is great, thanks for sharing. Where in the process do you allow for R&D activities?
What a great overview. We are currently building up our product development process, this ressource helps a great deal. Do you have any recommendations for tools that help manage this process? We are currently looking at Asana.