Climate startup MVT: a four-stage testing roadmap

That question is more useful than “How do we build the MVP?” for most climate founders. A software MVP can sometimes place a rough product in front of users within weeks. Climate hardware rarely gives us that luxury. The system may depend on materials, manufacturing partners, field conditions, certification, installation, maintenance, and a buyer whose budget is tied to a long procurement cycle. Building the whole thing before testing the riskiest assumption is not momentum. It is an expensive way to postpone learning.

A climate startup minimum viable test, or MVT, gives us a more disciplined path. Instead of simulating the entire product experience, we isolate the smallest critical hypothesis—the atomic unit of the idea—and test that directly. The goal is not to make a miniature version of the final product. The goal is to learn whether the next major investment is justified.

For climate tech, that means validating three realities at the same time:

• someone has a strong enough problem to pay for a solution;
• the solution can work in the physical and operational conditions where it will be used;
• the expected climate impact is credible, measurable, and meaningful.

These realities are connected, but they are not interchangeable. A technically elegant device can fail because the buyer does not control the budget. A product with clear demand can fail because installation takes three days instead of three hours. A promising emissions story can weaken when the full lifecycle of materials, transport, and maintenance is included.

The MVT framework helps us navigate those gaps before they become a product roadmap.

Beyond the MVP: test the assumption, not the entire dream

The traditional MVP is often misunderstood as “build the smallest complete product.” In climate tech, even the smallest complete product may require a supply chain, a field deployment, safety documentation, software integration, and a service model. That is too much to put on the first learning cycle.

An MVT asks a narrower question:

What is the single riskiest belief behind this business, and what is the cheapest credible test that could challenge it?

This is a shift from building to learning. We are not trying to prove that the entire company is ready. We are trying to remove uncertainty in the right order.

Gagan Biyani’s MVT framework groups risky assumptions into five broad categories:

1. Value proposition: Does the customer experience a problem severe enough to change behavior or allocate budget?

2. Execution: Can the proposed solution work reliably with the available materials, energy inputs, infrastructure, and operating conditions?

3. Marketing and sales: Can we reach the person who influences or approves the purchase, and can they move through the buying process?

4. Market size: Is there a sufficiently large group of customers with the same urgent need, rather than a handful of interesting exceptions?

5. Profit margins: Can we deliver, install, support, and replace the product at a cost that leaves room for a durable business?

A single test can touch several categories, but we should know which one it is designed to answer. “We spoke to customers and they liked it” is not a result. “Eight of twelve facility operators confirmed that reducing peak-load charges is a funded priority, and three agreed to share twelve months of interval data” is much closer to evidence.

How to choose the first MVT

Start with an assumption inventory. Write down every statement your business currently treats as true:

• Commercial buildings will pay for automated load shifting.
• The target site has the electrical connection required for the system.
• Operators can install the equipment without shutting down critical operations.
• The sensor remains accurate in the temperature and humidity range of the site.
• The buyer can approve a pilot within the current budget cycle.
• The avoided emissions justify the cost and operational complexity.
• The system can be serviced without sending a specialist across the country.

Then rank those assumptions by two factors: how damaging failure would be, and how quickly you can test them.

A founder developing a low-carbon industrial heat system may believe the main risk is thermal efficiency. But if the plant manager cannot authorize a pilot without corporate procurement and a two-year safety review, the first MVT may need to test access and adoption—not heat performance. Likewise, a team building methane-monitoring hardware may need to validate whether operators will act on the data before refining the sensor enclosure.

A useful test has a clear pass condition. It does not need to be a universal threshold, and climate sectors vary too much for one number to work across energy, agriculture, buildings, mobility, and materials. But the team should decide in advance what evidence would justify the next step.

The best first test often feels almost too small. That is a feature, not a flaw. If we can test a decisive assumption with ten interviews, a material sample, a spreadsheet model, or one monitored site, we should do that before commissioning a production-grade prototype.

The four-stage hardware validation roadmap

