Where Are You in the Product Development Funnel?

No two electronics projects start in the same place. Learn how to locate your project in the development funnel — and what to define before engineering begins.

I’ve had some version of this conversation with nearly every new client we’ve worked with over the past 20+ years. They come to us at different stages, from different industries, with different levels of technical depth on their team — and almost every one of them asks some variation of the same question: where do we begin?

The honest answer is that it depends entirely on where you actually are. And figuring that out together is usually the most valuable thing we do before any engineering work starts.

Product development doesn’t start with a PCB schematic. It starts with clarity.

That’s a lesson most engineering teams learn the hard way — usually after project scope blows up mid-project from late user feedback, a supplier comes back with an impossible lead time, or a regulatory submission gets kicked back because EMI far exceeds certification boundaries. The technical work is rarely where projects go sideways. It’s the upstream decisions — or the absence of them — that create the downstream pain.

This post is about how to think about where your product development project actually is, what you need to move it forward, and how to avoid the most common traps in new product development.

Why There’s No Universal Starting Point

Search “product development methodology,” and you’ll find a long list of frameworks: Stage-Gate, V-Model, Agile Hardware, Lean Product Development, Design for Six Sigma. Every OEM, every tier-one supplier, and every contract engineering firm has a preferred process. Most of them are useful. None of them are universal.

What actually determines where your project needs to begin isn’t the framework — it’s the state of your inputs. Two companies can both be early-stage and occupy completely different positions. One has a detailed product requirements document, a system block diagram, and a target BOM cost. The other has a compelling use case and a concept sketch. Both are valid starting points. They’re just not the same project.

The product development funnel exists to help you identify where you are honestly. Not where you wish you were, or where your stakeholders are pressuring you to be — where you actually are. That assessment determines everything that follows: what needs to happen next, in what order, how long it will realistically take, and what kind of investment dollars future stages could require.

The Product Development Funnel, Explained

Think of product development as a narrowing process. At the top of the funnel the aperture is wide — possibilities are open, decisions are reversible, and the cost of change is low. As you move down, each decision closes off alternatives, ideally reduces risks, and raises the cost of reversing course. By the time you’re in DVT or pilot run production, changes are really expensive. If you’re making changes at a contract manufacturer, costs can be program-ending.

The discipline of good product development is making the right decisions at the right stage — not rushing past critical checkpoints because there’s schedule pressure, and not over-engineering early-stage work that hasn’t been validated yet.

The electronics product development funnel moves through these phases.

Product Definition and Requirements: This is where the product becomes real on paper. A solid requirements document covers functional requirements, environmental specifications, regulatory targets, use case scenarios, and interface definitions. Many teams underinvest here and pay for it repeatedly throughout the rest of the development cycle.

Concept Development and Architecture System-level thinking: what are the major subsystems, how do they interface, and where are the technical risks? This is where you build a block diagram, evaluate critical components, identify long-lead items, and make early decisions about processor architecture, communication protocols, and power topology. Getting these calls right — or at least making them consciously — reduces risks and saves significant time later.

Proof of Concept and Feasibility (POC): Before committing to a full custom hardware design, validate the riskiest assumptions first. Can the sensor perform to spec in the target environment? Does the pre-certified wireless module work at the required range?  A focused feasibility effort at this stage is one of the highest-return activities in product development.

Engineering Validation Testing (EVT): The first hardware builds — schematic capture, PCB layout and prototyping, bring-up, and initial functional testing. Is the target BOM cost within an achievable range using available components? EVT is about proving the design works in a controlled environment. It is not a production build nor a perfect prototype stage. Treating it like one is a common and costly mistake.

Design Validation (DVT): DVT validates that the design meets its requirements under real-world conditions in the desired form factor: temperature cycling, vibration, EMC, ingress protection, worst-case voltage and load scenarios. This is also where pre-compliance testing happens and where regulatory submissions, timing, and costs come into focus. The design is locked.

Production Validation (PVT) and Transfer: DFM and DFT reviews happen here if they haven’t been built into the process already. The focus shifts to manufacturability, production testing coverage, and yield. A smooth handoff to a contract manufacturer requires complete documentation — assembly drawings, test specifications, approved vendor lists, and a bill of materials substitutions require scrutiny and potentially more testing DVT prototype testing before pilot runs can begin.

What You Can Define Without an Engineering Team

One of the most persistent myths in product development is that you need a technical partner before you can make meaningful progress. In most cases, that’s not true — and believing it causes teams to outsource thinking they should be doing themselves.

Before any engineering engagement begins, a product owner or program manager can — and should — define quite a bit on their own.

Requirements and Environment: What must this product do, and what must it never do? What are the operating temperature range, humidity exposure, ingress protection requirements, shock and vibration profile, and altitude range? What certifications apply — UL, CE, FCC Part 15, FDA 510(k), IEC 60601, MIL-STD-810H or 461 or RE102?

Use Case and User Context: Who uses this product, in what environment, and what does a successful interaction look like? Where does the current market fall short, and what specific problem does your product solve that competing products don’t?

Voice of Customer: What do end users actually care about — not what the sales network assumes they care about? This doesn’t require engineering expertise. It requires talking to customers and being willing to hear things that challenge your assumptions.

