Talking about product development budget(s) can be uncomfortable. It is common for new clients to try to avoid the topic entirely. Commonly, clients feel that if they tell us what their development budget is, that they are ‘showing their cards’, or putting themselves at a disadvantage early on in the relationship. We all want the best deal we can get, whether we are buying a house, a car, or professional development services.
But the budget question is also an important input into the development process.
For the purposes of discussion, let’s define “Budget” as the amount of money required to take a product from the concept stage through to manufacturing startup. Let’s include design, engineering, design iteration, prototyping, optimization for production, regulatory testing, documentation, and tooling purchase in this figure.
In the first or second conversation with businesses interested in having us help them, we bring up the question of the product development budget. Some businesses respond with a hard number, some respond with a dollars-per-month figure, and some respond by saying they want us to tell them what it will cost.
The last is a circular reference in this case since many things can drive actual development cost. These things include:
- The intended quality of the final product.
- Target production volume.
- Target production cost.
- Development time horizon.
- Target feature sets.
- The number of design iterations required during development.
- The level of programming required for the product (if electronics are involved).
- What regulatory work applies to the product category or application.
- Costs associated with testing.
The reason this can be a circular reference is that many of the items above can actually be tweaked depending on the development budget. For example:
- The intended quality of the final product: If development budgets are low, a lower level fit and finish, or ergonomic optimization can be applied to save development cost.
- Target production volume: If production volumes are uncertain, assuming lower volume can reduce development cost since the design for ease of assembly becomes less important, which means less development effort.
- Target production cost: In general driving product cost downward takes focused development effort and the development of more custom system elements. Low product cost comes at the expense of high development effort and may also require high production volume (driving tooling cost up).
- Development time horizon: Typically, an accelerated development timeline is costlier. To achieve faster development, multiple prototype iterations can happen in parallel, meaning the development team is larger. This can also include testing for each iteration.
- Target feature sets: Development budget often drives what features are feasible to include in a product.
- The number of design iterations required during development: Fewer development iterations can be executed, meaning overall product risk is higher as fewer things will be validated during development (this is typically not a good place to try to save money).
- The level of programming required for the product (if electronics are involved): If product features can be changed to reduce the amount of programming required, development budget can shrink.
- What regulatory work applies to the product category or application: A smaller development budget may mean only North American regulatory work is feasible, delaying an international product launch. This may then play into the target production volume question as well.
As you can see, if a product development budget is defined early on, the development team can identify a clear path to execution.
However, this also means there is a wide range of options for building a successful product while maintaining a budget.