Product, Service, and Technical Feasibility

Introduction

A business idea becomes investable only when it can be shown to create customer value and to do so reliably, legally, and at an economically acceptable cost. Product, service, and technical feasibility analysis addresses this question. It connects an entrepreneur’s proposed solution with evidence about desirability, usability, performance, resources, technology, quality, intellectual property, and product–market fit.

Technical feasibility is not limited to engineering. For a software venture it includes architecture, cybersecurity, data, integration, and scalability. For a food venture it includes formulation, food safety, packaging, shelf life, and production capacity. For a service venture it includes staff capability, workflow, customer experience, facilities, and service consistency. The central task is to reduce uncertainty before committing substantial capital.

A feasibility study should distinguish three claims:

1. Desirability: customers have a meaningful problem and value the proposed solution.
2. Viability: the solution can support a sustainable business model.
3. Feasibility: the venture can build and deliver the solution with available or attainable resources.

This chapter concentrates on the third claim while showing its close relationship with desirability and viability.

Learning Objectives

By the end of this chapter, students should be able to:

• distinguish a concept, prototype, proof of concept, MVP, and commercial product;
• design experiments that test important technical and customer assumptions;
• assess technology readiness, resource requirements, quality, and operational risks;
• evaluate intellectual-property ownership, freedom to operate, and regulatory obligations;
• use product–market fit indicators responsibly;
• prepare a structured product and technical feasibility report; and
• make a justified go, revise, pause, or stop recommendation.

1. From Opportunity to Testable Solution

An opportunity statement describes a customer problem, target user, context, and expected benefit. A solution statement specifies what the venture will provide and how it will create that benefit. These statements should not be confused. Entrepreneurs frequently become attached to a particular technology before establishing that the problem matters.

A useful requirements chain is:

Customer need → user outcome → functional requirement → technical specification → verification test

For example, “customers want faster delivery” is a need. “Orders arrive within 30 minutes in the service area” is an outcome. “The dispatch system must assign an available courier within 60 seconds” is a functional requirement. A measurable specification might be “95% of valid assignments are completed within 60 seconds under peak simulated load.” The final statement can be tested.

Important terminology

• Concept: an early description of a proposed solution.
• Prototype: a representation used to learn about form, function, interaction, or manufacture.
• Proof of concept (PoC): evidence that a critical technical principle can work.
• Minimum viable product (MVP): the smallest usable offering that enables learning from real customers while delivering genuine value.
• Pilot: a limited implementation in a realistic operating environment.
• Functional requirement: what the solution must do.
• Non-functional requirement: how well it must perform, such as reliability, security, speed, accessibility, or maintainability.
• Acceptance criterion: an observable condition used to determine whether a requirement has been met.
• Technical debt: future cost created by expedient technical choices.
• Technology readiness: the maturity of a technology for its intended use.

An MVP is not necessarily a crude or incomplete version. It is deliberately limited in scope, but it must be safe, lawful, usable, and sufficiently valuable to generate credible learning. A landing page can test interest in a service, but it cannot prove that the service can be delivered at the promised quality.

2. Prototypes, MVPs, and Experiments

Prototype fidelity

Prototype fidelity should match the uncertainty being investigated. A paper sketch may test navigation and information architecture. A clickable interface may test task completion. A physical mock-up may test ergonomics. A technical prototype may test sensor accuracy or system integration. High fidelity is not automatically better; it is justified only when the question requires it.

Common prototype forms include:

A disciplined experiment begins with an assumption. The assumption should be expressed as a hypothesis containing a target group, behavior, threshold, and time period. For example: “Among independent cafés in the launch district, at least 30% of qualified owners who receive a demonstration will request a paid pilot within four weeks.” This is more useful than “cafés will like the product.”

A test card should specify:

• hypothesis;
• test method;
• sample or participants;
• success threshold;
• measurement method;
• duration and cost;
• ethical safeguards; and
• decision rule.

Evidence quality

Evidence is stronger when behavior is observed rather than merely reported, when customers commit money or time, when the test resembles the intended context, and when results can be repeated. A stated intention to buy is weaker than a deposit, signed pilot agreement, or repeated use. However, behavioral evidence must still be interpreted carefully: incentives, novelty, sampling bias, and poor experimental design can produce misleading results.

For a proportion estimated from a sample, a confidence interval can communicate uncertainty. If a sample proportion is p̂ and the sample size is n, a commonly used approximate 95% interval is:

This approximation assumes independent observations and is less reliable for very small samples or proportions near zero or one. It describes sampling uncertainty, not all sources of bias. For example, surveying only enthusiastic early adopters does not become representative merely because the sample is large.

