The IoT product development process runs through a set of formal gates (EVT, DVT, and PVT) that every connected product has to clear before it ships. Those gates matter. They are how a team proves the design works, proves it can be manufactured, and proves the line can build it repeatably. What they are not […]
The IoT product development process runs through a set of formal gates (EVT, DVT, and PVT) that every connected product has to clear before it ships. Those gates matter. They are how a team proves the design works, proves it can be manufactured, and proves the line can build it repeatably.
What they are not is a learning schedule. Teams that wait for the next gate to find out what is wrong discover their biggest problems at PVT, where every change costs the most.
Treetown Tech runs the process the other way: we learn continuously, ahead of the gates, so that by the time a product reaches PVT the gate confirms what we already know.
A formal development process moves a connected product through five stages. Each one answers a different question, and each produces a decision about whether the design is ready to advance.
The first stage sets the system architecture: which sensors, which wireless protocol, how much processing happens on the device versus in the cloud, how the product is powered, and which certifications the target market requires. These decisions set the cost floor and are the hardest to reverse once a board is laid out around them.
EVT is the first functional hardware build, usually a small hand-built run. It answers whether the design works at all: the board powers up, the firmware brings it to life, the radio transmits, and the sensors return sensible readings.
DVT builds the near-final design with production-intent processes and materials and tests it against the full specification, including environmental range, mechanical fit, reliability, and the emissions and radio behavior certification depends on. Formal FCC and CE testing usually begins here.
PVT freezes the design and runs a production batch on the factory line to validate the manufacturing process itself: tooling, test fixtures, assembly instructions, and yield. Units from a clean PVT run are sellable product.
After launch, a connected product keeps moving. Firmware updates have to reach deployed devices, field data has to be watched for failures the lab missed, and returns have to feed the next revision.
A gate is a checkpoint. It tells you whether you have arrived somewhere; it does nothing to get you there. Trouble appears when a team treats passing the next gate as the plan, because then the gate becomes the moment of discovery. EVT reveals the sensor that behaves nothing like its datasheet. DVT reveals the enclosure that kills the antenna. PVT reveals the assembly step nobody can repeat at volume. Each discovery lands later and costs more than the last, and the ones that arrive at PVT can mean new tooling, a slipped launch, or a product that ships with a known compromise.
The gates were built to verify, not to learn. A program that leans on them for learning is running a long-cycle feedback loop on a product that needs a short-cycle one.
Our approach is to run fast, continuous learning loops underneath the formal stages. Between EVT and DVT, and well before PVT, we are putting working artifacts in front of the people who will judge them: engineers, operators, customers, and eventually end users. A rough electronics breadboard can test a sensing approach in days. Put a printed enclosure on a borrowed board and an operator will show you how they hold the device. One firmware build on an EVT unit can reveal whether the data your customer needs is the data you are collecting.
Speed here comes from the disciplines moving together. A loop that tests a meaningful product question usually touches the mechanical design, the electronics, the firmware, and sometimes the cloud side all at once. When those disciplines sit on one team, a finding on Tuesday can change all four design questions by Friday. When they sit in separate firms, the same finding waits for a meeting, a change order, and the next scheduled build.
The payoff is a quiet PVT. By the time the formal gate arrives, the design has been questioned, broken, and rebuilt many times at low cost. The gate does its job, verifying a product that is ready, instead of exposing one that is not.
Getting things in front of users early is easy to say and easy to do badly. The skill lies in matching what you show to who sees it and what you need to learn.
Fidelity has to fit the question. A looks-like model answers questions about form and handling and nothing about performance. A works-like breadboard answers performance questions and will mislead anyone judging the finished product by it. Show a rough prototype to someone expecting a finished one and you get feedback about polish instead of function. Show a polished model to someone testing function and you learn nothing useful at all.
The audience has to fit the stage, so to speak. Early loops belong with the people who can see past rough edges: internal engineers, a trusted customer contact, an operator who knows the job. Wider and less technical audiences come later, when the product is close enough to finished that their reactions mean something.
Timing and communication hold it together. Every person who sees an early artifact needs to know what it is, what it is not, and what question it is meant to answer. Skip that step and good feedback turns into noise, or worse, a customer forms an impression of the product from a prototype that was never meant to represent it.
Connected hardware adds its own limits. Iterations cost money and calendar time in a way software builds do not. A device cannot be handed to the public before it clears radio certification, and safety requirements shape what can go into anyone’s hands and when. Fast iteration in hardware is therefore a planning discipline as much as a building one: choosing which questions to answer with which build, so that each round of spend buys the most learning.
The formal stages are concept and architecture, EVT (Engineering Validation Test), DVT (Design Validation Test), PVT (Production Validation Test), and production with ongoing field support. EVT proves the design works, DVT proves it works as it will be manufactured, and PVT proves the factory can build it repeatably. These gates are necessary for a launch. The most effective teams also run faster learning loops underneath them so the gates confirm the design rather than reveal its problems.
EVT validates the design, DVT validates the design as it will be built, and PVT validates the manufacturing process. EVT uses small hand-built quantities to confirm basic function. DVT uses production-intent methods and tests against the full specification, including certification. PVT freezes the design and runs a production batch to prove yield and repeatability. A problem found at PVT that could have surfaced earlier is far more expensive to fix.
No. Waiting for PVT means your users see the product only after the most expensive point to change it. Fidelity-appropriate prototypes and early builds can reach the right people much sooner, as long as each audience understands what they are looking at and certification and safety limits are respected. The formal gates still happen; early user exposure makes sure nothing surprising reaches them.
Because the gates are usually spaced months apart and connected products generate questions every week. Running short learning loops between gates lets a team find and fix design problems while changes are still cheap. It also keeps the hardware, firmware, and cloud work aligned as the product evolves, instead of letting each discipline drift until the next formal build forces them back together.
A connected product on a validated hardware platform with standard connectivity can reach production readiness in roughly six to nine months. Custom hardware, novel sensing, and regulatory certification can extend that to twelve to eighteen months or more. Fast iteration between gates tends to shorten the schedule by removing late redesigns, which are the largest source of slip.
Building a connected product and want to learn faster than your gates allow? Treetown Tech’s IoT product development services run hardware, firmware, and cloud work as one team, iterating ahead of every gate. See the full picture in our guide to IoT product development, or tell us where your product stands.
Do you have a demanding application? Treetown Tech can turn your ideas into real-world solutions. Tell us more about your project, and we’ll help you identify risks, manufacture prototypes, validate designs, and even provide production support.
