DEVICE PRODUCT DEVELOPMENT

this doc is very much WIP and incomplete_. Notable TODOs:

- Identify items that are particularly collaborative between e.g. ID/ME, EE/FW
- Integrate an OKR framework into project manager role
- More cleanly define product manager and systemeng/techlead activities, right now lumped under project manager
- Break ME/EE stuff out into test/mfg where applicable
- Cleaner break between tech leads p
- Refactor Inputs to map to gates.
- Add algo info
- Add SQA
- Add Quality/Regulatory
- Define _all_ acronyms
- Add "usual problems" section
- etc
- test, regulatory, quality, biostats, hfe, ux
- clin ops
- clin science

Over the years I’ve worked on many development projects, usually of the “let’s commercialize this new technology” sort. No two are completely alike; the relationships between and skills of the team members, the sense of urgency, the market, and of course the product itself all vary from one project to the next.

The main thing common across all of them is that the devices exist to generate data. Since this is common, I want to generalize what I can about these projects through the lens of data.

Functional Roles

Throughout development of a product multiple roles must be filled. In large organizations there could be at least one person (often multiple) assigned to each of these roles. In smaller organizations individuals often take on multiple roles. For example a mechanical engineer may act as a manufacturing engineer or an electrical engineer may act as an algorithm engineer. The possibilities are as variable as the unique experiences of the team at your disposal.

If any of these roles are neglected. The data will suffer.

Management

Product Management (PM)

Responsible for the product vision. Balances what Technical Lead says is doable with what marketing/sales wants.

If neglected, you’ll collect the wrong data.

Technical Lead (TL)

Responsible for overall functional performance. Balances what Product Manager wants with what Industrial Design, Mechanical, Electrical, Firmware, Software says are possible.

If neglected, you won’t be able to collect any data.

Technical Program Manager (TPM)

Responsible for schedule, budget, and other logistics. Balances what Product Manager and Technical Lead want to do with the resources available.

Device

Industrial Design (ID)

Responsible for making the device something people want to use (usually means easy-to-use and attractive). Works closely with Mechanical and Product Management.

If neglected, peple won’t use your device (no data) or they’ll use it wrong (bad data)

MEchanical (ME)

Responsible for making sure parts fit together, sensors are well-packaged can reach what they need, move appropriately, don’t break, and are produced cost-effectively. Works closely with Industrial Design and Electrical.

If neglected the device will be too expensive (no data), unreliable (bad data), or get in the way of the sensors (bad data)

Electrical (EE)

Responsible for making sure the right combination of components are configured in such a way the device has the required “brainpower” and can sense the required phenomena. Works closely with Mechanical and Firmware

If neglected the device will be too expensive (no data), unreliable (bad data), or have poor sensors (bad data)

Firmware (FW)

Responsible for making sure the the code running on the device does what its supposed to do. Works closely with Electrical, Software, and Algorithm. May also work w/ ID re: on-device UI.

If neglected the device will be unreliable (less/bad data)

Interface

Software (SW)

Generally peripheral to device engineering. Most critical device-related responsibilities are the mobile app (works closely with ID) and data infrastructure (works closely with FW/Algo).

Algorithm (Algo)

Responsible for creating algorithms to turn the data from the sensors into a digital biomarker. Works closely with Firmware and Software

Overarching

New Product Introduction (NPI)

Responsible for getting the device built. Works closely with Mechanical, Electrical, and Firmware Engineering

If neglected the device will be too expensive (no data) and ship late (fewer data)

Quality Engineering (QE)

Responsible for ensuring that regulatory requirements are met. Works across with Mechanical, Electrical, Firmware, Algorithm.

Disciplines: A closer look

To engineer a device Mechanical, Electrical, and Firmware engineering are required. Their constitution varies slightly.

Also each may need their own TPM if the team gets large enough.

Firmware

Team Structure

A Firmware team comprises developers, testers, planners (TPM) and a FW lead

FW Lead

Sets the architecture, high-level design, and test strategy. Enables developres to break that architecture down into implementable and testable tasks.

Developers

Implement chunks of the architecture in code and unit tests. Also responsible for building tools/libraries for test development. (e.g. BLE)

Testers

Develop test strategies and protocols. Execute tests based on sysetm requirements. May also build automated integration tests.

Methodology

Its super common in Firmware to use an agile/scrum approach. It comprises the following elements.

Tasks

A “task” is the smallest piece of work that is tracked. Typically estimated in hours (sometimes ‘points’) they usually require from a few hours to 2-3 days of work.

Features (a.k.a. “Stories”)

Phases

What follows is a progression of the levels of maturity a device development project goes through, and the sorts of work that should be done by various roles. Laid out in this manner makes it look deceivingly clean and linear and so it is my hope that the reader uses it as a guide but resists the temptation to follow it too slavishly.

Initiation

Define Business Case

A good business case should provide history and context for support and should conclude that completion of the project is good for the organization.

Define Scope

Describe the high-level goals of the project. Also describe adjacent goals that are explicitly not in the project.

Define Objectives

Describe each objective in detail. Ideally this rolls right into an OKR scheme.

Define Stakeholders

Both internal and external.

Define team

If you’re early on you can get away with a tech lead and a few engineers to start. If the pace is quick you’ll want to make sure you have capability to scale to all the roles above.

Define costs/benefits

Planning & Requirements

Define the Product, Staffing, and Requirements. Also identify sizeable business opportunities

Inputs

Work

PM
TPM
TL

Gates

Architecture

Identify candidate end-to-end systems to meet requirements

Inputs

Work

TPM
TL
ID
ME
EE
FW

Gates

Proof-of-Concept (PoC) Builds

The goal of PoC is to build and test enough variants of high-risk interfaces that the team can downselect to one design concept for each. A good heuristic is Assuming that the concepts selected are no more than three major iterations from a mass-production design.

Inputs

Work

TPM
ID
ME
EE
FW

Gates

Alpha Build

The Alpha build (sometimes called “E0”, or “Proto”) is the first time the design is built in its intended Form-Factor, or at least very close to it. The mechanical parts are generally OTS, machined, or 3d-printed where possible. A few items might be tooled up. EE boards are generally in the correct form-factor as well.

The parts are built and tested in-house. The purpose is to gain enough confidence in the design to begin the RFQ process with contract manufacturers.

Depending on your quantity and manufacturing resources, you may be able to fold this and the first EV build into a single build.

Inputs

Work

TPM
ID
ME
ME/EE
EE
FW

Gates

Request For Quote (RFQ)

Take alpha design and refine it for volume manufacturing

Inputs

Work

TPM
ME
ME/EE
EE
FW
NPI

Gates

Engineering Validation (EV) Build

This is the usually the first build at the production factory. The parts are made with production processes and the assembly process includes required testing stations

Inputs

Work

TPM
ID
ME
ME/EE
EE
FW
NPI

Gates

Design Validation (DV) Build

Build validated form-factor design in high volume and refine to eliminate design issues

Inputs

Work

TPM
ID
ME/EE
EE
FW
NPI

Gates

Process Validation (PV) Build

Build validated DVT design in high volume to find associated process and capacity issues

Inputs

Work

TPM
ID
ME/EE
EE
FW
NPI

Gates

Mass Production (MP) Build

Build Validated PVT design in high volume to find associated process and _capacity issues

Inputs

Work

TPM
ME/EE
FW
NPI

Gates