Worked example: interpreting an MVP test

An entrepreneur offers a paid pilot to 40 qualified businesses. Twelve purchase. The observed conversion is:

The approximate standard error is:

The approximate 95% interval is 30% ± 14.2 percentage points, or approximately 15.8% to 44.2%. The result is encouraging if the business model requires at least 20%, but the interval is wide. A larger, better-selected sample and tests across different customer segments would improve confidence. The calculation does not prove future conversion, and it does not replace analysis of retention, delivery cost, or customer profitability.

3. Technical Feasibility Framework

Technical feasibility asks whether the proposed solution can be developed, produced, operated, maintained, and scaled within relevant constraints. A useful assessment covers six dimensions.

3.1 Technology maturity

Technology Readiness Levels (TRLs) provide a staged language for maturity. The exact definitions vary by sector, but the general progression moves from basic principles, to laboratory validation, to demonstration in a relevant environment, and finally to proven operation in the intended environment. A technology may be mature in general but immature in the venture’s particular application.

Entrepreneurs should document:

• what has already been demonstrated;
• the environment in which it was demonstrated;
• the gap between demonstration and commercial use;
• unresolved performance, safety, and integration risks; and
• evidence required before the next investment decision.

A low TRL is not automatically unacceptable. It means that uncertainty, time, specialist capability, and contingency funding must be recognized.

3.2 Architecture and integration

A system architecture identifies major components and their relationships. It should address inputs, processing, outputs, interfaces, data flows, failure modes, and external dependencies. Digital ventures should consider identity management, APIs, databases, hosting, observability, backup, cybersecurity, and migration. Physical ventures should consider materials, tolerances, tooling, suppliers, assembly, maintenance, and end-of-life treatment.

A technically attractive component can create strategic dependence. Reliance on one cloud provider, patent holder, specialist supplier, or proprietary data source should be recorded as a risk and, where practical, mitigated through alternatives, contractual rights, or modular design.

3.3 Resources and capability

Resource feasibility includes people, equipment, materials, facilities, data, utilities, software tools, suppliers, working capital, and time. A resource schedule should distinguish resources needed for development from those needed for recurring delivery.

Capacity should be checked against expected demand. If a process has usable capacity of 800 units per month and expected demand is 600 units, the utilization rate is:

This calculation assumes demand and capacity are measured over the same period and in comparable units. A 75% average may still conceal peak-period bottlenecks, setup time, maintenance, absenteeism, or product-mix effects.

3.4 Quality and performance requirements

Quality is conformance to requirements and fitness for customer use. Requirements should be measurable where possible. Examples include response time, accuracy, strength, shelf life, defect rate, availability, accessibility, and complaint resolution time.

A basic defect rate is:

If 18 of 1,200 units fail inspection, the defect rate is 1.5%. The denominator must be clearly defined, and the inspection method must be consistent. A defect rate alone does not reveal defect severity; a minor cosmetic defect and a safety-critical failure should not be treated as equivalent.

Service quality requires attention to the whole journey: search, purchase, onboarding, delivery, use, support, returns, and renewal. Service blueprints can map customer actions, front-stage employee actions, back-stage activities, systems, and evidence visible to the customer.

Quality assurance is preventive: requirements, supplier qualification, process control, training, and testing. Quality control is evaluative: inspection, measurement, audits, and corrective action. A mature venture uses both.

3.5 Reliability, safety, and resilience

Reliability concerns consistent performance over time. Safety concerns preventing unacceptable harm. Resilience concerns continuing or recovering operations after disruption. Risk analysis should identify hazards, causes, consequences, controls, responsible owners, and residual risk.

A simple risk-priority score may be used as a screening tool:

Here, S is severity, O is occurrence likelihood, and D is difficulty of detecting the problem before harm. Each score must use a documented ordinal scale. The product is not a probability and should not be interpreted as one. It helps prioritize discussion; it does not replace engineering judgment, legal compliance, or formal hazard analysis.

3.6 Scalability and maintainability

A solution is scalable when it can handle growth without unacceptable increases in cost, delay, failure, or complexity. Scalability may involve automation, modular design, standard operating procedures, supplier capacity, cloud resources, or workforce development. Maintainability includes documentation, monitoring, repairability, update processes, technical support, and ownership of source code or design files.

Founders should avoid proving only that a prototype works once. They should ask whether it can be produced repeatedly, supported economically, updated safely, and transferred to people other than its creator.

