How to Scope a Hardware Product Before You Start Designing

Early product ideas often feel clearer than they really are because the creator has already spent a lot of time thinking about them. The problem is that much of that understanding may still exist as assumptions, rough sketches, reference images, or ideas that have never been properly articulated. Before jumping into design, it helps to translate that thinking into a clearer product brief so there is a shared understanding of what the product is supposed to achieve, who it is for, and what constraints will shape the development process.

Before designing anything, define the basics:

• What does the product need to do?
• Who will use it?
• Where will it be used?
• What are the important functional requirements?
• Are there target price points or production volumes?
• What constraints are already known?

You do not need a perfect specification. The aim is to create enough clarity that the project can be assessed against something concrete rather than a constantly moving idea.

Every early product concept contains unknowns, and some of those unknowns will have a much bigger impact on the project than others. A feature that sounds simple in principle might require a complex mechanism, specialist engineering, difficult sealing, electronics, compliance work, or an expensive manufacturing process. Identifying these questions early helps separate the parts of the concept that are relatively straightforward from the areas that are likely to need testing, specialist input, or deeper investigation before the project can progress confidently.

The useful question is:

What do we still not know?

The way a product is ultimately manufactured should influence how it is developed from the beginning. Materials, production volumes, assembly methods, tooling requirements and supplier capabilities can all have a major effect on the design direction. At the same time, the project itself needs to be broken into logical stages so that technical risk is resolved progressively rather than everything being designed at once. Thinking about development and manufacturing together helps create a more realistic path from early concept through to production.

A low-volume CNC-machined product has very different design constraints from something intended for injection moulding at scale.

At this stage, you should start forming a view of:

• likely materials
• manufacturing processes
• assembly method
• custom versus off-the-shelf components
• prototype strategy
• specialist input required
• possible testing or compliance requirements

From there, break the project into logical development stages.

A simple product might follow:

Definition → Concept → Prototype → DFM → Production

A more complex hardware product might include electrical development, firmware, EVT, DVT or specialist testing.

The point is not to follow a generic process. It is to understand what your particular product needs to resolve before moving forward.

Cost is one of the hardest things to understand at the beginning of a hardware project because so much of the design is still unresolved. Even so, it is useful to establish an early financial picture before significant development begins. This does not need to be a precise quote. The aim is to understand the likely scale of investment, where the major development expenses may sit, and which parts of the product are likely to drive unit cost. That information can influence design decisions long before supplier pricing becomes available.

Separate the project into areas such as:

• industrial design
• mechanical or electrical engineering
• prototyping
• specialist testing
• compliance
• tooling
• production samples
• supplier setup

It is also useful to create an early product cost model or indicative BOM. That might include major components, materials, manufacturing processes, assembly and tooling allowances. Some figures will still be broad estimates or TBC. That is fine.

The goal is not false precision. It is to identify the major cost drivers before you make expensive design decisions.

The purpose of product scoping is not to solve every problem before design starts. It is to reduce enough uncertainty that the next step becomes clearer and more deliberate. Once the likely development path, technical unknowns, specialist requirements and indicative costs are visible, it becomes much easier to decide what should happen first. In some cases that may be concept development, while in others it may make more sense to test one technical assumption, seek specialist advice, or revise the brief before committing further.

By the end, you should have a better understanding of:

• the likely development path
• major technical unknowns
• key risks
• specialist input required
• indicative development investment
• major product cost drivers
• what needs to be resolved before progressing

You might be ready to move into concept development. You might need to prove one technical feature first. Or you might need to revise part of the brief before committing further.

All of those are useful outcomes.

This is the thinking behind Idea to Action, Made Evident’s product development scoping service.

It is designed for founders and businesses who have already done some initial groundwork around their market, customer and competitive landscape, and are ready to treat the idea as a real development project.

The scope looks at the product from a practical design and manufacturing perspective and helps map out the likely development route, key technical considerations, indicative costs and, where appropriate, an early product cost model.

It is not a substitute for commercial validation, detailed engineering or supplier quotations. It is a way to leverage over a decade of product development experience to understand what it may actually take to develop the product before committing significant time and money.