The Hardware Path

Why nobody can quote a new product up front

An accurate number on day one would be a guess. Here is what a good estimate looks like instead, and how to get one.

On this page
  1. What a real quote would require
  2. How large companies get good numbers
  3. The uncertainty curve
  4. What "plus or minus 20%" means
  5. How to get estimates that mean something
  6. What a good first engagement looks like

Every first conversation about a new product reaches the same question within a few minutes: what will it cost? The honest answer, at that point, is a range wide enough to sound evasive. It is not evasion. It is the only truthful answer available, and understanding why changes how the whole project should be planned.

What a real quote would require

To price a complete product, a firm would need to know every part, how each one will be made, how they go together, which design ideas will fail on the first attempt, how many rounds of changes the owner will ask for, which certifications apply, and what testing will find. At the start of a new product, none of that is known. Most of it cannot be known until something has been designed, built and tested.

So a firm number for the whole journey, given on day one, is one of three things:

  1. A guess, delivered with confidence.
  2. A padded guess, with enough margin to cover the unknowns, which means the owner pays for risk that may never materialize.
  3. A plan to bill the difference later, through change orders once the unknowns appear.

None of these is the owner's friend. The low quote is often the most dangerous of the three, because it is usually the one that assumed the least.

How large companies get good numbers

Established manufacturers do price new products with reasonable accuracy, and that makes the problem look solvable. The difference is history. A company that has made two hundred variations of a product has supplier relationships, parametric cost models, estimating staff, and a detailed record of what went wrong last time. A new idea from a new team has none of that. The accuracy comes from the record, not from a method a small firm is failing to use.

The uncertainty curve

The useful way to think about an estimate is as a band, not a number. Picture a chart with time along the bottom, marked by versions of the requirements document (v0.1, v0.2, … v1.0, v2.0). Up the side is how much is known, in three layers:

  • Rough guess. Placeholder numbers. Where every project begins.
  • Assumed. Numbers with reasons behind them, not yet tested.
  • Known. Measured, quoted, tested, or frozen by agreement.

A line rises through the layers as the project moves through its phases. Around the line is a shaded band: how far off the numbers could be. At the start, the band is very wide. At each phase gate it narrows, because the phase just completed turned some guesses into assumptions and some assumptions into facts.

Two things about the curve are easy to miss. The line describes the whole document; individual items can stay loose long after others are settled. And the revisions cluster early. A requirements document that changes every week during Feasibility is a sign the process is working, not a sign of chaos.

Key takeaway Development money buys down uncertainty. Each phase is paid for to replace a guess with a fact. An estimate that is precise before the facts exist is precise about the wrong thing.

What "plus or minus 20%" means

On a well-defined phase, with clear requirements and a bounded scope, an experienced firm can usually estimate within roughly plus or minus 20%. That is the best case, and it applies to a phase, not to the product. A Prototype phase estimated at the end of Proof of Concept, with a stable requirements document, can be that tight. A Prototype phase estimated from a napkin sketch cannot.

Early phases have much wider bands, and they should. A feasibility study that comes back with "the unit cost will be somewhere between $6 and $14" has done useful work: the band was $2 to $40 before.

How to get estimates that mean something

Write the requirements down first. A requirements document, even a rough one, is the single most effective tool for getting comparable quotes. When three firms price the same written list, the quotes describe the same product and the differences are informative. When three firms fill the gaps with their own assumptions, the quotes describe three different products and the comparison is meaningless. Project Initiation explains how the document is written.

Ask for a phase, not a product. "What would Feasibility cost, and what will it tell me?" is a question a firm can answer well. "What will the whole thing cost?" is not.

Ask for the range and the assumptions. An estimate given as "$18,000 to $26,000, assuming two build rounds and no custom electronics" is more trustworthy than "$20,000." The assumptions are where the risk lives, and they are what to compare across firms.

Ask what is excluded. Certification testing, tooling, shipping, and third-party costs are commonly left out. An estimate that lists its exclusions is being honest about its edges.

Expect the estimate to change at each gate. A firm that re-estimates the next phase at every gate is doing it right. One that holds a day-one number through the whole project is either padded or heading for a change order.

Common mistake Choosing a firm on the day-one quote. The quote measures how much the firm assumed, not how much the product will cost. Compare instead on the questions the firm asked, the assumptions it stated, and whether it offered a phased plan with gates.

What a good first engagement looks like

A sensible pattern, used by many firms in different forms: a short, fixed-price discovery phase that produces a requirements document and a rough plan, followed by hourly development against a phase estimate, re-estimated at each gate. The fixed-price start gives the owner a predictable first cost and a document that can be taken anywhere. The hourly development keeps the owner from paying for risk that does not materialize, in exchange for carrying the risk that does. The costs page goes into the hourly-versus-fixed tradeoff in more detail.

The question to carry into any first conversation is not "what will it cost?" It is "what is the next thing to find out, and what will finding it out cost?"

Try this (15 minutes) Write the product's five most important requirements as "The product shall…" sentences. Then write the three biggest things nobody knows yet. Those eight lines are enough to ask a firm for a feasibility estimate, and the estimate will be worth something.

Wayne Weber

Mechanical engineer, MBA. Product development and prototyping.

Mechanical engineer with an MBA, working in product development and prototyping. Questions about anything on this page are welcome by email. Answers are informal, come as time allows, and nothing is for sale.