4. Intellectual Property and Legal Feasibility

Intellectual property (IP) may include patents, utility models, copyright, trademarks, designs, trade secrets, databases, software code, documentation, and know-how. The correct protection depends on the asset and the jurisdiction.

A patent generally requires an eligible subject matter, novelty, inventive step or non-obviousness, and industrial applicability, subject to national law. Public disclosure before filing can destroy novelty in some jurisdictions. Entrepreneurs should therefore obtain qualified advice before demonstrations, publications, crowdfunding, or investor disclosures.

A feasibility review should ask:

• Who created each important asset?
• Were employees, contractors, universities, or partners involved?
• Do written agreements assign ownership and confidentiality?
• Has a trademark, patent, design, or domain search been conducted?
• Could the venture operate without infringing third-party rights?
• Is the competitive advantage protectable, difficult to imitate, or better treated as a trade secret?

Freedom to operate is not the same as owning a patent. It is an assessment of whether planned activities may infringe enforceable third-party rights in relevant markets. Searches are evidence, not guarantees; legal opinions may be necessary.

Data and AI introduce additional concerns. A venture must examine consent, lawful processing, data minimization, retention, security, cross-border transfer, bias, explainability, and responsibility for automated decisions. Training data may carry copyright, confidentiality, privacy, or licensing restrictions. Human oversight is essential where errors could affect health, employment, credit, safety, or access to essential services.

5. Regulation, Ethics, and Responsible Design

Regulatory feasibility should be assessed early, not after product development. Requirements may concern licensing, product safety, labeling, building codes, accessibility, employment, environmental impact, consumer protection, financial services, medical devices, food safety, or telecommunications.

A regulatory map should identify the relevant authority, obligation, evidence required, approval lead time, cost, and accountable person. “No regulation applies” is a conclusion that requires investigation, not an assumption.

Ethical feasibility extends beyond legal compliance. A technically feasible product may still be undesirable if it exploits vulnerable users, creates discriminatory outcomes, encourages unsafe behavior, or produces disproportionate environmental harm. Responsible design asks:

• Who benefits and who may be excluded?
• Can users understand material risks and limitations?
• Are consent and privacy meaningful?
• Is the product accessible to people with disabilities?
• Can the product be repaired, reused, recycled, or safely retired?
• What happens when the system fails?

6. Product–Market Fit Indicators

Product–market fit is not a single score. It is a pattern of evidence showing that a defined group repeatedly obtains sufficient value from the offering and that acquisition, delivery, and retention can support the business model.

Useful indicators include:

• activation: the proportion of new users completing a meaningful first action;
• retention: the proportion returning or renewing after a defined period;
• cohort behavior: performance of groups acquired in the same period;
• repeat purchase and usage frequency;
• referral and organic acquisition;
• willingness to pay and price sensitivity;
• customer-reported outcome improvement;
• support requests, complaints, refunds, and churn; and
• contribution margin after variable delivery costs.

Retention for a cohort can be expressed as:

If 120 customers start and 78 remain active after 30 days, retention is 65%. The definition of “active” must be specified. Retention should be analyzed by segment, acquisition channel, use case, and customer type; an aggregate rate can hide strong fit in one segment and poor fit in another.

The popular “Sean Ellis” survey question—how disappointed customers would be if a product disappeared—may provide a useful directional signal, but it is not a universal scientific threshold. It should be combined with observed behavior, economic data, and qualitative interviews.

7. A Structured Feasibility Decision

A feasibility report should present evidence, assumptions, gaps, risks, and decisions. A practical structure is:

1. solution description and target user;
2. requirements traceability matrix;
3. prototype and experiment evidence;
4. technical architecture and technology maturity;
5. resources, suppliers, facilities, and schedule;
6. quality, safety, security, and regulatory requirements;
7. IP ownership and freedom-to-operate issues;
8. operating and maintenance model;
9. product–market fit indicators;
10. risk register and mitigation plan; and
11. recommendation with explicit next gates.

A requirements traceability matrix links each requirement to its source, test method, result, owner, and status. This prevents attractive demonstrations from substituting for complete verification.

The final recommendation may be:

• Go: evidence meets critical thresholds and residual risks are manageable.
• Go with conditions: proceed only after specified tests, approvals, or partnerships.
• Revise and retest: the concept is promising but key assumptions remain unsupported.
• Pause: conditions or resources are currently unfavorable.
• Stop: evidence shows that critical requirements cannot be met economically, legally, or safely.

Stopping is not necessarily failure. It can be a high-quality entrepreneurial decision that preserves scarce resources and reveals a more promising direction.