Climate technology rarely moves from “idea” to “finished product” in one clean jump. The physical validation path usually develops through four broad stages: pre-alpha, alpha or engineering validation, beta through EVT and DVT, and pilot production through PVT.

The names vary between companies, but the logic is consistent. Each stage should answer a different class of question. The mistake is allowing a prototype to advance simply because it exists.

1. Pre-alpha: test the core assumption before engineering complexity

Pre-alpha, sometimes called pre-EP, is where we test whether the underlying concept deserves engineering effort.

At this stage, the artifact may be a lab setup, a material sample, a manual process, a simulation, a rig assembled from off-the-shelf parts, or even a service delivered by hand behind the scenes. The important thing is that the test isolates the mechanism that creates value.

For a carbon-mineralization startup, that might mean demonstrating the reaction under the temperature and feedstock conditions found at a target industrial site. For an agricultural monitoring product, it could mean proving that a specific measurement correlates with the farm decision the buyer actually wants to make. For a building-energy system, it might be a manual intervention using existing controls rather than a new device.

Pre-alpha should help answer:

• Does the physical or scientific principle work outside ideal conditions?
• Which variables most strongly change the result?
• What does failure look like?
• Is the outcome valuable in the language of the customer, not only in the language of the lab?
• What must be measured now to support a later climate-impact claim?

This is also the right moment to test the problem with real users. Customer discovery interviews should not be used to collect compliments about a concept. Ask about the last time the problem occurred, what it cost, who responded, what workaround they used, and what made the issue difficult to solve.

We are looking for behavior, not imagination. “That sounds useful” is weak evidence. “We currently lose two production shifts each quarter and have an approved budget line for monitoring” is much stronger.

2. Alpha or engineering validation: prove the requirements can be met

Once the core assumption has survived early testing, the next question is whether we can turn it into a system that meets customer requirements.

An alpha or engineering prototype is not expected to be beautiful. It may be bulky, manually calibrated, or assembled with components that will never appear in the final product. Its job is to reveal engineering constraints.

At this stage, define the operating envelope rather than celebrating a best-case result. If a device performs well at 20°C in a clean laboratory, that tells us very little about a dusty installation exposed to vibration and temperature swings. If a thermal system reaches its target output only when supplied with premium-quality feedstock, the feedstock requirement belongs in the business model.

Engineering validation should bring technical and commercial conversations together. Ask customers what “usable” means in practice:

• How long can installation take before operations are disrupted?
• What certifications or safety approvals are required?
• Who owns maintenance?
• What data format must connect to existing systems?
• What happens when the device fails at 2 a.m.?
• Which performance metric is tied to a budget, a compliance obligation, or a production result?

These questions can change the product more than another round of internal brainstorming. A system that saves energy but requires weekly manual calibration may not be a viable product for a small facilities team. A solution that performs well but creates a new reporting burden may face resistance even when the climate case is compelling.

3. Beta, EVT, and DVT: validate the product outside the friendly lab

The beta phase moves the product toward external testing, certification, and real-world use. Engineering Validation Testing, or EVT, asks whether the design performs against its technical requirements. Design Validation Testing, or DVT, pushes further: can the design work reliably in the conditions and use patterns expected in the market?

For climate hardware, this is where hidden assumptions become expensive. A component may degrade faster than expected. A sensor may drift. A housing may collect condensation. A software integration may work with one building-management system but not another. The product may require an installer skill set that is rare in the target region.

External testing should be designed to expose those weaknesses, not to produce a flattering demonstration. Choose sites that represent the intended market, including the inconvenient variables. If the product is meant for agricultural use, test in the weather and connectivity conditions that farmers actually face. If it is intended for industrial facilities, include the shift patterns, maintenance constraints, and safety procedures that shape daily operations.

This is also the stage to make claims more precise. Avoided emissions are not a single number floating above the product. They depend on the baseline system, usage patterns, grid or fuel mix, product lifespan, maintenance, and end-of-life treatment. Early lifecycle assessment does not need to be perfect, but it should make the boundaries visible.

4. Pilot production and PVT: validate that the company can make the product

