Ben Einstein goes through the process for a relatively simple product. This is a good study how his company Bolt, has a process for product development. Is his process perfect? No, I would approach things a little differently, but his techniques certainly lay out how a well developed process works. In my experience, no matter how good you are, always have your hair fire extinguisher ready.
Building a product that customers love is often the difference between a $1B company and bankruptcy. But with the cost and time requirements of the hardware world, startups really only get one chance to ship a product. Failure and iteration isn’t an option like it is for software startups.
If building a great product is so important, why do most hardware startups we talk to reject any sort of process for product development?
This series of posts is designed to shed light on what a good hardware startup development process looks like.
Yes, You Have a Process
Startups seem to have an allergic reaction to anything that imposes order. Yet, most software startups have vocally supported adopting the Lean Startup process popularized by Eric Ries:
The build-measure-learn loop has become engrained in the software startup culture but is incomplete for hardware startups. Most hardware startups embrace a product development process that looks something like this:
Most startups think the hair-on-fire methodology is faster because it’s “less overhead” but in the long run this couldn’t be further from the truth.
Hardware product development requires more planning than software development. This is driven by the sheer number of things that must be done right before shipping a connected hardware product. Many of these things have long lead times and high costs if done improperly. A tiny mistake in design or a poorly QC’d part can bankrupt you.
I think that he’s overstating the case just a little bit. He does have a point, but if you are careful you can plan for the issues that come up. I’m going to skip over the description of how his process works and deal with it at the end. Let’s go to the meat of part one, taking the idea and thinking it out. .
Nearly every company starts with an “ah ha” moment — an anecdote connecting the founder’s experience to the problem they’re solving. For DipJar, that moment was in a coffee shop. While a student, Ryder would frequent the local Starbucks a few times a day and became friendly with the barista staff. One afternoon it was exceptionally busy and the staff looked miserable. “At least you’re collecting a lot of tips,” Ryder remarked. “Actually, no one tips anymore due to credit cards. We’d rather the store be empty.”
As Ryder talked to more people, he realized it wasn’t just baristas that were affected by the decrease in cash transactions. Ryder also talked to musicians (especially those performing on the street), service providers (like barbers), and charities (including Salvation Army and The Children’s Miracle Network, both early customers of DipJar).
He makes a good point about developing a good feel for the personas of your potential customers. It’s a good idea to go out and talk to people in your target market.
Good problem research usually follows this checklist:
- If it’s a B2B customer: you know which stakeholder at the company makes the decision, how they purchase products like yours, and why this is a “top 3” problem for them
- If it’s a consumer customer: you know what brands they identify with, which designated marketing areas they live in, and their purchasing habits
- You have research to support how much they would pay for your product
- You have a beachhead customer base defined and a total customer basesized
- If you plan on raising venture capital, you can demonstrate how these numbers equate to $100M of revenue within 5 years
If you can check off each of these items, you’re ready to begin to think about how to solve this problem.
One thing is that I don’t think you can separate your POC prototype from the design process, simply because one depends on the other. Another is that for nonworking prototypes presenting it into controlled environment is a good thing if it doesn’t actually work. Trade shows and whatnot are good for this.
Once you enter the design phase the earlier you can get the potential customer involved the better off you are.
A design mentor of mine once said “you can only learn how much your design sucks when you watch people use it.” One problem the DipJar team saw constantly (marked with the red arrow): users would put the credit card in backwards causing a failed swipe. It became clear that this was a primary design constraint.
Conversations during this phase of customer development (vs conversations during problem research):
- Have a detailed script and stick to it as much as possible
- Take detailed notes and/or recordings
- Track NPS if possible (many companies prefer to do this later in the development process and that’s okay)
- B2C: Allow users to play with the product (when you’re ready) without explaining or setting them up for it.
- Don’t ask what customers would change; observe how they use it
On thing is that he moves some irrelevancies way up in the process. You don’s start talking about packaging and shipping until you know what the design is going to look like.
Storyboarding is designed to force founders to think through the entire product journey. Storyboards often depict:
- Packaging— what does your packaging look like? How do you communicate what your product is in 9 words or less (average box area)? How big is your box? Where does it go in a store/shelf?
- Sales— where is your product sold and how to people interact with it prior to purchase? Are there interactive displays? Do customers learn a lot about your product prior to buying it or is it more of an impulse buy?
- Unboxing— what is the experience of opening the box? It should be simple, obvious, and require minimal effort.
- Setup— what steps does a customer go through to get your product ready for first use? What is required besides accessories you’ve included in the box? What happens if it doesn’t work (i.e. can’t create a wifi connection or smartphone app doesn’t install)?
- First use — what does the product do to ensure users get comfortable quickly with your product? What have you designed into the product to delight your customers?
- Repeated use or special use cases— how do you ensure users continually come back to your product and enjoy their experience? Are there special use cases your product may get into: loss of connection/service, firmware updates, a missing accessory, etc?
- Customer support — when users have a problem, what do they do? If they’re sent a replacement device, how does that transaction/setup occur?
- End-of-life— most products are retired after 18 or 24 months. How does this fit into your buyer’s journey? Do you expect users to purchase another one? How do they transition from one product to the next?
I can’t argue with this.
The engineering specification (or product design/requirements specification, often “spec”) is a critical document in the creation of every hardware product. While many startups believe documentation of any kind is overhead and unnecessary I’ve seen companies waste months and tens of thousands of dollars by not thinking through their spec rigorously.
A spec sheet is where you set your goals. It will evolve as the design and development process proceeds, but it’s the framework that defines the work.
Most products can be defined by seven core areas:
- Commercials and regulatory — countries of sale and MSRP, regulatory requirements, acceptable margin structure, timeline for product refresh (EOL)
- Hardware and sensors — diagram of entire hardware system, list of major BOM components, requirements of sensors
- Electronics— size of PCB, amount of memory, requirements of processor(s) and radio(s), size/life/chemistry of battery
- Firmware and libraries— operating system or embedded environment used by firmware, API specification, external libraries required
- Software and web— software stack and environment for development, server infrastructure requirements, SCM plans, error states
- Durability and packaging— lifetime requirements, cycles of various sub-systems, packaging requirements
- Environmental and service— operating temperatures and humidities, descriptions of serviceability and returns process, customer support system and tolerances
There was a time when a product designer could only have to deal with mechanics, or casting, or electronics. Nowadays all those thing come into play for almost anything.
Having access to a good shop can save you a fortune in development time. Even if the final parts as going to be molded, being able to make machined prototypes right on the spot can be a real time and life saver. Einstein mentions how long it took what appears to be fairly simple part right and I have to think that one issue was farming the part out with the lead times that go with that. when you start planning for the development time, take lead times for your vendors into account.
If you get to this point and your design and engineering people haven’t been talking to each other, you may catch your hair on fire.
The engineering prototype (commonly known as an “EP” or “proto”) is the first point in the development cycle where design and engineering meet….
Merging these two prototypes can be challenging and often requires sacrifices on both sides. The engineering prototype process should conclude with:
- 5 or fewer units (often 1 is enough)
- No tooling and limited cost optimizations. It’s okay if unit cost is extremely high (often >10x of the production version)
- A “database” (or full list of parts and model files) that is ready to send to contract manufactures for quotes (RFQ)
Often this is the best time to raise money from investors. The EP represents the single largest step function in the product development process. For B2B/enterprise businesses: the EP is often good enough to begin selling. Because sales cycles tend to be longer, demoing an EP with a promise to deliver a production version in a few months is reasonable.
Up to 80% of engineer and design time can happen in the last 20% of work. The earlier you get manufacturing and vendors in line and costs down the lower your chances of having a truly expensive screwup are. Looking at the picture, the things called out for DFM are the sort of things that should have been in the design right form the start. This is where brining in manufacturing and your vendors as part of the design review pays off.
Still you are not done yet.
The engineering validation test (or EVT) is the final test of core product engineering. The question being asked during an EVT build is “does my product cover the functional requirements of my specification?” Common parameters for the first EVT build:
- Typically 20–50 units
- First time the contract manufacturer is assembling units (so many things often go wrong)
- Built on tooling that hasn’t been finalized (often called “first shots”) so it’s common to have flashing, incorrect coloring, no texture, or even significant issues with part fit)
- Basic tests including power, thermal, and EMI
It’s not uncommon to do a second EVT build after changes have been made.
You may want to have two different contract manufacturers at this stage. One close to home that runs the first fab and then your overseas manufacturer for the long run. At his point minor issues can still screw you up and when you are borrowing money or have sales deadlines delays at this point get really expensive. Also having a vendor close to home can help in those small emergencies.
And then you do your final testing
The design validation test (or DVT) is the first time the production process is the primary focus. The core question of the DVT build is “does the product meet all possible requirements including cosmetic and environmental?” Common parameters in the DVT build:
- Typically 50–200 units
- Final validation test before making sellable units
- Optimizing for yield (percentage of products off the assembly line that work) and time (number of units made per day)
- DVT units go through a large battery of tests
It’s a good idea to find a good outside testing house and consult all the specs and regulations required. Of course if you haven’t been doing that all along, you’re probably screwed.
Once you get through all that, you build and ship. This is why hardware is hard.
The Let’s Build Series.