Applied Case: GreenBox Cold-Chain Meals

This is an illustrative case, not a report of an actual company.

Background and problem

A start-up proposes reusable insulated containers for local meal-delivery businesses. The container is intended to reduce single-use packaging while maintaining safe food temperature during delivery. The founders believe restaurants will pay a monthly service fee for containers, cleaning, tracking, and replacement.

Initial assumptions

The founders assume that restaurants value waste reduction, customers will return containers, the container will preserve temperature for 45 minutes, and a local washing partner can process 2,000 containers daily.

Analysis and approach

The team separates the concept into testable requirements:

The first prototype meets the insulation target but is difficult to stack and costs more than expected. A second prototype improves stacking but reduces internal volume. The team uses a concierge pilot: staff manually track containers and send reminders rather than building a complete app. This isolates the return-behavior question from software development.

Results and decision

Seven of ten restaurants pay for a pilot. During the pilot, 82% of containers return within seven days, but only 61% return within three days. The washing partner can process the planned volume only by adding a second shift. Two containers develop cracked lids after repeated washing. Temperature performance is acceptable in controlled tests, but summer field testing has not yet been completed.

The evidence supports customer interest and basic return behavior, but it does not justify full commercial launch. The appropriate decision is go with conditions: redesign the lid, validate field temperature performance in hot conditions, confirm food-safety approval, and calculate the cost of the additional washing shift. The team should not invest heavily in a tracking application until the operating model is economically and technically sound.

Learning points

The case illustrates that desirability and technical feasibility develop together. Paid pilots provide stronger evidence than interviews, but a pilot does not automatically prove scalability. A prototype can meet one performance requirement while failing durability or operational requirements. Finally, a disciplined entrepreneur treats unresolved risks as decision gates rather than concealing them in a launch narrative.

Challenges and Limitations

Feasibility analysis has unavoidable limitations. Prototype results may not predict long-term use. Early adopters may be unusually tolerant. Laboratory conditions may differ from field conditions. Supplier quotations may change. Regulations may evolve. Small samples produce uncertain estimates, while large samples can still be biased. Technical success may be undermined by poor distribution, pricing, or customer support.

There is also a danger of false precision. A risk score, readiness level, conversion rate, or confidence interval can create an appearance of certainty if definitions and assumptions are hidden. Every important metric should therefore be accompanied by its measurement method, scope, limitations, and decision relevance.

Best-Practice Checklist

A strong feasibility assessment:

• starts with customer outcomes rather than technology enthusiasm;
• tests the riskiest assumptions first;
• uses the lowest-cost prototype capable of answering the question;
• defines measurable requirements and acceptance criteria;
• distinguishes technical, operational, commercial, and regulatory evidence;
• tests in realistic environments before scaling;
• documents assumptions, version changes, failures, and learnings;
• considers accessibility, safety, privacy, security, and environmental impact;
• verifies ownership and third-party rights;
• plans maintenance, support, end-of-life, and incident response; and
• makes explicit go, revise, pause, or stop decisions.

Chapter Summary

Product, service, and technical feasibility analysis determines whether a proposed solution can create customer value and be delivered reliably, safely, legally, and economically. Prototypes, proof-of-concept tests, MVPs, pilots, and experiments serve different learning purposes. Effective experiments state a measurable hypothesis, use an appropriate test, define a success threshold, and recognize bias and uncertainty.

Technical feasibility requires examination of technology maturity, architecture, integration, people, facilities, suppliers, data, capacity, quality, reliability, safety, scalability, and maintainability. Requirements should connect customer outcomes to technical specifications and verification tests. Intellectual-property analysis must address ownership, confidentiality, protection strategy, and freedom to operate. Regulation and ethics must be considered from the beginning, especially for data-intensive and AI-enabled products.

Product–market fit is best understood as converging evidence: activation, retention, repeat use, referrals, willingness to pay, customer outcomes, and sustainable delivery economics. A feasibility report should expose assumptions and risks rather than merely advocate launch. The most professional recommendation may be conditional progress, revision, or termination when evidence does not support further investment.

Key Terms

Prototype: A representation used to learn about a proposed solution.

Proof of concept: Evidence that a critical technical principle can work.

Minimum viable product: The smallest usable offering that creates value and enables learning.

Pilot: A limited implementation in a realistic operating environment.

Functional requirement: What a product or service must do.

Non-functional requirement: A performance, quality, security, or usability condition.

Acceptance criterion: A testable condition for judging completion.

Technology readiness: The maturity of a technology for its intended application.

