Before You De-Risk the Hardware, De-Risk the Decisions: The Cost of Learning in Technology Development
Insights from Dr Jeremy Simmons, U.S. DOE ORISE Marine Energy Fellow at Blackfish Engineering
Some of the most expensive lessons in engineering are not learned when a project fails. They are learned when a project succeeds just enough to discover, years and millions of pounds later, that it has been solving the wrong problem.
A prototype works. A demonstration is completed. Funding is secured. Readiness milestones are achieved. From the outside, everything appears to be moving in the right direction.
Then reality intervenes.
The system proves difficult to manufacture at scale. Maintenance is far more complex than anticipated. Reliability falls short of expectations. Deployment takes longer than planned. A critical design assumption that seemed reasonable early in the programme becomes difficult to defend when exposed to real operating conditions.
At that point, the technology may still be recoverable. Valuable learning has been generated and progress has been made. Yet the organisation is now discovering something that could have been explored years earlier at a fraction of the cost.
This challenge was the focus of a presentation given by Dr Jeremy Simmons during the ICOE/OEE 2026 session Building the Business Case: Cost Reduction Pathways. Drawing on publicly available development data and experience spanning hydraulic systems, hardware-in-the-loop testing, wave-powered desalination research and technology development, Jeremy posed a question that extends far beyond ocean energy:
How can organisations reduce the cost of learning?
At ICOE/OEE 2026, the session Building the Business Case: Cost Reduction Pathways examined how ocean energy developers can reduce costs as technologies progress towards commercialisation. Jeremy's contribution explored a more fundamental challenge that applies across engineering sectors: how to ensure the most important questions are answered before they become expensive.
It is a deceptively simple question, but one that has implications across almost every technology sector.
The Hidden Economics of Engineering Decisions
When organisations discuss cost reduction, attention naturally gravitates towards visible factors: manufacturing costs, supply chains, materials, installation methods and operations and maintenance requirements.
These areas matter enormously, particularly as technologies approach commercial deployment. Yet long before procurement teams negotiate material costs and long before operators think about maintenance strategies, another set of decisions is quietly determining much of a project's eventual economics.
Engineering decisions.
Every major programme is built upon assumptions. Some concern performance. Others concern reliability, manufacturability, maintainability, operability or deployment strategy.
In the early stages of development, those assumptions are relatively cheap to challenge through analysis, testing and modelling and simulation. A change may require additional modelling, testing, design revisions or engineering effort, but the consequences are usually manageable.
As development progresses, however, those same assumptions become embedded within increasingly expensive activities. Detailed engineering packages are completed, hardware is manufactured, supply chains are established, demonstration programmes are launched, regulatory pathways are pursued and investors, stakeholders and customers become committed to a particular vision of the future.
By this stage, teams are often managing increasingly complex programmes, making successful delivery heavily dependent on the quality of earlier engineering decisions.
Changing direction remains possible. It simply becomes far more expensive.
The decision itself may not have changed, but the cost of discovering whether that decision was correct increases dramatically over time.
Why Intelligent Organisations Still Learn Too Late
Few teams deliberately postpone important learning.
In reality, many of the best engineering organisations face powerful incentives that encourage exactly that outcome.
Investors want evidence of progress. Grant programmes require milestones. Customers seek confidence. Leadership teams need momentum. Technology-readiness frameworks provide useful structures for measuring development progress.
None of these drivers are inherently problematic. In fact, they are often entirely appropriate.
The challenge arises when visible progress becomes easier to demonstrate than genuine understanding.
A prototype is visible. A sea trial is visible. A successful test campaign is visible. An increase in technology readiness is visible.
By comparison, uncertainty often remains hidden.
Questions around maintainability, manufacturing constraints, operational practicality or long-term reliability can remain unresolved while a project appears to be progressing successfully through increasingly advanced stages of development.
The result is not incompetence. It is human nature.
Organisations naturally focus on the metrics being measured. Yet there is an important distinction between demonstrating that something works and understanding why it will succeed commercially.
The two are related, but they are not identical.
Performance Before Readiness
One of the central themes explored in Jeremy's presentation was the idea of prioritising performance before readiness.
The phrase is not an argument against readiness. Technologies must ultimately be demonstrated, deployed and proven. Investors, customers and regulators all require evidence that risks have been addressed.
Rather, the idea challenges the sequence in which some risks are tackled.
A readiness-first approach can encourage organisations to focus heavily on proving that a technology is ready for the next stage of development.
A performance-first approach asks a different question:
Are we confident this is the solution we genuinely want to scale?
That distinction matters.
Before expensive hardware programmes begin, organisations still have opportunities to challenge fundamental assumptions about architecture, manufacturability, maintainability, reliability and operations.
As technologies mature, the challenge often shifts from proving a concept works to ensuring it can be delivered repeatedly and reliably, a theme explored in our recent article From Prototype to Repeatable Project.
Those decisions often determine commercial success long before anyone calculates a levelised cost of energy, launches a production line or commissions a field deployment.
The earlier these questions are answered, the cheaper the learning becomes.
The Danger of False Confidence
Perhaps the most subtle risk in technology development is not technical failure.
It is false confidence.
A successful test programme can create confidence. A funding milestone can create confidence. A prototype demonstration can create confidence.
Sometimes that confidence is fully justified.
Sometimes it masks unanswered questions.
An organisation may become increasingly certain that a technology is progressing while remaining uncertain about the factors that ultimately determine whether it will be commercially viable.
This is particularly common in hardware-intensive industries where physical demonstrations require substantial investment.
The act of building something creates commitment and the act of deploying it creates even more. Stakeholders understandably want to believe that progress achieved should continue.
Yet engineering history is full of examples where the underlying challenge was not whether a system could work, but whether it could work repeatedly, economically, safely and reliably under real operating conditions.
Confidence is valuable, but evidence is even more valuable.
This closely mirrors a theme explored in our article, The Validation Gap: Why Engineering Models Never Perfectly Match Reality, where we discuss the importance of testing assumptions against real-world evidence.
The challenge for engineers is ensuring the two remain aligned.
The Questions That Matter Most
Across different sectors, technologies may look entirely different, but the critical questions often sound remarkably familiar.
Can it be manufactured repeatedly?
Can it be maintained efficiently?
Can components be accessed, repaired or replaced?
How does performance change over time?
What happens when something fails?
What skills, infrastructure and resources are required to operate it?
Does increased performance introduce new reliability risks?
Can it be deployed where customers actually need it?
Can it be tested effectively before major investment is committed?
These questions are relevant whether a team is developing a tidal turbine, an autonomous vessel, an aerospace mechanism, a defence platform, a battery system or a novel industrial process.
The technology changes, but the economics of learning remain remarkably consistent.
Why This Matters Beyond Ocean Energy
Although Jeremy's analysis focused on ocean-energy development, the principle itself is universal.
Every organisation developing complex hardware operates under some form of uncertainty. Every organisation must decide which risks deserve attention today and which can safely be addressed tomorrow. Every organisation must also balance progress against understanding.
For clean-tech innovators, the challenge may be scaling from prototype to production.
For defence programmes, it may be ensuring operational robustness before deployment.
For advanced manufacturers, it may be understanding how design decisions affect production efficiency.
For researchers, it may be generating sufficient evidence before pursuing large-scale demonstration programmes.
Different sectors use different language, but the underlying challenge remains consistent.
The later a critical lesson is learned, the more expensive that lesson becomes.
Engineering as a Tool for Better Decisions
This is one reason why some of the most valuable engineering activities often appear, at first glance, to slow things down.
Independent design reviews
Verification and Validation programmes
Failure-mode analysis
Test planning
Systems engineering
Requirements management
Challenge sessions
None of these activities create compelling photographs for investor presentations. They rarely generate headlines. They can occasionally feel uncomfortable because their purpose is to expose uncertainty rather than celebrate progress.
Yet their value lies in helping organisations answer an essential question:
Are we solving the right problem before we commit significant resources to the solution?
Viewed through that lens, engineering is not simply a means of proving a design works.
It is a means of improving decision quality. Independent challenge, peer review and technical advisory support can help organisations expose assumptions before they become expensive project risks.
The organisations that consistently develop successful technologies are rarely those that avoid mistakes altogether. They are the organisations that discover important truths while those truths are still affordable.
A Different Way to Think About Cost Reduction
When cost reduction is discussed, attention often turns towards materials, manufacturing, logistics and operational efficiency. Those factors undoubtedly matter.
However, Jeremy's presentation offered a useful reminder that some of the largest savings may originate much earlier in the development process.
They arise when engineering teams identify the assumptions that matter most and challenge them before those assumptions become embedded within expensive hardware, large-scale demonstrations and long-term investment decisions.
Through effective engineering design, teams can evaluate alternative architectures, challenge assumptions and improve confidence before committing significant resources.
In that sense, cost reduction is not solely about building things more cheaply.
It is about learning more intelligently.
Because in complex technology development, the most expensive mistake is often not making the wrong decision.
It is discovering whether the decision was right only after millions have already been spent.
Or, as Jeremy's presentation ultimately argued:
Before you de-risk the hardware, de-risk the decisions.
Download the Presentation
Jeremy's ICOE/OEE 2026 presentation, "The Cost to De-Risk", explored the relationship between technology development, design iteration and the escalating cost of learning as projects progress towards commercialisation.
Download the presentation to explore the original analysis, development-stage cost comparisons and the concept of performance-first versus readiness-first development pathways.
At Blackfish, much of our work centres on helping clients answer critical engineering questions before those questions become expensive. Through analysis, verification, validation, testing and independent technical review, we help organisations build confidence in the decisions that ultimately shape project success.
If you're developing a new technology, planning a test programme, or trying to understand how much confidence you really have in your design assumptions, we'd be happy to discuss the challenge.
Comments