DEVICE PRODUCT DEVELOPMENT

Over the years I’ve worked on lots of device projects, usually of the “let’s commercialize this new technology” sort. Each project is different, but I think can be defined along the same 5 axes: urgency, team, cost, regulations, technology, volumes. In this essay I hold that, regardless of where along each axis a particular project falls, the roles needed are the same—though often one person must fill multiple roles. I’ll elaborate on each role in turn, but first I’ll describe each axis.

Axes

Urgency

Early in my career I thought everything had to be done “The Right Way”. I used to scoff when I would tear apart a device and see some nonsense; a solid piece of aluminum hollowed out save for one little fin, a mess of wires and glue, &c. A few years in I realized that sometimes something shitty that ships is better than something better that doesn’t. Of course no one, least of all designers and engineers, wants to ship something bad. Nevertheless, circumstances intervene and it can sometimes be the right, distasteful, call.

Team

Solo projects are deeply different than 2-man projects. 10-man projects are different yet again. More people means more horsepower, but it also means more communication overhead. Somewhere around 5-10 people it makes sense to have someone whose only job is to coordinate.

Experience matters too. A team of senior people tackling a familiar problem is different than that same team tackling a new problem or a bunch of new grads tackling anything. Much of a good coordinators job is checking in with the right people in the right way at the right time. Very tricfky.

Market: Cost

Market: Regulations

Technology

Volumes

But one thing is common: the devices exist to generate data. Sensors collect it, firmware processes it, algorithms interpret it, software displays it. Everything else—the enclosure, the battery, the regulatory filings—exists to support that data pipeline.

So I want to generalize what I can about these projects through the lens of data. If a role is neglected or a phase is rushed, how does the data suffer? Wrong data, bad data, less data, no data.

Functional Roles

Every product needs these roles filled. Big companies have one or more people in each. Small teams double up—your ME might also do manufacturing, your EE might write algorithms. The possibilities depend on who you’ve got.

The common thread: if any role is neglected, your data suffers.

Management

Product Management (PM)

Owns the product vision. Sits between what the tech lead says is doable and what sales wants. Makes the hard calls about what the product is.

If neglected: you’ll build the wrong thing and collect the wrong data.

Technical Lead (TL)

Owns system performance. Sits between what the PM wants and what the engineering teams say is possible. Makes the hard calls about how to build it.

If neglected: you won’t collect any data because the thing won’t work.

Technical Program Manager (TPM)

Owns schedule, budget, and logistics. Sits between what PM and TL want to do and what the resources allow. Makes the hard calls about when and how much.

If neglected: you’ll run out of money or time before you collect any data.

Device

Industrial Design (ID)

Makes the device something people want to use—easy, attractive, intuitive. Works closely with ME and PM.

If neglected: people won’t use it (no data) or they’ll use it wrong (bad data).

Mechanical Engineering (ME)

Makes sure parts fit, sensors reach what they need to reach, nothing breaks, and it’s cheap enough to build. Works closely with ID and EE.

If neglected: the device costs too much (no data), breaks (bad data), or the sensors can’t do their job (bad data).

Electrical Engineering (EE)

Picks and configures the components—processing power, sensors, power management. Works closely with ME and FW.

If neglected: the device costs too much (no data), is unreliable (bad data), or has weak sensors (bad data).

Firmware (FW)

Writes the code running on the device. Works closely with EE, SW, and Algo. May also work with ID on device UI.

If neglected: the device is unreliable (less data, bad data).

Interface

Software (SW)

Generally peripheral to device engineering. The critical device-related work is the mobile app (with ID) and data infrastructure (with FW and Algo).

If neglected: data never makes it off the device, or it’s unusable when it does.

Algorithm (Algo)

Turns raw sensor data into a digital biomarker. Works closely with FW and SW.

If neglected: you have data but it doesn’t mean anything.

Overarching

New Product Introduction (NPI)

Gets the device built at scale. Works closely with ME, EE, and FW.

If neglected: the device ships late (less data) or costs too much (no data).

Quality Engineering (QE)

Makes sure regulatory requirements are met. Works across ME, EE, FW, and Algo.

If neglected: the device can’t ship (no data) or gets recalled (no data, plus lawyers).

Disciplines: A Closer Look

To build a device you need ME, EE, and FW at minimum. Here’s how FW teams typically work—the others follow similar patterns.

Firmware Team Structure

A firmware team has developers, testers, a lead, and sometimes its own TPM if the team gets big enough.

FW Lead: Sets the architecture, high-level design, and test strategy. Breaks the system down into chunks that developers can build and testers can verify.

Developers: Build chunks of the architecture in code and unit tests. Also build tools and libraries for testing (BLE stacks, debug interfaces, etc.).

Testers: Write test strategies and protocols. Run tests against system requirements. May build automated integration tests.

Methodology

Firmware teams usually run some flavor of agile/scrum. The basics:

Tasks: The smallest tracked unit of work. Estimated in hours or points, usually a few hours to 2-3 days of effort.

Features (Stories): A user-facing capability that takes multiple tasks to build. “As a user, I can see my battery level” might break into tasks for the fuel gauge driver, the BLE characteristic, and the mobile app display.

Sprints: A fixed time window (usually 2 weeks) where the team commits to finishing a set of features. At the end, you demo what you built.