System-Level Thinking: You don’t need to be an electrical engineer to sketch a block diagram. What are the major functional blocks — power input, processing, sensing, actuation, communication, user interface? How do they connect? Where are the interfaces to external systems? A rough block diagram, even an imprecise one with question marks is enormously useful as a communication tool.

Business Parameters: What is the target unit cost at volume? What does Year 1 production look like — 500 units or 50,000? Are there physical constraints on size, form factor, or enclosure type? What is the program timeline, and where are the hard gates? What are the NRE and capital funding situations?

None of this requires a PCB designer or a firmware engineer to produce. But all of it directly determines the scope, cost, and timeline of the engineering work that follows. Teams that do this work upstream move faster and spend less. Teams that skip it hand the uncertainty to their engineering partners pay for the time it takes to work through it.

Where Technical Expertise Becomes Essential

There’s a point in every program where the decisions stop being definable by business logic alone and start requiring deep technical judgment. That’s where outside engineering expertise earns its place.

The highest-risk decision points in electronic product development tend to cluster in a few areas.

Processor and Microcontroller Selection: The choice of processor architecture shapes firmware complexity, memory requirements, toolchain, available peripheral support, long-term component availability, and power consumption. Getting this wrong early is painful to unwind.

Communication Protocol and Connectivity Architecture: Wired or wireless? Which protocol — CAN, Modbus, EtherCAT, BLE, Wi-Fi, LTE-M, LoRaWAN? Each has different implications for range, latency, power budget, antenna design, regulatory certification, and infrastructure requirements. These decisions interact with each other in ways that aren’t always obvious until you’re deep in bring-up.

Power Architecture and Thermal Management: Power subsystem design — input protection, regulation topology, battery management, thermal dissipation — is an area where experienced engineers make very different decisions than less experienced ones. Mistakes here show up as field failures, safety concerns, and regulatory holds.

EMC and Signal Integrity: EMC is often treated as a compliance checkbox at the end of development. It should be a design input from the start. PCB stackup, component placement, trace routing, filtering, and shielding decisions made early either solve EMC problems before they exist or create expensive ones that surface at pre-compliance testing.

Regulatory Pathway and Design Controls: For medical devices, this means understanding FDA classification, predicate selection, and design history file requirements before the first schematic is drawn. For industrial products seeking UL or CE marks, it means understanding which standards apply and designing to them from the beginning — not retrofitting compliance after the fact.

The Questions Worth Asking Before You Engage an Engineering Partner

Whether you’re issuing an RFQ, evaluating engineering firms for contracts, or deciding how to staff your next program, the quality of the conversation depends on the quality of the questions.

How does the firm handle design ownership and IP? Your agreement should be explicit about who owns what — schematics, firmware source code, test fixtures, and manufacturing documentation.

What does their handoff process look like? A good engineering partner produces documentation that doesn’t require their continued involvement to manufacture or support. Ask to see examples of what they deliver at the end of a program.

How do they staff projects? Senior engineers doing design review is a different engagement than senior engineers doing the work. Know which one you’re getting before the project starts.

What’s their pre-compliance testing capability? Teams that can run EMC, environmental, and functional testing in-house catch problems earlier and at lower cost than those that rely entirely on third-party labs.

How do they manage component availability? In the current supply chain environment, component selection strategy and obsolescence planning are design engineering decisions, not procurement decisions. Ask how they think about this at the schematic stage.

Who We Work With

Since 2002, DE Design Works has partnered with engineering teams across industrial, medical, military, and technology R&D markets — anywhere complex electronic product development demands reliable, senior-level expertise.

Industrial manufacturers building ruggedized control systems, IoT-connected field devices, and custom gateway hardware rely on us to bring PCB design, embedded firmware, and industrial communications protocols together under one roof. We understand the reliability and lifecycle demands of B2B industrial environments, including the component obsolescence challenges that come with long-production-run products.

Medical device teams including OEMs to specialized startups — engage us when a product requires disciplined hardware-software integration alongside compliance awareness. We design with IEC 60601, FDA regulatory pathways, and design history file requirements in mind from the start, not as an afterthought.

Military and defense-adjacent programs bring DE in for electronics that must perform in demanding environmental conditions. Our team designs for MIL-SPEC temperature ranges, vibration, shock, and EMI environments, and we support pre-certification testing and certification documentation where programs require it.

Technology R&D teams use us to accelerate new technology integration — whether that’s a novel sensor interface, a custom IoT edge device, a high-power embedded system, or a platform migration driven by component obsolescence or connectivity modernization.

Across all of these engagements, the dynamic is consistent: our clients have capable internal teams that need a specialized outside resource to close a gap in bandwidth, in a specific technical discipline, or in both. We work alongside internal teams to fill that gap and keep programs moving forward.

We’re headquartered in the St. Louis, Missouri metro area. Our entire engineering team is US-based.

Starting a Conversation

If you’re preparing for an engineering services engagement — whether you’re issuing an RFQ, evaluating outside development partners, or trying to scope what your project actually requires — we’re a useful early call.

Bring what you have. We’ll help you figure out what you need.

Tell us about your project