How Much For One?

Heath Raftery -

As a product development engineer I frequently get asked to quote on creating new products. Everyone has a model for what a reasonable response is, but as an industry we don't do a particularly good job of guiding clients at this stage of the process. I'm no longer responsible for keeping a product development consultancy alive, so would like to use that freedom to make amends.

Note that this exclusively applies to physical products. There's a-whole-nother definition of engineering which isn't related to making things, but to writing software. This doesn't apply there, and it's important not to get the two confused.

So what does it cost to make a thing?

If you're engaging a product development engineer, that implicitly suggests the thing doesn't already exist. Providing something that already exists is a very different ballgame to creating something that doesn't. One of the first questions I like to ask new prospects is "does this already exist?". New product development is a big undertaking, and even a small product development project results in something that needs to be nurtured if it is going to remain production-ready. So it's important to be clear that the goal is something that is the first of its kind.

With those definitions out of the way, what then, does it cost to make a thing? Honestly, none of us really know. Being first of its kind means that the steps that get us there are yet to be defined. But we can estimate. After doing this many, many times, the most honest way I've found is based on Daniel Kahneman’s "Reference Class Forecasting" - that is, based on the average of all similar projects, and the fact that this one is a bit bigger here and a bit smaller here, it'll be on average x. I've worked on projects where x is anything from $2,000 to $2,000,000. And a couple outside that. So the devil is in the detail.

So what about just five of the things? Or 100 of them? Or just one? Or if I get someone else to do the first one, how much then?

This is where we need to be clear about where the costs go. Product development is almost always costed at an hourly rate. Sometimes that rate is hidden, and it's sold as a fixed price or "NRE" (non-recurring engineering) or a royalty deal or whatever. But at the end of the day the process of creating a new product is one of labour, and usually, some development materials.

So the cost per unit is typically huge for the first couple of units. All the development time and materials ultimately gives you zero units, until the first one is made. But because having physical artefacts is so crucial to the product development process, typically the goal is to produce one as soon as possible. That means it will be a high-touch unit. The cost to make it will be very high, because that is better than putting a lot of effort into optimistically making the build cheaper, and delaying the opportunity to learn what really needs to be built.

Okay then, much for the second unit?

Keep in mind that the goal of producing early articles is to accelerate the product development process. This is far more cost effective in the long run, than optimising the build process early (and skilled practitioners develop a fine balance). So if your product development engineer is looking after you, then the second unit will also be a high-touch unit. They will be maximising their opportunities to learn more about the design, removing issues that would otherwise cause a lot of pain down the road.

Typically the second unit has a lot of development labour baked into it too.

Okay, okay. So what is my tenth going to cost? And my hundredth?

At some point during development, the COGS (cost of goods sold) will become apparent. If COGS is critical to the viability of the product (which is common in consumer goods, and often less so otherwise) then pinning it down needs to be a development priority. An estimate can be developed early, and some boundaries can be set to guide further development. COGS is a matter of sourcing costs and manufacturing costs. Sourcing costs are a function of part selection and supply chain. Manufacturing costs are a sum of assembly and test. All four aspects are levers that can be adjusted during product development.

A critical aspect to note here is that if your product development engineer is paid by the hour, then it is in their best interest to reduce your COGS. It takes time and expertise to optimise those four levers, which is the engineer's bread and butter. But the result, the actual COGS, makes little difference to the engineer's bottom line.

On the other hand, if your manufacturer is doing your product development, you'll typically find the product development labour is discounted because there is margin in the COGS. In that case, there's not necessarily an inherent incentive to minimise COGS.

This is why it's useful to be both informed and clear about the cost target - the viability of your product is what matters, not what the engineer or factory gets paid. So make sure they're optimising for the right thing.

The cost of the tenth and the hundredth, then, depends on the process taken to get to the first. The worst case scenario is a first unit that barely answers questions about what the second looks like. It may take several more iterations to finalise the product, and the COGS might still be an issue. The best case scenario is that the first unit meets all requirements, and the path to stripping out the high-touch inefficiencies and achieving the target COGS is clear.

Usually it's somewhere in between. There's still some key learnings still to be capitalised on, but the COGS is not far off the estimates.

Cool story bro, but what's it going to cost?

Your product's COGS is the BOM (bill of materials) cost, plus the assembly (and test) cost. Plus any tariff, shipping and other logistics costs to get the thing to where it needs to go.

When your product development engineer buys the BOM for development purposes, they'll use fast turn suppliers. High volume parts like electronic components will come from the likes of DigiKey and Mouser. Low volume parts like mechanical enclosures will come from the likes of SendCutSend and local fabrication houses.

You can see for yourself. When you order 1 off from the likes of DigiKey it might cost 16c for a component. 10 off might be a quarter of that and 100 can be one-eighth. Mechanical parts often scale even more steeply. A 3D printed part might be cents to make, but wont provide all of the physical characteristics necessary to finalise a product. A machined prototype could be a high definition representation, and cost thousands of dollars per unit. While the mass produced part could be tens of thousands of dollars for the setup, and dollars per unit for the next 10,000 units.