The trap with agile in hardware-adjacent firmware: sprints assume you can ship at the end of each one. But firmware often can’t ship until the hardware exists. So you end up with a backlog of “done” features you can’t actually verify until boards arrive. Plan for this.

Phases

What follows is a progression of maturity stages for a device development project. Laid out like this, it looks clean and linear. It’s not. Use it as a guide, not a script.

Each phase has inputs (what you need to start), work (what each role does), and gates (what you need to move on). I’ve added notes on what usually goes wrong.

Initiation

The goal here is to decide whether this project should exist. You’re writing the business case and defining scope—not designing the product yet.

What usually goes wrong: Teams skip this and jump into design. Then six months later, someone asks “wait, why are we building this?” and nobody has a good answer.

Work

Business Case: Write down why this project is good for the organization. Include history and context. Be honest about risks.

Scope: Describe the high-level goals. Just as important: describe what’s explicitly not in scope. Adjacent features that seem obvious will creep in later if you don’t fence them off now.

Objectives: Describe each objective in detail. Ideally this feeds into an OKR scheme—see Measure What Matters.

Team: Early on you can get away with a tech lead and a few engineers. If the pace is fast, make sure you can scale to all the roles above.

Costs/Benefits: Salaries, capital expenditure, unit costs, opportunity costs. Get real numbers, not vibes.

Gates

Planning & Requirements

The goal here is to define the product, staff the team, and nail down requirements. You’re also sizing the market opportunity.

What usually goes wrong: Requirements stay vague because nobody wants to commit. “We’ll figure it out as we go” is fine for some things but deadly for hardware. Changing requirements after tooling starts is expensive.

Inputs

Work

PM:

TPM:

TL:

Gates

Architecture

The goal here is to find candidate end-to-end systems that could meet the requirements. You’re not picking one yet—you’re exploring options and understanding tradeoffs.

What usually goes wrong: Teams fall in love with the first architecture that seems to work. Then they discover a fatal flaw in PoC and have to start over. Explore at least two or three options here.

Inputs

Work

TPM:

TL:

ID:

ME:

EE:

FW:

Gates

Proof-of-Concept (PoC) Builds

The goal here is to build and test enough variants of high-risk interfaces that you can pick one design concept for each. A good rule of thumb: the concepts you pick should be no more than three major iterations from mass production.

What usually goes wrong: Teams build one PoC, it works, and they declare victory. Then in Alpha they discover the PoC only worked because of a lucky sample or a benchtop power supply. Build enough PoCs to understand the variance.

Inputs

Work

TPM:

ID:

ME:

EE:

FW:

Gates

Alpha Build

The Alpha (sometimes “E0” or “Proto”) is the first build in the intended form factor, or close to it. Mechanical parts are usually off-the-shelf, machined, or 3D-printed. A few might be tooled. EE boards are generally correct form factor.

Parts are built and tested in-house. The goal is enough confidence to start the RFQ process with contract manufacturers.

What usually goes wrong: The form factor introduces problems that didn’t exist on the benchtop. Thermal issues, antenna detuning, mechanical interference. Budget time to find and fix these.

Inputs

Work

TPM:

ID:

ME:

ME/EE:

EE:

FW:

Gates

Request for Quote (RFQ)

The goal here is to take the Alpha design and refine it for volume manufacturing. You’re selecting factories and getting real cost numbers.

What usually goes wrong: Teams lowball the RFQ to hit a cost target, then discover during EV that the factory cut corners to hit that price. Be realistic about what things cost. Cheap tools make expensive problems.

Inputs

Work

TPM:

ME:

ME/EE:

EE:

FW:

NPI:

Gates

Engineering Validation (EV) Build

This is usually the first build at the production factory. Parts are made with production processes. Assembly includes required test stations.

What usually goes wrong: Everything. This is where you find out what the factory actually understood vs. what you thought you communicated. Expect yield problems, test escapes, and long debugging sessions. Budget for multiple trips to the factory.

Inputs

Work

TPM:

ID:

ME:

ME/EE:

EE:

FW:

NPI:

Gates

Design Validation (DV) Build

The goal here is to build the validated form-factor design in volume and fix any remaining design issues. Process issues come later.

What usually goes wrong: Teams assume EV fixed everything. It didn’t. DV will surface corner cases—units that passed line test but fail in the field, reliability failures that only show up at volume. Keep engineering engaged.

Inputs

Work

TPM:

ID:

ME/EE:

EE:

FW:

NPI:

Gates

Process Validation (PV) Build

The goal here is to build the validated DV design in high volume and fix any process and capacity issues. The design is frozen—you’re tuning the line.

What usually goes wrong: The line runs fine at 100 units/day but falls apart at 1000. Bottlenecks appear. Test stations become the constraint. Operators make mistakes the automation didn’t anticipate. This is why you do PV before MP.

Inputs

Work

TPM:

ID:

ME/EE:

EE:

FW:

NPI:

Gates

Mass Production (MP)

You made it. The design is frozen, the process is validated, and units are shipping. Now the work shifts to monitoring, cost reduction, and field support.

What usually goes wrong: Teams declare victory and move on to the next project. Then field returns start coming in, and nobody’s watching. Keep someone on MP monitoring—line yields, reliability data, field return rates. Problems caught early are cheap to fix.

Inputs

Work

TPM:

ME/EE:

FW:

NPI:

Gates

What’s Missing

This doc is still incomplete. I haven’t covered:

Maybe someday.