Technical debt: Future cost caused by expedient technical choices.

Scalability: The ability to handle growth without unacceptable deterioration.

Reliability: Consistent performance over time.

Quality assurance: Preventive activities designed to achieve required quality.

Quality control: Inspection and evaluation of outputs against requirements.

Freedom to operate: Assessment of whether planned activity may infringe third-party rights.

Trade secret: Valuable confidential information protected through secrecy.

Product–market fit: Evidence that a defined market repeatedly receives sufficient value from an offering.

Retention: Continued use or purchase by customers over a specified period.

Cohort: A group sharing a defined starting characteristic or time period.

Risk-priority number: A screening score combining severity, occurrence, and detectability ratings.

Requirements traceability: Linking requirements to tests, evidence, owners, and status.

Review Questions

Short Answer Questions

1. Distinguish a prototype, proof of concept, MVP, and pilot.
2. Why should technical specifications be linked to customer outcomes?
3. What is the difference between quality assurance and quality control?
4. Why is freedom to operate different from owning a patent?
5. Name four indicators that may contribute to evidence of product–market fit.

Long Answer Questions

1. Explain how an entrepreneur can design an experiment for a critical business or technical assumption.
2. Discuss the major dimensions of a technical feasibility assessment.
3. Explain how requirements traceability improves product development decisions.
4. Analyze the ethical, regulatory, and data-governance issues that may arise in an AI-enabled venture.
5. Discuss why a technically successful prototype may still fail as a commercial product.

Analytical / Application Questions

1. A start-up reports 45 paid customers from 150 demonstrations. Design a follow-up experiment that tests whether the result reflects genuine product value rather than a temporary promotion.
2. A manufacturer has monthly demand of 4,500 units and usable capacity of 5,000 units, but demand is highly concentrated in one week. Explain why the utilization calculation alone is insufficient and propose additional feasibility tests.
3. Using the GreenBox case, recommend the three most important next decision gates and justify the order in which they should be completed.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a minimum viable product?

A. The cheapest possible version, regardless of safety or usefulness

B. The smallest usable offering that delivers value and enables learning

C. A fully scaled product with every planned feature

D. A technical laboratory demonstration with no users

Correct Answer: B. The smallest usable offering that delivers value and enables learning

Question 2

A functional requirement primarily describes:

A. What the solution must do

B. How attractive the logo should be

C. The founder’s preferred financing method

D. The legal structure of the company

Correct Answer: A. What the solution must do

Question 3

A pilot is most useful because it:

A. Eliminates all commercial risk

B. Tests implementation in a realistic operating environment

C. Replaces the need for regulatory approval

D. Guarantees product–market fit

Correct Answer: B. Tests implementation in a realistic operating environment

Question 4

If 18 of 1,200 units are defective, what is the defect rate?

A. 0.15%

B. 1.5%

C. 6.7%

D. 15%

Correct Answer: B. 1.5%

Question 5

Which evidence is generally stronger than a customer’s stated intention to buy?

A. A positive response to a general advertisement

B. A request for more information with no commitment

C. A paid pilot or deposit

D. A founder’s personal opinion

Correct Answer: C. A paid pilot or deposit

Question 6

In the risk-priority screening formula RPN = S × O × D, what do the variables represent?

A. Sales, output, and demand

B. Severity, occurrence, and detectability

C. Speed, operations, and delivery

D. Scale, ownership, and design

Correct Answer: B. Severity, occurrence, and detectability

Question 7

Which statement about freedom to operate is correct?

A. It is identical to owning a patent

B. It concerns whether planned activities may infringe third-party rights

C. It guarantees that no competitor can enter the market

D. It applies only to trademarks

Correct Answer: B. It concerns whether planned activities may infringe third-party rights

Question 8

If 78 of 120 customers remain active after 30 days, the cohort retention rate is:

A. 35%

B. 52%

C. 65%

D. 78%

Correct Answer: C. 65%

Question 9

Which approach best matches prototype fidelity to the learning objective?

A. Use the highest fidelity possible for every question

B. Use a paper sketch to test a complex production process

C. Use a clickable interface to test user navigation

D. Avoid prototypes until the final product is funded

Correct Answer: C. Use a clickable interface to test user navigation

Question 10

A technically feasible product may still fail commercially because:

A. Technical feasibility automatically proves demand

B. Customers may not value it enough relative to its price and delivery cost

C. Quality requirements are irrelevant after launch

D. Regulation applies only to large firms

Correct Answer: B. Customers may not value it enough relative to its price and delivery cost