That's the BOM costs. Meanwhile, the assembly and test costs are a function of labour. The more automation, the less labour. But introducing automation can be expensive. Your product development engineer will be looking to minimise the labour per unit, which is a delicate balance of streamlining the process and preventing escapes which require human intervention to resolve.

The early high-touch units will have labour everywhere - in assessing the correctness of the BOM; in the feeling out the reliability of the mounting points; in the touch-points required to program and test each unit.

Eventually, units will be built as low-touch as possible. Any minute that can't be stripped out of the process will cost you somewhere around $USD0.50. Plus or minus a fair bit, depending on where it is happening and their willingness to take or absorb a hit.

So any unit your product development engineer builds is likely to be very expensive and (if your engineer has your best interests in mind) very worthwhile. That because the units built by your product development engineer are for feedback, which is rolled back into development to provide you a desirable product. The better the feedback, the quicker you can ramp down your engineering costs.

tl;dr

At any point, you should be free to ask your product developers what the unit cost will be. They wont know for sure, until development is done. But if it's important, the development process must factor that in and you can get a good idea early.

The units built for the purposes of development though, are expensive. They have a concrete, but complex, relationship to the final build cost. The final build cost is: the BOM cost at a quantity discount + the assembly cost with as much manual labour stripped out as possible + testing and scrap costs with a dialled-in balance of coverage and yield + packaging, shipping and market entry costs particular to your product.

Here's how you can estimate it:

  • Get your product BOM. Find out the list price of every item, and then factor in a quantity discount. Bare PCBs are maybe $30 for a few, and about $1 each for 100+. Basic electric components are often 1/10th the single price in volume, and factories can often afford to purchase by the thousands. High-touch custom parts like cables don't usually attract as much of a discount. Low-touch custom parts like injection moulded plastic are very expensive to get going (tens of thousands of dollars) and then typically dollars per piece for every unit after that.
  • Get your product assembly and test procedure. Time how long it takes and assume somewhere around $1 per minute while your development team is getting the intern to do it, and $0.50 per minute once you convince a factory you'll order enough for them to set up a production line.
  • Add BOM and assembly together, and divide by yield. For the first couple of hundred units you might only achieve, say 80% yield. As the process is refined that might increase to 99% for a product with well established build practices.
  • Finally, add any packaging, warehousing, shipping and market entry costs you're responsible for to get the product where it needs to go. That's your COGS.

For example, if your product development engineer says that the BOM is currently $200 in singles, and it takes them about 30 minutes to assemble and test, then you might reasonably assume the first ten units are all going to cost $200 + $30 = $230 each. And maybe 60% of them survive the build process instead of turning into "learning experiences" like drop testing. There's also most likely a lot of engineering labour on top of that to carefully refine the product design based on the learnings from each unit.

After that you might find you can order 50 sets of the BOM at a 50% discount, and shave 10 minutes off the assembly time. If you're willing to go pick them up and walk them through customs in your hand luggage, they might only cost you $100 + $20 = $120 each.

If it's all green lights and you want 1000 more of the same, you could probably expect in most cases that your BOM will come down 80%, assembly labour drops to $0.50/minute, and the production line shaves another 10 minutes off the process. Units are now $40 + $5 = $45, with 95% or more yield. However, you may now need to factor in additional costs like packaging, warehousing, shipping and tariffs.

Here's an illustration of the numbers above, assuming $10k of product development costs to first unit, and about $18k to volume production. The take-away here is not the numbers per-se, but how engineering costs and the product development process itself are entwined with the first articles.

Notice how the bulk of the engineering spend comes before the first unit is built. As subsequent units are built the engineering labour required starts to ramp down and the product manufacturing process is refined. The two callouts highlight how the COGS (assembly plus BOM cost) starts high and approaches the target. Even though the COGS remains high for early units, it is still typically dwarfed by the engineering costs.

Excluded from this graph are the materials costs. General prototyping and development materials may not be significant compared to the engineering labour costs. However if your product requires tooling to mass manufacture custom parts cheaply, or sophisticated test fixtures to speed up assembly, there may be additional material costs involved to get to the final unit price.

Coda

Ultimately it's horses for courses. Even the typical figures I picked above are unlikely to be completely representative in most cases - there's a lot of scope for nuance. But the principles remain the same:

  • The cost of early units is heavily tied into the development process itself. It's usually unsafe to assume that after the first build, others will follow the same recipe. The first build is likely to be flawed, so repeating it just bakes in flaws.
  • Nonetheless, the COGS of a product is a key design criteria. Your product development engineer will be motivated to try to meet your target if they know it - there's usually no incentive to design a high cost product if a lower cost alternative is available.
  • An early estimate on COGS can be made, but it will come with a bucket of assumptions: that this particular display technology will be used; or that high volume manufacturing technique can be applied; or your favourite low cost vendor will come through with the goods. Flushing out these assumptions with early, high-cost builds, is part of the process.