Who this is for: Businesses considering a new product or a substantial change to an existing one.
A technical feasibility study establishes what must be true for an idea to become a workable product. Its useful output is a decision: proceed, change the concept, obtain missing evidence or stop pursuing an unsuitable option. A persuasive rendering cannot make that decision on its own.
The starting point is the intended outcome, the operating environment and the constraints the business cannot change. These allow the investigation to be scoped sensibly. There is little value in detailing components that still depend on an unresolved choice about the product’s basic function or architecture.
Separate requirements, preferences and assumptions
A requirement describes an observable outcome: a maximum envelope, an interface, a way of operating or a performance level under stated conditions. A preference guides the design but can be negotiated. An assumption is something that still needs evidence, such as component availability or whether users will accept a different operating sequence.
Keeping these categories separate prevents an assumption from silently becoming the basis of every subsequent calculation. Record who requested each decisive requirement, why it matters and what evidence would close it. If two requirements conflict, surface that conflict while alternative concepts are still available. Resolving it after a detailed design has been commissioned can affect several connected decisions.
Compare options against the same intended use
The comparison is meaningful only when each option addresses the same application and assumed production volume. Comparing the purchase price of one component with the cost of a complete system creates a misleading result. Include development, integration, sourcing, maintenance and unresolved information for every option.
The following table is a starting point for discussion, not a universal scoring system. Weightings depend on the business. An easily modified approach may be useful while the concept is uncertain, while long-term spare-parts availability may matter more for a product expected to remain in service for years. Record those priorities before selecting the preferred option.
Scroll horizontally to see every column.
| Criterion | Question | Useful evidence |
|---|---|---|
| Function | Does it meet the intended need? | A targeted test or documented analysis |
| Integration | Will it connect to existing parts? | Interfaces, envelope and dependencies |
| Production | Can it be made at the expected volume? | Process and supplier review |
| Service life | How will it be supported? | Spares, access and alternative components |
Test the uncertainty that could change the decision
Not every uncertainty calls for a complete prototype. An interface sample may answer a fit question; a simple volume model may reveal more about user interaction than a finished assembly. Choose the experiment after writing down the decision it is supposed to support, including the outcome that would make the team reconsider its preferred concept.
It is useful to distinguish verification against a stated requirement from validation for the intended use, a distinction also made in NASA’s systems engineering guidance. This methodological reference does not make aerospace procedures automatically applicable to an industrial project. A feasibility report should identify the conditions actually examined and the limits of the conclusions drawn from them.
References: NASA — Systems Engineering Handbook: verification and validation
Specify the decision package the business will receive
Useful outputs include agreed requirements, options considered, evidence gathered, open risks and the reason for the recommended direction. They should also identify the next decision points: what must be known before detailed CAD, before a prototype is ordered and before production tooling is committed.
Commercial estimates should be distinguished from confirmed figures, with the assumptions that could change them. Where relevant to an Italian investment, the technical schedule and expected documentation can be reviewed alongside potential funding instruments. Technical feasibility does not establish funding eligibility or market demand. Those questions require their own evidence and should not be hidden inside a favourable engineering conclusion.
Prepare for an initial feasibility discussion
- Describe the user, intended application and problem to solve.
- Gather available drawings, photographs or samples with their versions.
- List envelope, environment, interface and performance constraints.
- Explain expected volumes, meaningful deadlines and existing commitments.
- Identify the uncertainties currently preventing an investment decision.
Common questions
Do we need a CAD model first?
No. A clearly described need can be enough to start. Sketches, photographs and measurements help, but the first objective is to clarify requirements and decisive uncertainties rather than immediately commission a detailed model.
Does feasibility include production drawings?
That depends on the agreed scope. Feasibility supports a decision and may include early concepts or tests. Production drawings, comprehensive testing and manufacturing documentation are further activities that should be specified explicitly.
Sources and further reading
Apply this to your project.
Tell us about the product and the decision you cannot yet make. Studio Dinamico can help define a focused technical assessment and the evidence it needs to produce.
Discuss your product development