A successful prototype can still be an unsuccessful business if every unit is hand-built by the founding team.

Production Validation Testing, or PVT, is the final validation phase before mass production. A pilot production run is typically around 5% to 10% of a full production run. The point is not simply to make more units. It is to test whether the supply chain, assembly process, quality controls, packaging, installation, and service model can work together.

PVT may reveal that:

• a key component has a six-month lead time;
• a tolerance that was acceptable in the lab creates a high defect rate on the assembly line;
• the packaging cannot protect the product during shipping;
• installation takes twice as long when performed by a partner;
• field technicians need a diagnostic tool that has not been designed;
• a small design change creates a new certification requirement.

These are not manufacturing details to postpone until after the market is “proven.” They shape price, delivery timelines, customer trust, and cash requirements. In a hardware-heavy climate company, execution risk is part of product-market fit.

In climate hardware, validation is not one gate marked “works” or “doesn’t work.” It is a sequence of increasingly honest questions about demand, performance, deployment, impact, and repeatability.

Navigating the Valley of Death without confusing patience with progress

Many climate startups face a development path measured in years rather than months. Physical systems, regulatory approvals, infrastructure dependencies, and manufacturing constraints can stretch the journey through the Valley of Death to roughly two to ten years.

That timeline does not mean we should wait passively for the product to mature. It means the company needs a sequence of fundable learning milestones.

A strong roadmap separates progress into evidence that can be reviewed before full commercialization:

1. Problem evidence: a clearly defined customer segment, repeated pain, and a known economic or operational consequence.

2. Mechanism evidence: a test showing that the scientific or technical principle works under relevant conditions.

3. Deployment evidence: a customer site, partner environment, or controlled field setting where the solution fits the workflow.

4. Impact evidence: a defensible method for measuring the environmental outcome against a stated baseline.

5. Repeatability evidence: multiple deployments or production units showing that results are not dependent on founder intervention.

6. Commercial evidence: a path from pilot to paid rollout, with an identified buyer, budget, procurement process, and service model.

Each milestone should unlock the next investment. If the team cannot explain what a new round of funding will help prove, the roadmap may be organized around activities rather than risk reduction.

Cash planning matters here. A climate company can run out of money while still having a technically promising product because the financing schedule does not match the validation schedule. Long-lead components, certification costs, pilot-site preparation, insurance, installation labor, and warranty reserves should appear in the plan before they become surprises.

The same principle applies to partnerships. A corporate pilot is not automatically a customer. A memorandum of understanding is not the same as a purchase order. A demonstration funded by an innovation budget may not convert into a deployment funded by an operating budget.

During customer discovery, ask what happens after the pilot:

• Who owns the result?
• What evidence does procurement require?
• Which budget pays for the next phase?
• What internal team must approve it?
• What would cause the customer to stop?
• Can the deployment expand to other sites without a new custom project?

The answers will help us distinguish a learning partnership from a repeatable sales motion.

For a deeper look at the commercial and operational questions behind an early climate pilot, you can also use this guide to climate transition planning as a companion reference.

Bring climate impact into validation early

Climate impact should not be added to the pitch deck once the product is ready. It belongs in the MVT because it can change the target customer, the product design, and the economics.

Investors, including Article 9 venture funds with sustainable investment objectives, may examine measures such as Climate Performance Potential and lifecycle assessment. These frameworks are not interchangeable universal scorecards, and there is no single CPP template accepted by every climate investor. But the underlying expectation is clear: the company should be able to explain what impact it creates, compared with what baseline, and with which assumptions.

A useful early LCA does not need to pretend to know everything. It should be transparent about what is included and what remains uncertain.

For example, a product may avoid emissions during use but require energy-intensive materials, frequent replacement parts, or long-distance servicing. A software layer may reduce energy consumption, but only if customers actually change operating behavior. A recycling technology may process waste with lower emissions than disposal, but the result depends on collection logistics, contamination, and the destination of recovered materials.

At the MVT stage, map four elements:

• Baseline: What would the customer do without the product?
• Intervention: What exactly changes when the product is adopted?
• Measurement: Which inputs and outputs can we observe directly?
• Boundary: Which lifecycle stages are included in the current claim?

Then test whether the customer values the measured outcome. A buyer may care about emissions, but they may purchase because the same intervention reduces fuel costs, protects against regulation, improves uptime, or gives them credible reporting data. Understanding that alignment does not weaken the climate mission. It helps the solution survive long enough to create impact.

Be especially cautious with claims that depend on future scale. A technology may have impressive climate performance potential at large deployment volumes while producing modest impact in its first commercial configuration. That is not a reason to hide the ambition. It is a reason to distinguish current measured performance from future potential.

Securing the first pilot: turn access into field evidence

The first pilot customer is often treated as a sales milestone. For a climate startup, it is also a validation instrument. The right pilot gives us field data, operational learning, evidence for investors, and a clearer view of whether the product can move toward repeatable adoption.

The wrong pilot becomes a custom consulting project that proves only that the founding team can work very hard.

Before agreeing to a pilot, define its learning contract. Put the following in writing with the customer:

• the operational problem being tested;
• the baseline period and comparison method;
• the performance metrics;
• the site conditions and exclusions;
• who provides data and how often;
• what counts as a successful deployment;
• what happens if the system underperforms;
• the timeline for reviewing results;
• the commercial path if the agreed outcome is achieved.

The pilot should be narrow enough to finish and meaningful enough to influence a purchase decision. If the team attempts to prove every benefit at once, the project will become difficult to interpret. Select one primary outcome and a small number of supporting measures.

Suppose a startup offers an energy-management system for cold-storage facilities. The primary outcome might be reducing peak demand without affecting product temperature. Supporting measures could include installation time, operator interventions, system uptime, and data completeness. “Improved sustainability” is not a pilot metric. It is a conclusion that must be built from observable changes.

Choose an early adopter for more than enthusiasm. Look for a customer with:

• a visible and costly problem;
• authority or access to approve a test;
• data that can establish a baseline;
• operational capacity to support the deployment;
• a reason to act before the broader market is ready;
• a credible path to expansion if the result is positive.

Early adopters are not necessarily the biggest companies. A large enterprise may have excellent facilities and a strong climate target but take eighteen months to approve a new vendor. A smaller regional operator may have fewer sites but a direct line between the problem, the budget, and the decision-maker.

During the pilot, resist the urge to repair every difficulty silently. Document the extra installation work, the missing data, the training requests, and the moments when the customer hesitates. Those details are part of product discovery. If the team hides them, the next customer will uncover them at a higher cost.

After the pilot, hold two conversations. The first is about results: what changed, what did not, and how confident are we in the measurement? The second is about buying: what would need to be true for the customer to pay, expand, or recommend the product internally?

That separation is valuable. A customer can be impressed by the technical result and still decline to buy because the implementation burden is too high. Conversely, a customer may buy a modest version of the product because it solves an urgent operational problem, even when the full climate benefit will take time to realize.

The next action is smaller than the roadmap

A climate startup MVT is not a miniature version of a finished company. It is a carefully chosen learning step that prevents the team from spending months validating the wrong thing.

Start this week by writing down the five riskiest assumptions in the business. Put each one into a sentence that could be proven wrong. Then choose the assumption that combines the highest consequence with the lowest-cost credible test.

That might mean scheduling ten problem-discovery interviews with budget owners. It might mean running a bench experiment under field-relevant conditions. It might mean shadowing an installer, costing the service model, or building an early lifecycle-impact estimate with explicit boundaries. It might mean asking a prospective pilot customer to commit data access and a decision date rather than offering another enthusiastic conversation.

The aim is not certainty. Climate companies cannot buy certainty in advance. The aim is alignment between what we believe, what we have actually tested, and what we are asking the next dollar, partner, or pilot site to prove.

When each validation stage answers a distinct question, the path through the Valley of Death becomes easier to navigate. The product may still take years. The learning should not.