Knowing whether a new product is worth building is one of the most valuable decisions a technical lead can make.
Not because the answer is often no. In most cases, the product is worth building. What matters is whether it is worth building as currently planned, at the currently assumed cost, for the currently targeted market.
Treating viability as a yes-or-no decision made once at the start tends to create problems mid-development, when the real constraints become visible and changing direction has already become expensive. Keeping it as a live question, tested at each stage, gives leadership the information they need when they need it.
What Viability Actually Means in NPD
When a product fails commercially, the instinct is to call it a market failure. More often it is a viability failure.
The product has a credible market and the engineering is competent. What often goes wrong is the relationship between the commercial model and the technical reality. If a market model is set at the start and treated as fixed, and the constraints that change it emerge later, the cost of responding to them has already grown.
Viability is not a number or a gate, it changes shape as the programme develops.
At the outset, our viability questions are primarily commercial:
- Does a market exist at a price point that justifies the investment?
- Is the capital requirement achievable given the revenue model?
As development progresses, viability questions become technical:
- Can the product be built to meet its requirements at the target cost?
- Can it be tested, certified and manufactured at a volume that makes the business case hold?
At 3Point1, our New Product Development (NPD) process is structured to surface constraints early, when responding to them is still manageable.
The 8 Stages of Electronic Product Development and Where Viability Is Tested
At 3Point1, we structure NPD across eight stages. Viability is not a decision made once at the beginning; we test it progressively, as each stage adds real constraints to the picture.
The 8 Stages:
- Business case
- Market model
- Requirements
- Concept design
- Engineering
- Prototyping and testing
- Production
- Ongoing operations
The decisions made in stages one and two shape every stage that follows. An engineering team can deliver exactly what was asked of them and still produce a product that cannot be viably brought to market if the commercial foundations were not properly set.
Stage 1: The Business Case
The business case is where the programme earns its rationale, or reveals that more thinking is needed before development begins.
It needs to answer five questions with enough rigour to hold up as the programme progresses.
What will the product cost to produce?
A target production cost must be established before development begins. Bill of materials cost cannot be known precisely at this stage, but a credible range can be. Without one, there is no way to know whether the product can be built at a price the market will bear.
How will the product generate revenue?
Is the product a one-time purchase, a subscription, a service contract, or a loss leader generating margin through consumables? Each has different implications for the volume needed to recover development investment, and the timeline to profitability. The revenue model is not a commercial detail to finalise while engineering is underway. It directly affects what the product needs to be, how it needs to be built, and at what cost.
What is the total capital requirement?
Development costs, including salaries, design work, and prototypes, are what most programmes plan for. What catches teams out are the one-off costs that arise just before manufacturing begins: tooling, certification, production line setup, and initial component inventory. These can be substantial, and they all land before a single unit has been sold.
A common example is end-of-line testing. Automated test equipment carries a higher setup cost but a lower cost per unit. Manual testing is cheaper to implement but costs more at volume. Neither is universally correct. One client came to us with an assumption that automated testing was required, which was adding significant cost and delay to the programme. For their volumes, manual testing was the right choice, and the business case improved materially once that decision was revisited.
How is capital raised, and on what terms?
The terms of funding affect the financial headroom available during development. A programme funded on a tight runway with milestone-based capital release has different risk dynamics to one with committed long-term investment. This affects how aggressively requirements can be set and how much iteration the programme can absorb before the business case comes under pressure.
Are there external constraints that affect timing?
Regulatory windows, competitor launches, IP expiry and market deadlines can all change what a viable programme looks like. A product that could be developed carefully over 24 months may need a fundamentally different approach if a competitor is 12 months from market.
Stage 2: The Market Model
The market model defines how the product makes money: who pays, how much, how often, and at what volume. It translates the business case into a commercial structure and is more consequential for product requirements than most teams appreciate.
The point we see clients leave too late, more often than any other, is the relationship between manufacturing cost and price. A product can clear every technical hurdle and still fail commercially if the cost to manufacture it cannot support a price the market will pay. That relationship needs to be visible early, while design decisions are still open, not after the engineering phase has locked in the bill of materials.
The other consequence of the market model that is frequently missed is compliance. A product sold at a premium price into a regulated sector carries very different obligations to one competing on cost in a commercial market. Those obligations affect design, testing, documentation and certification cost. They belong in the market model, not as a discovery made during the requirements phase.
Stage 3: Requirements
Requirements are where commercial intent becomes technical specification.
The instinct in many programmes is to write tight requirements. They reduce ambiguity, make cost estimation more reliable and give teams a clear target. Written too tightly before sufficient technical understanding exists, they can foreclose options that would have been valuable, creating a change control burden when those options need to be reopened.
Loose requirements create a different problem. Scope drifts, cost estimates become guesswork, and teams working from the same brief can arrive at incompatible solutions.
The better approach is requirements that are tight where commercial constraints demand precision, such as cost targets, regulatory thresholds and interface specifications, and deliberately open where the technical solution is not yet understood, with a clear process for resolving them as concept design progresses.
The commercial consequences of getting requirements wrong are significant. A requirement that cannot be tested adds cost at stage six. A requirement that manufacturing cannot meet at the target cost resurfaces at stage seven, when it is far more expensive to address. How 3Point1 approaches requirements in practice is covered on our process page.
Stage 4: Concept Design
The concept design phase establishes a credible technical direction and identifies the main risks. It is not a commitment to a solution; it is the process by which the programme develops enough understanding to commit to one with confidence.
The discipline here is controlling deviation. Every departure from requirements during concept design carries a cost, sometimes immediately visible, more often deferred. Products that arrive at the end of development significantly outside the requirements, or materially over budget, can usually be traced to a specific point in concept design where a deviation was accepted without being fully understood.
This is also the stage where the integration of disciplines matters most and is most often underestimated. Product design, electronics, firmware and manufacturing readiness are not separate conversations to be had in sequence. The enclosure geometry affects PCB layout. PCB layout affects thermal performance. Thermal performance affects component selection. Component selection affects cost. None of those decisions can be made cleanly in isolation.
We cover the mechanics of this in detail in our post on the fragmentation of electronic device development. The principle applies with particular force at concept design, where decisions are most open, and the cost of getting them wrong is lowest.
Stages 5 and 6: Engineering, Prototyping and Testing
These stages are where the product becomes real and where the consequences of earlier decisions become visible. Two points are worth emphasising specifically in the context of viability.
The cost picture becomes fixed here, not at production.
By the end of the engineering phase, the majority of the product’s unit cost is determined. Component selection, PCB complexity, assembly requirements, and the firmware architecture that shapes test and support overhead are all locked in during engineering. If the market model has not been checked against real cost data by this point, the business case is built on assumptions that may no longer hold.
Active budget management during engineering means tracking the target production cost as the design evolves, rather than waiting for a formal cost review at the end. A design decision that adds cost is not necessarily wrong. It is only wrong if it has not been explicitly weighed against the market model.
Prototyping is not the start of validation. It is the end of the period when validation is cheap.
A test failure at prototype stage is not a disaster. It is the expected outcome of a rigorous development process. What matters is that the test standard was known and designed against from the start of engineering, so that a failure at prototype stage reveals something specific and correctable rather than a systemic issue with the architecture.
Stage 7: Production
By the time a product enters the production stage, bill of materials cost is largely determined. What is less predictable, and consistently underestimated, is the total cost of production setup. This typically includes:
- Tooling for injection-moulded, cast or formed mechanical components
- End-of-line test equipment and test fixture development
- Quality management documentation and process validation
- Regulatory or sector-specific production approvals
- Initial component inventory and supply chain qualification
Each of these is a real cost incurred before a single saleable unit is produced. The programmes that handle this well are the ones where manufacturing was involved during engineering, reviewing component choices and tolerances while the design was still flexible. Production cost should be a live number throughout the programme, not a figure that first appears at the production commitment stage.
Viability as a Running Decision
The programmes that handle viability well share one characteristic. They treat it not as a gate to pass at the start, but as a live discipline that runs through the programme and is tested at each stage.
What makes that possible is structure. That means clear decision gates, budget tracked as a live document, and manufacturing, firmware and compliance thinking present from concept design rather than introduced in sequence. In practice, that means concurrent engineering: the disciplines working together from the outset rather than handing work over in stages. We cover what that looks like, and why it matters, in our posts on electronic device development fragmentation and IoT product design.
The commercial and technical decisions in a development programme are not separate tracks that converge at launch. They interact continuously, and the earlier that interaction is managed deliberately, the less often it needs to be managed as a crisis.
A product reaching the market also creates commitments that continue throughout its commercial lifetime: warranty provisions, field service when on-site support is required, and post-market surveillance, which in regulated sectors is a legal obligation. Where products reach multiple geographies, each territory may carry its own regulatory requirements. These costs are manageable when planned for as part of the market model at stage two. They become a problem only when they are left out of it until after launch.
Working With a Development Partner
For technical leads managing NPD across hardware, electronics, firmware, and compliance, the structure of the development partner matters as much as its capabilities.
If you are planning a new electronic product and want to work through the viability questions early, contact 3Point1 to discuss your programme.
