# What a Product Feasibility Study Should Prove Before You Build a Prototype
A prototype is often treated as the first tangible sign of progress. It gives a team something to hold, demonstrate, photograph, or place in front of a customer. That visibility is valuable, but it can also tempt a company to integrate the product before it has tested the assumptions that determine whether the concept is viable.
A product feasibility study creates a deliberate pause between “we have an idea” and “we are building the product.” Its purpose is not to eliminate uncertainty or produce a guarantee. Its purpose is to identify the uncertainties that could invalidate the concept, gather proportionate evidence, and make a documented decision about the next investment.
When done well, feasibility work can prevent a team from spending months refining a prototype around an impossible performance target, an unavailable component, an unsuitable manufacturing process, or a cost structure that cannot support the business.
Feasibility is a decision, not a document format
Some feasibility reports become long collections of research with no clear recommendation. Others are little more than optimistic summaries. A useful study is organized around a decision: should the team proceed with this concept, revise it, test a specific risk, or stop?
The work begins by defining the proposed product, intended user, use environment, essential functions, business assumptions, and current level of evidence. It should state which decision the study supports and what remains outside scope.
The output may be a concise technical memo for a focused mechanism or a larger report for a complex product. Length is less important than traceability. A reviewer should be able to see the assumptions, method, evidence, uncertainty, and reasoning behind the recommendation.
Feasibility is also time-bounded. A study based on preliminary information should say so. If requirements, volume, suppliers, or regulations change, the conclusion may need to be revisited.
Start with the product claim
What must be true for the product to create value? This is more specific than listing features.
A product claim might involve lifting a load within a defined space, maintaining temperature for a given duration, positioning a component within an accuracy band, surviving a use cycle, fitting a user population, or reducing a process step. The claim should connect the user outcome to measurable performance.
Break the claim into supporting requirements. Identify inputs, outputs, interfaces, constraints, and verification methods. Separate desired performance from minimum acceptable performance. Clarify which values are known, estimated, or assumed.
This step often reveals that the team does not yet agree on the product. That is useful. It is less expensive to resolve disagreement in a requirement review than after stakeholders react to different interpretations of a prototype.
Identify the assumptions that could kill the concept
Not every unknown deserves equal effort. Feasibility should focus on risks with high consequence and meaningful uncertainty.
Ask what would make the concept unacceptable even if the rest of the design worked. Common examples include insufficient strength or stability, excessive heat, inadequate battery life, uncontrollable variation, a mechanism that binds, a component that is too large, a material that cannot tolerate the environment, an unsafe failure mode, a process that cannot make the geometry, or a unit cost far beyond the business case.
Create a risk register with the assumption, consequence, current evidence, likelihood or uncertainty, proposed action, owner, and decision date. A simple high/medium/low scale can be enough if the team defines it consistently. More formal methods may be appropriate in regulated or high-consequence contexts.
The goal is not to make the risk table look green. The goal is to make uncertainty visible so the team can spend effort where evidence changes the decision.
Test technical principles before integrated details
Technical feasibility asks whether the concept can meet essential performance within its constraints. The method should match the risk.
First-principles calculations can estimate loads, energy, flow, heat, stiffness, motion, torque, pressure, or geometry. Simulation can explore conditions that are difficult or expensive to test, provided the model assumptions and boundary conditions are credible. Bench experiments can isolate uncertain physical behavior. Supplier data can clarify component capability, but marketing values should be checked against the real operating condition.
Use margins intentionally. A rough calculation with conservative assumptions can quickly show that a concept has ample capacity or no plausible path. A detailed model is more valuable when the decision depends on a narrow range and the inputs are known well enough to justify the precision.
Document failed approaches. A concept that did not meet a target still produced valuable evidence. Future teams should not repeat it because the result lived only in one engineer’s memory.
Examine architecture and interfaces
Many concepts fail not because any single component is impossible, but because the components cannot coexist within the product constraints.
Create a preliminary architecture that shows subsystems, energy or information flow, mechanical interfaces, user interfaces, and the physical envelope. Identify dependencies: a larger motor changes heat and power; more insulation changes volume; a stronger joint may change assembly; a protective enclosure may restrict access or cooling.
Packaging models can test clearances and service access before surface detail exists. Interface documents can define ownership and prevent two disciplines from making incompatible assumptions. Even for a primarily mechanical product, consider electronics, software, packaging, manufacturing, installation, and service interfaces where relevant.
Review off-nominal conditions. What happens when power is lost, a user applies the wrong force, a part is assembled backward, a sensor fails, a product is dropped, or maintenance is delayed? Feasibility does not require solving every case, but it should identify conditions that can change the architecture.
Screen materials against the real environment
A material is feasible only in context. Nominal strength may matter, but so can stiffness, fatigue, creep, impact, wear, friction, moisture, chemicals, ultraviolet exposure, sterilization, temperature, fire behavior, appearance, joining, and supply.
Define the environment over transport, storage, use, cleaning, and disposal. Consider duration and cycles, not just maximum values. A polymer may tolerate a short heat exposure but creep under sustained load. A coating may resist one chemical but not the cleaning process. A metal pair may create galvanic corrosion in the actual environment.
Material feasibility also includes manufacturing. Can the intended process produce the geometry and properties? Is the grade commonly available in the expected region and form? Does it require special finishing, controlled storage, or a supplier that narrows the sourcing options?
At this stage, the goal may be to narrow families and define tests rather than select a final grade. State what evidence is needed before release.
Check manufacturing feasibility early
A concept can perform perfectly in CAD and still be impractical to produce.
Identify likely manufacturing processes and review their design constraints. Consider tooling, draft, tool access, wall thickness, bends, workholding, support structures, parting, joining, surface finish, tolerance capability, and inspection. Ask whether the process makes sense at the assumed volume.
Talk to appropriate suppliers before detailed release. Share enough information for useful feedback, protect confidential information through approved agreements where necessary, and ask suppliers to state assumptions and exceptions. A supplier’s ability to make one prototype does not prove repeatable production capability, so distinguish between “possible once” and “controllable at scale.”
Estimate the effect of yield, secondary operations, inspection, handling, packaging, and logistics. These often explain why a theoretically inexpensive process produces an unattractive landed cost.
Build a preliminary commercial model
Technical success is not sufficient if the development and production economics cannot support the intended business.
Create a range-based model for development engineering, prototypes, tooling, testing, certification or compliance activity, unit production, packaging, freight, inventory, service, and expected change. Connect the model to volume assumptions and price strategy.
Avoid using a single precise number when inputs are preliminary. Show low, expected, and high cases or another transparent range. Identify the variables with the greatest effect: material price, cycle time, component cost, tooling amortization, volume, yield, labor, or compliance work.
The purpose is not to produce an accounting forecast from weak data. It is to discover whether the concept has an economic path and which technical decisions control that path. If no reasonable scenario supports the business, the team should revise the concept before investing in an integrated prototype.
Review standards, safety, and regulatory context
The team should identify applicable obligations early enough that they can influence architecture, materials, documentation, and testing. Requirements vary by product, claim, industry, market, and jurisdiction, so qualified specialists may be needed.
Begin with intended use, reasonably foreseeable misuse, users, energy sources, failure modes, and markets. Research relevant laws, standards, certifications, labeling, environmental restrictions, accessibility, data/privacy, import, and disposal requirements as applicable.
Do not assume that using a compliant component makes the final product compliant. Integration, enclosure, wiring, software, instructions, and use can change the assessment. Similarly, do not use “meets industry standards” as a generic marketing statement without identifying and evidencing the specific requirement.
The feasibility report should state what has been reviewed, by whom, what remains uncertain, and what formal assessment is planned.
Protect the supply path
Feasibility includes the ability to obtain critical materials, components, processes, and expertise at the needed time and scale.
Identify long-lead and single-source items. Check lifecycle status, regional availability, minimum order quantities, export or import constraints, tooling capacity, approved alternatives, and supplier financial or operational risk where appropriate. A concept that depends on a rare component may need a second architecture before detailed design.
For custom processes, ask how many capable suppliers exist and which features restrict the pool. For standard components, define the parameters that matter so alternatives can be evaluated without redesigning the product.
The supply review should influence the risk register. “Available from one online listing today” is not a supply strategy for a production program.
Choose the smallest prototype that answers the decision
Feasibility often includes physical testing, but the first build does not need to look like the final product.
If the key risk is a latch force, build the latch and representative interfaces. If the risk is thermal, create a thermal test article with controlled loads. If the risk is user reach, make an ergonomic volume model. If the risk is a joining process, test representative coupons before designing the full assembly around it.
This approach reduces cost and improves learning because fewer variables change at once. It also lets teams run parallel experiments on independent risks.
Define the question, configuration, procedure, measurement, acceptance criteria, and next decision before ordering the prototype. Otherwise, the team may admire the model while disagreeing about what it proved.
State uncertainty honestly
Every feasibility conclusion has conditions. The report should distinguish measured data, supplier information, calculation, simulation, analogy, expert judgment, and assumption.
Use sensitivity analysis for uncertain inputs. If performance changes dramatically with friction, user force, ambient temperature, or production variation, that dependency deserves attention. If a conclusion remains stable across a broad range, the team may not need more precision yet.
List unresolved questions and the consequence of being wrong. A “go” decision can be appropriate with open risks if the next phase includes controlled actions before an irreversible commitment. The decision owner should understand and accept those conditions.
Feasibility language should be specific: “The concept is technically plausible within the evaluated load and envelope, subject to prototype validation of the joint” is more useful than “The product is feasible.”
What the feasibility report should contain
A practical report commonly includes:
- Executive decision and conditions.
- Product definition, intended use, and study scope.
- Requirements and assumptions.
- Concept architecture and alternatives considered.
- Technical analysis and experiments.
- Manufacturing and supplier assessment.
- Preliminary cost and schedule ranges.
- Safety, standards, and regulatory considerations.
- Supply and lifecycle considerations.
- Risk register and unresolved questions.
- Recommended development plan, prototypes, and decision gates.
- Source references, calculations, data, and revision history.
The report should be understandable to the decision makers who will fund and govern the next phase. Technical detail can live in appendices, but the recommendation must not hide behind it.
Common feasibility mistakes
Starting with detailed CAD. Surface detail can create false confidence while architecture risks remain untouched.
Testing what is easy rather than what is dangerous. A beautiful appearance prototype may not address the failure that determines viability.
Treating supplier enthusiasm as evidence. Supplier input is important, but assumptions, process capability, and production conditions need verification.
Ignoring the business model. A technically possible product may still have no plausible cost or schedule path.
Using a prototype as the requirement. Teams sometimes accept whatever the prototype happened to do rather than testing the intended performance.
Writing a conclusion without conditions. Decision makers need to know what was proved, what was not, and what could change the answer.
A feasibility study buys better choices
The best feasibility work does not make a product inevitable. It makes the next choice more informed.
It may confirm that the concept deserves detailed development. It may reveal a more practical architecture. It may recommend a focused experiment before integration. It may show that the economics need a different process or market. In some cases, it may support stopping the project—and avoiding a much larger loss.
Before funding an integrated prototype, ask:
- Are the essential product claims testable?
- Have the highest-consequence assumptions received evidence?
- Is there a plausible manufacturing and supply path?
- Does a realistic cost range support the business?
- Are safety and regulatory questions identified?
- Is the next prototype designed around specific decisions?
If those answers are unclear, Aurea Engineering can help structure a focused feasibility study, identify the governing risks, and define the evidence and prototype plan needed for the next gate. Begin with the decision your team must make—not with the prototype you hope to show.
> Editorial note: This article is general educational information. Feasibility, safety, testing, manufacturing, and regulatory requirements depend on the specific product, use, market, and jurisdiction. Engage appropriately qualified professionals for the application.