Built a prototype? Ask these questions before you go any further.

A working prototype can create more confidence than the project has earned.

You have proved that the technical approach is viable. The sensor reads correctly, the radio communicates, the software responds, or the control system performs the function you set out to demonstrate.

That is a real achievement. It is also only one stage in a much longer process.

A prototype will often concentrate on the most uncertain part of the design. It may prove the highest technical risk while leaving questions about reliability, compliance, manufacturing, servicing and field performance unanswered.

Before you move towards production, I would work through the following questions. They will help you establish what you have proved, where the remaining risks sit and what needs to happen before the product is ready to sell.

Here is what you have actually proved

1. What specific technical question was the prototype built to answer?

Start with its original purpose. Was it designed to prove a radio range, a sensing method, a power budget or a control principle?

This prevents you from using evidence gathered for one narrow purpose to support decisions about the whole product.

2. Which product requirements has the prototype validated?

Map the prototype results back to the requirements. Be precise.

A successful demonstration might validate a function, but it may not prove performance across different users, environments or operating conditions. Knowing exactly what has passed gives the next phase a firm starting point.

3. Which requirements remain untested or based on assumptions?

Unproven requirements do not disappear because the prototype worked.

List them openly. This allows you to decide which assumptions are low risk and which ones could force a redesign if they turn out to be wrong.

4. Have all the relevant teams contributed to the requirements?

Engineering rarely holds the whole picture. Marketing may understand the customer proposition, while service teams know what a replacement must look like in the field. Manufacturing and operations will bring another set of constraints.

Bringing those views together now can prevent a late requirement from invalidating the design.

5. Has anything changed since the requirements were agreed?

Products develop inside moving businesses. The intended market may have changed, a customer may have introduced a new condition, or the commercial model may now depend on a different service life.

A short requirements review can expose changes before they become expensive engineering problems.

Here is how you establish whether it can become a product

6. Does the system architecture support the complete product?

A prototype architecture may have been chosen for speed. The finished product has to support the full set of functions, interfaces, updates and operating conditions.

Reviewing the architecture now helps you avoid building more development work on a temporary technical decision.

7. Who owns the interfaces between each part of the system?

Hardware, firmware, software, cloud services and connectivity all affect one another.

When several suppliers or teams are involved, gaps often appear at the interfaces. Clear ownership means someone is responsible for how each part exchanges data, handles failure and responds to change.

8. Have the physical constraints been confirmed?

Connector positions, board dimensions, mounting points, cable routes and enclosure space can dictate large parts of the electronics design.

A late change to any of them may force you to move components, redesign the board and repeat the prototype. Confirming them early protects the work already completed.

9. Will the product survive its operating environment?

The bench is usually kinder than the field.

Temperature, humidity, water, dust, shock and vibration can affect component life, signal quality and mechanical integrity. Environmental testing shows whether the design will continue working outside the controlled conditions used during development.

10. Has the design been assessed against its operating life and duty cycle?

A product that works for an hour may behave differently when it runs continuously, wakes thousands of times or carries repeated peak loads.

This question helps you identify wear, heat and power issues before customers begin finding them for you.

Here is how you test the technical assumptions

11. What will the real power consumption be?

Measure consumption during normal operation, peak activity, sleep and poor communication conditions.

Average figures can hide short periods of heavy demand. Those peaks may affect battery choice, power-supply design, heat generation and the reliability of the whole system.

12. Will the power source support the required service interval?

Battery life is a commercial issue as well as an engineering one.

If customers expect five years between service visits and the design delivers two, the cost of replacing batteries may undermine the product case. Establish the service requirement before finalising the power system.

13. What happens when communications are weak or unavailable?

Connected products need a defined response to lost signal, interrupted data and unavailable cloud services.

You may need local storage, retries, alerts or a safe operating mode. Making those decisions now prevents intermittent connectivity from becoming an intermittent product failure.

14. What data needs to be captured and transmitted?

More data creates demands on power, storage, bandwidth and cloud costs.

Start with the decisions the data must support. That gives you a reasoned basis for deciding what to collect, how often to send it and how long to retain it.

15. How will firmware and software updates be managed?

A product may remain in service for years. During that time, you may need to fix faults, update security or change functionality.

You need a reliable update method, version control and a recovery process if an update fails. Retrofitting this capability after deployment is rarely straightforward.

Here is how you prepare for failure, testing and compliance

16. What diagnostics will be available in the field?

When a product fails, the support team needs enough information to understand what happened.

Logs, error codes and remote diagnostics can reduce unnecessary returns and site visits. They also help engineering teams distinguish isolated faults from a wider design issue.

17. What are the likely failure modes?

Look at how the product could fail, what causes each failure and what happens next.

The design may need to shut down safely, preserve data or continue in a reduced mode. Thinking through these conditions reduces the chance of a minor fault causing a much larger operational problem.

18. What testing still needs to be completed?

Functional testing is only part of the evidence.

You may still need regression, environmental, reliability, endurance and field testing. Defining the test plan gives the team a shared view of what must be demonstrated before the next project gate.

19. Which standards and certification requirements apply?

Compliance work can affect the circuit design, enclosure, power supply, components and documentation.

Identifying the requirements early allows you to design towards them. Discovering them after the product has been finalised may lead to retesting, component changes or another board revision.

20. Could future design changes affect compliance?

A product does not retain its compliance position regardless of what you change.

Replacing a component, altering the layout or changing the enclosure may affect electromagnetic compatibility, safety or radio performance. The change process needs to consider whether further testing will be required.

Here is how you protect the commercial case

21. Are the selected components available for the expected production life?

Prototype components may be available today but unsuitable for a product that needs to remain in production for several years.

Check lead times, lifecycle status and alternative parts. This reduces the risk of redesigning the product because a single component becomes difficult or impossible to source.

22. Can the product be manufactured consistently?

A skilled engineer may be able to assemble a prototype that a production line cannot build reliably at volume.

Review tolerances, assembly steps, test access and repeatability with the manufacturer. Small changes at this stage can improve yield and reduce the cost of failures during production.

23. What production testing and traceability will be required?

Manufacturers need a clear method for proving that each unit works before it leaves the factory.

That may require test fixtures, calibration procedures, serial numbers and records of components or firmware versions. Planning this into the design is easier than adding it once manufacturing has started.

24. Can the product be installed, serviced and replaced economically?

The product has to work within the customer’s existing operation.

Check access, wiring, compatibility, tools, training and replacement procedures. A board that saves money in manufacture may create much larger costs if every replacement requires a new wiring loom or a lengthy site visit.

Here is what to do next

25. Should the project proceed, change direction or complete another targeted validation stage?

This is the decision the review should support.

You may have enough evidence to move into detailed design. You may need another prototype focused on a specific environmental, integration or manufacturing risk. You may also find that the commercial case needs to change before further development makes sense.

The answer should come from the evidence, not from the amount already spent or the enthusiasm created by the first successful demonstration.

A useful post-prototype review separates four things:

• what has been proved

• what remains assumed

• what could cause the greatest cost or delay

• what evidence is needed before the next commitment

That gives you a controlled way to move forward. It also helps you avoid the most expensive version of product development: discovering a missing requirement after the design, tooling, compliance work or customer commitments have already begun.

If your prototype has reached this stage, the next task is to test the assumptions around it before those assumptions become fixed in the product. An independent feasibility and risk review can help you decide which questions need answering first.