Early-stage hardware companies usually understand the “how” of product development. Product management adds a layer of “why,” “what,” and “when” to the process.

Building hardware is complicated. Many founding teams going through product development for the first time struggle to manage that process on a day-to-day basis. Founders know they need to build a product and that there are many steps, but they might not be sure which steps come in which order, or what features and tests to prioritize. The goal of this blog post is to guide founders through this process of day-to-day product development, or what I call early-stage product management.

Early-Stage Product Management

Once startups raise enough capital to have 20 or 30 employees, nearly all companies hire a dedicated product manager. Before that, founders, CEOs and engineers have to handle product management themselves. The basic scope of product management for an early stage hardware startup typically includes five things:

1. Product Definition: interfacing with customers to determine what the product should be.
2. Documentation: developing user requirements and formalizing a specification for the product (usually via a Product Requirements Document).
3. Feature/Scope Management: deciding what features should be included in a given product release.
4. Prototype Management: prioritizing prototype builds and testing to ensure requirements are met.
5. Project Management: managing overall cost, quality, and schedules for the product.

#1 and #2 are covered extensively in the Illustrated Guide to Product Development series, which is a strategic approach to product development. The focus of this post is the last three parts of the product development process: the tactical side of product management.

Product management is not a mystery. You are, in fact, already doing it. You’re doing it all the time: It’s fundamental to the process of building anything that users will touch and hopefully love. Whether it’s a hastily-made Proof of Concept prototype or Apple’s next iPhone, product management is essential, and realizing you’re doing it will help you manage it better (and hopefully build a better product more cost-effectively).

Two Frameworks to Decide Why, What, and When

I find it helpful to think through product management via two frameworks: risk and schedule. Any given product/company can use either or both of these, but the output should be a timeline and budget for how to get your product into the hands of customers.

The Risk Framework

Startups are machines to reduce risk. One of the best frameworks for early product management is figuring out how to maximize risk-reduction as early and as cost-effectively as possible. What are all possible risks you face as a product/company? Here are some common categories/examples:

• Business risk — We can’t build the product for a low-enough price that users will happily pay.
• Technical risk — Standard GPS receivers will use too much power and won’t be accurate enough.
• Customer risk — Users won’t know how to set up the product without detailed explanation.
• Product risk — If the product doesn’t live up to consumer expectations, it creates significant liability for the consumer. More on the nuances of product risk here.

Most startups take hundreds of risks, but there are usually only a handful of “showstoppers” that result in disaster if they can’t be mitigated. Here’s how to prioritize which risks to focus on:

• Brainstorm all possible risks and then categorize them using two parameters: severity (how serious a risk it is) and addressability (how easy or difficult the risk is to mitigate). For example: A customer risk of not being able to set up the product is a very serious risk that can be addressed easily and cost-effectively with design. On the other hand, a technical risk of not being able to build a product that adheres to Apple’s iOS MFi Bluetooth rules is nearly impossible to mitigate.
• Capture your risks in a spreadsheet. One heuristic for figuring out “risk level,” or how much risk a given item can cause, is severity x number of people. You can have small risks that impact everyone, or larger risks that are serious but unlikely to happen. (example courtesy of Flare Jewelry, one of our portfolio companies with dummy data inserted to product the company’s IP)

• Early prototype builds (works-like and looks-like) should each be designed to mitigate one of these risks, working down the list from most to least severe. In the example above, Flare needed to ensure they could get a single button action of their physical device to quickly launch a mobile app on iOS and Android, without a negotiated Bluetooth connection. This was one of their first works-like builds (WL1) and the development board for reducing several other risks with new firmware builds (WL2, WL3, etc.).
• Once many major risks have been “tested away,” it’s time to integrate each separate build into a single prototype with an engineering prototype (EP1). The EP phase is much less deterministic; rather than binary “can it be done?,” as is common with WL builds, EPs are often a series of tradeoffs between design and engineering.
• The risk framework tends to become less useful after the EP builds. Attention turns towards manufacturing execution, where decisions are typically driven by cost, quality, and schedule.

The Schedule Framework

Time is also a driver of business decisions. A very common scenario we see in our portfolio is a sub-par version of a product being sold/demoed to customers, while the startup desperately works on the “final version,” to be delivered by a specific date. When this dynamic is at play with a company, it’s common to start with a firm delivery date and work backwards.

Tive, another Bolt portfolio company, is currently selling a product they’ve been hand-assembling in 100-unit batches for trial customers. They’re working on a totally new revision, with a new layout, interface, and business process, but same general function. Because there’s limited technical risk and lots of customer pressure, using the schedule-driven framework is a great option.

The founders and sales team have made a strategic decision to deliver production units of the new product by March 1, with the ability to cost-effectively make 1K unit runs for the subsequent twelve months. These strict requirements have some major effects:

• High-volume production manufacturing techniques must be used: injection molding, fully outsourced PCBA/bringup, heat staking, and ultrasonically welded clamshell housings.
• Contract manufacturing facility doing procurement, final assembly, QA/QC, and kitting (packing boxes and accessories).
• Consigned components and volume purchases (usually by the reel).
• Focus on low manual labor assembly and high yield, without manual rework.

With these requirements, we can start by laying out the Production Validation Test (PVT), Design Validation Test (DVT), and Engineering Validation Test (EVT) timeframes and steps:

Continuing to work backwards for Engineering Prototype (EP) builds (we’ll plan for an EP2 as a buffer):

We then have a good idea of how much time we can spend on looks-like (LL) prototypes:

And works-like (WL) prototypes:

The trickiest part of the schedule-driven framework is estimating time for each process and build, especially for first-time founders, who might lack a frame of reference. If that sounds like your near future, I suggest buying a copy of Manufacturing for Design Professionals to get a running start, and don’t underestimate the power of talking to folks who have gone through this process before.

No One Size Fits All

As with many other decisions around hardware development, there’s no single approach that works best for all startups. Worth noting: A great product development process is not a top-down management-driven way of working. For it to be adopted fully, it requires discussion and buy-in from the entire product, engineering, and design orgs within your company.

Companies that carefully plan their product development are much more likely to build products that people love — and are able to deliver them more or less on time and on budget. Proactively work with a product management framework that works for you and stick to it during the development process; it’ll have a tremendously positive effect on your company.

Ben Einstein was one of the founders of Bolt. You can find him on LinkedIn.