What a technical feasibility study should answer before you spend money on a prototype 

Most engineering programmes that run into serious difficulty made their most consequential mistakes early, before a prototype existed and before significant money had been committed. The technical feasibility study is the point in a programme where those mistakes are cheapest to catch. The problem is that, in the rush to get to a hardware demonstrator, feasibility studies are often treated as a box-ticking exercise rather than a structured piece of engineering work, which means they produce confidence without actually earning it. 

This article sets out what a rigorous technical feasibility study needs to answer — and why each question matters to the decisions that follow. 

The commercial value of rigorous feasibility work is well established beyond PTL’s own view. NIST has reported that errors made during the early stages of design can contribute as high as 70% of the cost of production. Separately, Rolls-Royce work presented through INCOSE reported a benefit:cost ratio of better than 100:1 for technical risk management. That is why a feasibility study should be treated as a structured engineering activity, not an administrative gate. 

What is a technical feasibility study actually for? 

A feasibility study is not a document that proves an idea will work. It is a structured process for understanding whether the idea is worth serious development effort, and on what terms. The output should give the reader a clear picture of what is known, what is assumed, what is uncertain, and what would have to be true for the programme to succeed. 

That distinction matters because the temptation at early stage is to build confidence rather than to test it. A feasibility study written to validate a decision that has already been made does not serve the programme. One written to identify the conditions under which the decision makes sense does. 

How to define requirements clearly enough to test against them? 

The first question a feasibility study must answer is whether the requirements are actually defined. Not aspirational targets, not placeholder numbers carried over from a pitch deck, but specific, measurable, and traceable requirements that would allow an independent engineer to determine whether a proposed solution meets them.  

Requirements that are vague at feasibility stage do not become clear later. They become disputed. The point where a customer and a supplier disagree about what was meant by a specification is almost always traceable to a requirement that was never properly defined at the beginning. A feasibility study that does not challenge the requirements it is given is not doing its job. PTL’s approach to this is to prepare and agree a Functional Specification document. This is a living document that is regularly reviewed with the customer at each stage as a project progresses towards production, updated as further details are defined and confirmed.

Identifying which technical assumptions are grounded and which are speculative

Every engineering concept rests on a set of assumptions. Some of those assumptions are well-founded, tested by prior work or established physical principles. Others are essentially optimistic estimates, or projections from analogous systems that may not transfer directly to this application. 

A credible feasibility study identifies the key assumptions explicitly, distinguishes between those that are grounded and those that are speculative, and assesses what happens to the concept if the speculative ones are wrong. That is not pessimism. It is the minimum standard for understanding what the programme is actually betting on. 

How to map critical issues before they reach hardware 

Related to assumptions, but distinct from them, are the potential barriers to success, identified by PTL as critical issues. Every advanced engineering programme has critical issues at feasibility stage. The question is not whether they exist but whether they have been identified and whether there is a credible plan for resolving them. 

The risk in many feasibility studies is not that the critical issues are too large, but that they are unacknowledged. An issue that is not on the list cannot be managed. A programme that proceeds without mapping its technical unknowns will discover them in hardware, at the point where they are most expensive to resolve.

What should a feasibility study say about prototype purpose and validation approach?  

A prototype is not a goal. It is a tool for answering specific engineering questions. A feasibility study should define what questions the first prototype is intended to answer, and therefore what it needs to be capable of demonstrating. A prototype specification that is not grounded in a validation question is a prototype that will not tell you what you need to know. 

The feasibility study should also outline the broader validation approach: what will be tested, at what stage, using what methods, and to what standard of evidence. That plan does not need to be complete at feasibility, but the framework needs to exist. Programmes that proceed to prototype without a validation framework tend to produce data that cannot be interpreted confidently, because no one agreed in advance what a good result looks like. 

Why manufacturing path belongs in a feasibility study, not after it

Technical feasibility and manufacturing feasibility are not the same thing. A concept that works in prototype form may rely on processes, tolerances, materials or assembly methods that cannot be economically transferred to production. A feasibility study that does not consider manufacturing constraints is only answering half the question. 

This is not about designing for production at feasibility stage. It is about understanding whether the concept, as currently framed, has a plausible path to manufactured product. If it does not, that is important to know before the prototype is built to a specification that will need to change. 

How to set a realistic budget and timeline at feasibility stage

The final element of a credible feasibility study is an honest assessment of what the programme will cost and how long it will take, based on the engineering work that actually needs to happen rather than on the budget that was assumed or the timeline that has been promised.

Budget estimates at feasibility are inherently uncertain. That uncertainty should be acknowledged and bounded, with a clear explanation of what assumptions the estimate rests on and what would cause it to change. A programme that goes into development with a budget that was never realistic is not a programme that will complete on time and to specification. The feasibility study is the point where budget realism is cheapest to establish. 

What good feasibility work changes

A well-conducted technical feasibility study does not eliminate uncertainty. It structures uncertainty, so that the programme knows what it knows, what it assumes, and what it still needs to find out. That structure is what allows well-informed decisions to be made at each subsequent gate, rather than decisions made on optimism. 

For founders and technical leaders preparing for investment, a rigorous feasibility study also provides a secure basis for the claims being made. Investors and technical reviewers who have seen many early-stage programmes know the difference between confidence that has been earned through structured analysis and confidence that has simply been asserted. The feasibility study is where that difference is established. 

Frequently asked questions

How long does a technical feasibility study take?

For most early-stage hardware programmes, a structured technical feasibility study takes between two and six weeks, depending on the complexity of the concept and the quality of existing documentation. A study that is conducted in less time than this typically cannot address all of the areas that matter — requirements, assumptions, unknowns, validation approach, manufacturing path and budget realism — with sufficient depth to be useful. In some cases, resolution of certain critical issues, at least with a sufficient level of certainty to proceed into hardware design, will require additional analysis in a follow-on study.

What should a technical feasibility study include?

A rigorous feasibility study should include: a clear statement of the requirements the concept is being assessed against; identification of the key technical assumptions and which are grounded versus speculative; a map of the programme’s critical issues and a plan for resolving them; a defined prototype purpose and validation framework; an assessment of whether the concept has a plausible manufacturing path; and a realistic budget and timeline estimate with stated assumptions. 

What is the difference between a technical feasibility study and a concept study? 

A technical feasibility study assesses whether an idea is worth serious development effort, and on what terms. Once feasibility is established, a concept study explores the best way of turning that idea into a working product. A feasibility study is more structured, more critical, and more explicit about uncertainty than a concept study. It should produce conclusions about what is known, what is assumed, and what still needs to be resolved — not just a description of how the concept might work. 

When in a programme should a technical feasibility study be commissioned?

A technical feasibility study should be completed before prototype spend and a development path is committed to. Once tooling or prototype build costs have been committed, the findings of a feasibility study are harder and more expensive to act on. The feasibility stage is where the cost of changing direction is lowest, which is precisely why a rigorous study at this point returns a disproportionate benefit relative to its cost.

Related resources

Overview of Services

Case Study: Architecture studies for in-wheel applications