Part of a two-part series with Dr Chloe Sharp, Sharp Insights.
Every hardware prototype cycle takes months and serious capital, and every change touches tooling, components, certification, supply chains and manufacturing plans. The decisions about what gets built next matter more than most technical teams give them credit for.
A common reflex in technical teams is to treat the next expected TRL milestone as the next thing that should be built. Sometimes that is exactly right. More often it is not. A more advanced prototype is not necessarily a more useful one, and a prototype cycle can consume six months of runway without reducing the commercial uncertainty that made the last funding conversation hard.
The four decisions below are the ones I return to before every hardware build. Sharp Insights’ companion article looks at the wider commercialisation journey and the evidence founders need before committing further development, funding or commercial effort. This piece focuses on the physical product-development implications: how customer and commercial evidence should shape requirements, prototypes, field testing and the move towards manufacture.
1. Understanding demand: Whose problem should shape the product brief?
Product designers are trained to start with the user. In physical and regulated markets, the user is often only one voice in a much larger system.
An AgriTech device may be operated by a farmhand, specified by an agronomist, purchased by a farm manager, financed by a lender, and audited by an insurer or food producer. A retrofit system may involve the building owner, the facilities manager, the M&E consultant, the installer, the finance team and the planning authority. Each of them has a different definition of what makes the product valuable. The farmhand cares about speed. The agronomist cares about data quality. The insurer cares about the evidence trail.
The user wanting the product is not enough for the system to adopt it. The product brief has to reflect the requirements of everyone whose decision enables adoption, not just the person whose hands the product ends up in.
An illustrative example, drawn from patterns we’ve seen across a few AgriTech ventures. Take a device for taking crop samples: a premium, carefully engineered piece of kit, aimed at the farmer. At the farmer level, the problem was real, but it was a low-value, occasional annoyance – nowhere near enough to justify the device’s price. One layer up the supply chain, the same underlying problem was far more expensive where poor quality data has real financial consequences. Repositioned a layer up, the product found a customer who would actually pay for it. That kind of pivot only surfaces if the mapping goes wider than the user, before the brief is locked.
The practical test before locking the brief: who it’s for, who pays, and who needs it urgently enough to act now.
2. Defining the outcome: What outcome becomes the design requirement?
Founders often begin with a technical capability. The device detects something more accurately. The material is lighter. The sensor operates in conditions where existing products fail. Those capabilities matter, but they are rarely what the customer is buying. The customer is buying an operational, financial or strategic outcome. That outcome is usually something they’re already trying to achieve today, with or without your product – the job is to name it precisely.
The designer’s job is to translate that outcome into performance thresholds. Not “what would make this technically impressive” but “what performance threshold would change the customer’s decision”.
A nuance that matters especially in hardware: the user and the customer are often different people, and they define the outcome differently. The farmhand uses the sampling kit and wants speed. The farm manager signs the purchase order and wants yield decisions supported by better data. The bank holds the asset finance and wants defensible collateral. All three definitions need to be tested in each language. If the outcome only lands with the user and not the buyer, the product cannot be sold no matter how well it performs.
The requirement that lands in the design brief is often unrelated to the technical performance the team assumed was decisive. Customer payback, installation time, reliability, maintenance frequency, compatibility with existing equipment, training requirements, evidence for compliance, and speed of results are frequently more commercially consequential than another round of accuracy improvement in the core technology. Those become the requirements the next prototype has to meet.
3. Route to revenue: What is the minimum delivery mechanism needed to test value?
The instinctive hardware answer to “how do we test the value” is “build the product”. That is often wrong. The final physical delivery mechanism may be years away and expensive to iterate. The customer outcome the final product is meant to deliver may be testable through a much cheaper mechanism today.
Back to our previous illustrative example of the agritech venture. The final delivery mechanism is a robot in the field. That is six years and £500,000 away, with UKCA marking, manufacturing scale-up and field deployment all ahead. The immediate delivery mechanism is a lab-based service, using off-the-shelf hardware, on samples the customer ships in, that produces the same analytical report the eventual robot is meant to produce. Deliverable next quarter. The report is what the customer values. The report is what the robot is meant to deliver. The delivery mechanism looks nothing like the long-term product, but the outcome is the same, and whether customers pay for the report tells you whether the robot is worth building.
Software product development has language for this. The concierge MVP. The wizard-of-Oz prototype. Hardware does not yet have a common name for the equivalent, so the practice mostly does not happen. The forms it can take include service-wrapped delivery using borrowed or pre-production kit, manual back-ends standing in for eventual automation, off-the-shelf components stitched together, or human labour doing what an algorithm will eventually do. Regulation can impose a real floor through conformity assessment, certification, safety requirements or controlled testing. That floor does not remove the option of a service-wrapped equivalent. It changes its shape. Depending on the product and regulatory pathway, you may not be able to place an early device into normal customer use. But you may still be able to test the outcome through a controlled trial, supervised deployment or service-based alternative. What you can do is deliver the outcome in a form that sits outside the regulatory boundary until the evidence justifies crossing it.
The purpose of this move is not to replace the eventual product. It is to test the customer outcome before committing capital to the final physical delivery mechanism, and to let the evidence that comes out of that test shape the eventual design requirements.
4. Deciding what to build: What question must the next prototype answer?
This is the decision that matters most, and the one hardware teams most often skip.
Hardware teams tend to describe progress through the prototype itself. “We have built version three.” “We are moving from the lab prototype to a field prototype.” “We are developing a demonstration unit.” The problem is that a more advanced prototype is not necessarily a more useful one. A prototype should exist to answer a specific question. If the question is not defined before the build starts, the prototype gets built to whatever standard the engineering team thinks is impressive, and the result is difficult to interpret when it comes back.
Before a prototype cycle starts, four things should be defined. What uncertainty is this prototype supposed to reduce? Whose decision depends on the answer? What evidence will be collected, and what threshold constitutes success? What happens if the result is positive, and what happens if it is negative? If any of those is undefined, the cycle is technical development in search of a justification, dressed up as a prototype cycle.
The distinction between a science prototype and a customer-ready product matters here. A working technical prototype demonstrates that the science is viable. It does not yet establish manufacturability, conformity and certification requirements, reliability over time, installation and maintenance, supply-chain availability, production cost, field usability or commercial support requirements. Treating those as the same product produces unrealistic timelines and funding plans. Different questions require different builds, and they cannot be answered by the same physical object at the same time.
Testing outcomes matters more than testing features. A crop sampling device that is technically lighter than the competition is a feature. A crop sampling workflow that takes the farm manager from an hour per field to fifteen minutes is an outcome. The first can only be assessed by handing someone a prototype. The second can be assessed with a conversation about workflow, or by observing the customer using a lab-based alternative that produces the same output. Feature-level feedback before the outcome has been validated tends to be polite noise. Outcome-level feedback is diagnostic.
The same discipline applies to field testing. A weak field result does not automatically mean the technology underperformed. It can also mean the installation was unsuitable, the staff had not been trained, the data the product needed was unavailable, or the existing workflow prevented use. Without separating those, the team can make the wrong design decision. They may redesign a component when the real problem is integration. They may push for more technical performance when the barrier is installation time. They may automate a step that the customer needs to keep visible and manual. The most useful question after a field test is not “did the product work”. It is “did the complete solution create value in context, and if not, why not?”. Getting to that answer requires observing use in the real workflow rather than relying only on verbal feedback afterwards.
Related, the feedback most worth acting on comes from customers whose behaviour has changed as a result of the product. Verbal enthusiasm is common. Actual use, actual reordering, and actual behaviour change are much rarer, and are the only signals that reliably distinguish real value from politeness. Prioritise the evidence from customers who did the thing. Discount the evidence from customers who said they would.
Finally, avoid building the next prototype simply because it is the next expected TRL step. TRL describes technical maturity. It is not a plan for reducing commercial uncertainty. A team can pass every TRL milestone on schedule and still arrive at a finished product with no route to a paying customer. Every prototype cycle should be justified by the specific question it answers about the market, the buying system or the operating environment. If it cannot be justified that way, the cycle is early. Either sharpen the question, or use a cheaper mechanism to answer a different one first.
When “too early” comes back from investors
A hardware founder hearing “too early” from an investor and heading back to the lab is a familiar scene. It is often the wrong response. “Too early” is rarely a verdict about engineering. It usually means the founder has not yet shown who needs the product, how it will be adopted, what outcome matters, or whether anyone will make a meaningful commitment. More technical development does not answer any of that.
The right response to “too early” is a question. What evidence is missing, and what is the leanest credible way to generate it? Sometimes the answer will be technical. Often it will involve the buying system, the customer commitment, the field access, the implementation, the economics, or all of the above. In physical product ventures, it usually involves some combination of them. The next hardware build should exist to reduce whichever uncertainty is now blocking the next decision, whether that decision sits with a customer, a partner, a certification body or an investor.
Commercial strategy determines which uncertainty matters next; physical product development determines the leanest credible way to answer it through the product. Dr Chloe Sharp’s companion article for Sharp Insights sets out the wider commercialisation framework across software, hardware, deep tech and hybrid innovation, and how commercial evidence should shape market entry, funding strategy and route to scale.
Matt Langford is a hardware product designer and product-development adviser with experience across MedTech, AgriTech and CleanTech. Through People Planet Product, he helps spin-outs and research-led ventures translate customer and market evidence into product requirements, prototypes and development plans, supporting the transition from lab-based technology to physical products that can be tested, manufactured and deployed with real, paying customers. Wondering if your hardware venture is actually “too early,” or just missing the evidence? Start with the free Hardware Traction Audit — or book a call if you’d rather talk it through directly.
Dr Chloe Sharp is co-founder of Sharp Insights, an evidence-led commercialisation partner supporting founders across deep tech, climate tech, applied AI, health and hybrid innovation. Sharp Insights acts as an in-house commercial team, working through their commercial framework with founders to identify what needs to be known before committing further development, funding or commercial effort. The team has supported over 150 founders and secured more than £10 million in non-dilutive funding for clients, with an 80% grant success rate. Sharp Insights also runs Juno and Theia, AI assistants for customer discovery and demand validation. Chloe holds a PhD in psychology, behavioural science and sociology, is the author of Make Products That Matter, an ILM7 coach, angel investor and Innovate UK assessor. Start with a free 30-minute call at sharpinsights.co.uk/founders.
