Climate tech feasibility study: a step-by-step framework

A climate tech feasibility study should help us navigate both sides of the problem. We need to test the technology, but also the customer’s workflow, the regulatory path, the supply chain, the climate impact, and the economics of delivering the solution repeatedly. A promising prototype can still fail because installation takes too long, procurement is too cautious, a critical component is unavailable, or the buyer cannot justify the price.

The climate tech feasibility study stages below are a practical synthesis rather than a universal industry standard. They give us a sequence for turning a raw scientific or engineering concept into a clearer launch decision: what to test next, what evidence to collect, and which assumptions are still carrying too much weight.

Start by separating “can work” from “can become a business”

Early ClimateTech ideas often arrive as a technical claim:

• a new material stores more energy;
• a sensor detects methane leaks;
• a software model reduces building consumption;
• a process turns waste into a useful input;
• a device removes carbon from an industrial stream.

That claim may be true and still not describe a viable company. A feasibility study widens the lens. We are not asking whether the invention is interesting. We are asking whether it can survive contact with the physical, commercial, and institutional systems around it.

A useful first pass is to write down five hypotheses:

1. Technical hypothesis: the product performs the promised function under realistic conditions.

2. Customer hypothesis: a specific customer experiences a painful enough problem to seek a solution.

3. Adoption hypothesis: the customer can implement the product without unacceptable disruption, risk, or internal resistance.

4. Impact hypothesis: the solution creates a measurable environmental benefit against a defined baseline.

5. Economic hypothesis: the company can deliver that benefit at a price and margin that support the business.

These hypotheses are connected, but they should not be tested as if they were one thing. A lab result does not prove demand. A pilot does not automatically prove willingness to pay. A letter of support does not establish a repeatable revenue model. And a high technical readiness level does not mean the market is ready to purchase.

A climate venture becomes clearer when we stop asking, “Is this a good idea?” and start asking, “Which assumption could still make this idea fail?”

This change in language is small, but it gives the team somewhere practical to go.

Mapping technology maturity: beyond the TRL scale

The Technology Readiness Level, or TRL, is a useful way to describe how far a technology has moved from basic research toward a demonstrated commercial system. The commonly used scale runs from TRL 1 to TRL 9:

• TRL 1–4: research, early principles, component development, and laboratory validation;
• TRL 5–6: validation in a relevant environment and demonstration;
• later stages: system maturity, scale-up, and commercial operation.

The scale helps us avoid a common mistake: treating a successful bench test as proof that a product is ready for deployment. In clean energy, for example, the difference between a prototype and a demonstration unit is not just size. A full-scale commercial unit introduces installation constraints, maintenance demands, safety requirements, financing needs, supply-chain exposure, and operational data that a prototype may never reveal.

For a ClimateTech business viability check, document the current TRL using evidence rather than enthusiasm. A useful evidence file might include:

• test conditions and results;
• performance degradation over time;
• safety and reliability observations;
• the components that have not yet been tested together;
• operating conditions that differ from the target customer’s site;
• manufacturing assumptions and expected yield;
• maintenance, replacement, and installation requirements;
• unresolved regulatory or certification questions.

Then write the next readiness step in concrete terms. “Improve the technology” is too broad. “Run a six-month test with feedstock variability representative of three target facilities” is more useful because it tells us what evidence the team needs and what resources that evidence will require.

The gap between a working prototype and a deployable product

Climate technologies are often exposed to conditions that are messy, seasonal, or difficult to control. A water-treatment process may encounter changing contamination levels. An agricultural tool may face weather variation, different soil conditions, and fragmented buyers. An energy system must work alongside infrastructure that was designed before the new technology existed.

That is why the feasibility study should test not only peak performance but operating range. Ask:

• What happens when the input quality changes?
• What happens when the system is used by a non-specialist?
• How often does it need calibration or service?
• Which failure modes are safe, and which are expensive?
• Can the unit be repaired locally?
• Does the product still deliver value during the customer’s worst operating month?

A simple readiness table can keep the team from collapsing these questions into one score:

The goal is not to earn a perfect score. It is to expose the next constraint before the company spends heavily on scale.

Adoption readiness: the market has its own maturity curve

A technology can be technically ready while its market is not. Customers may lack the budget, staff, permissions, data, infrastructure, or confidence needed to adopt it. This is especially common in ClimateTech, where the buyer, user, asset owner, regulator, and climate beneficiary may all be different people.

The U.S. Department of Energy’s Adoption Readiness Level framework is helpful here because it treats adoption risk as a separate dimension from technical maturity. It examines 17 risks across four broad areas:

• value proposition;
• market acceptance;
• resource maturity;
• license to operate.

The scale also runs from 1 to 9. We do not need to use the framework mechanically, but its logic is valuable: commercialization readiness is multidimensional.

For each target segment, map the adoption path in plain language:

1. Who feels the problem first? This may be an operations manager rather than the executive who signs the contract.

2. Who owns the budget? The person who benefits from lower energy costs may not control capital expenditure.

3. Who can block implementation? Procurement, safety, IT, facilities, a utility, or a regulator may have veto power.

4. What must change in the customer’s routine? A solution that requires daily behavior change faces a different adoption challenge from one that runs in the background.

5. What evidence earns trust? Customers may ask for test data, warranties, insurance, certifications, references, or a performance guarantee.

6. What resources are required? Installation crews, grid access, feedstock, sensors, data systems, financing, and trained operators all belong in the feasibility picture.

This is where many founders discover that their first customer segment is not actually a customer segment. “Commercial buildings” is a broad environment. A more useful segment might be “mid-sized property operators with central energy management, recurring peak-demand charges, and an internal facilities team.” The narrower definition makes the adoption path visible.

Regulatory and institutional fit

Climate founders do not need to predict every future regulation, but they do need to identify the permissions required to operate. Depending on the product, the path may include environmental permits, electrical interconnection, building approval, product certification, data protection, waste handling, worker safety, or claims substantiation.

Create a regulatory map with three columns:

• Requirement: What approval, certification, or rule may apply?
• Decision-maker: Which agency, utility, customer department, or third party controls it?
• Evidence and timing: What must be submitted, tested, inspected, or documented?

Do not hide uncertainty behind a generic phrase such as “regulatory review pending.” Name the uncertainty. “We do not yet know whether the process will be classified as a waste treatment operation or a manufacturing process” is a real work item. It may affect facility design, operating costs, insurance, and the launch sequence.

The same applies to infrastructure. If a product depends on grid upgrades, specialized transport, a particular waste stream, or access to industrial sites, the dependency belongs in the feasibility study—not in a footnote.

Customer discovery: validating demand beyond the lab

Customer discovery is where we translate technical possibility into a problem someone is prepared to solve. The best conversations are not demonstrations disguised as interviews. They are investigations into how the customer currently handles the problem, what it costs, and why existing options have not worked.

A strong interview usually explores:

• the last time the problem occurred;
• the current workaround;
• the people involved in solving it;
• direct and indirect costs;
• operational or financial consequences;
• previous attempts to improve the situation;
• the purchasing process;
• the evidence required before a trial;
• the budget source;
• the conditions under which the customer would stop or expand use.

Avoid leading with the product. If we ask, “Would you use a device that cuts energy consumption by 20%?” many people will be polite. If we ask, “How did you manage your last demand spike, and what did it cost?” we are more likely to hear about the actual workflow.

A program-specific example from the Department of Energy sets an expectation of at least 30 customer-discovery interviews for participating Phase I awardees, unless equivalent work has already been documented. That is not a universal threshold for every ClimateTech startup. It is a useful reminder that a few friendly conversations are rarely enough to reveal patterns across buyers, users, and decision-makers.

Organizing the interview evidence

After each conversation, record observations under four headings:

• Observed behavior: what the customer actually does;
• Stated preference: what the customer says they want;
• Economic evidence: budget, cost, loss, or financial constraint;
• Adoption evidence: access to a pilot, data, decision-maker, site, or purchasing process.

This distinction matters because interest is not the same as commitment. A prospect may love the mission and still lack a budget. Another may not use climate language at all but have a strong operational reason to buy. We are looking for the problem that creates action, not just agreement.

The interview phase should produce a sharper customer and a more honest value proposition. “We help companies decarbonize” is not yet a buying reason. “We reduce refrigeration losses for regional food distributors without requiring a full equipment replacement” gives the team a problem, a user, and a constraint to test.

The U.S. Small Business Administration’s market-research guidance also points founders toward demand, market size, customer location, saturation, pricing, competitors, barriers to entry, and indirect competitors. For a ClimateTech startup, indirect competition often includes doing nothing, extending the life of existing equipment, hiring more staff, changing a process manually, or waiting for a regulation or grant program. Those alternatives deserve the same attention as named competitors.

The real competitor is often not another startup. It is the customer’s familiar workaround—and the risk of changing it.

Quantifying climate impact without making claims too early

Climate impact is not a decorative number for the pitch deck. It is part of product design, customer value, funding conversations, and sometimes regulatory exposure. But impact claims become fragile when the baseline, system boundary, and measurement method remain vague.

Start with a defined comparison:

• What would happen without the project?
• What product, process, or behavior is being displaced?
• Over what time period?
• For which geography and operating conditions?
• What is the functional unit—for example, one tonne of material processed, one megawatt-hour delivered, or one building-year of operation?
• Which emissions and environmental effects are included?
• What inputs, transport, construction, maintenance, and end-of-life stages matter?

ISO 14040 provides a life-cycle assessment structure built around four principal analytical phases:

1. goal and scope definition;

2. life-cycle inventory analysis;

3. life-cycle impact assessment;

4. interpretation.

Reporting, critical review, documentation, and limitations are part of making the result credible. Not every early-stage company needs a full ISO-compliant LCA before testing its first customer hypothesis. But every company making an environmental claim needs to understand what it is comparing and where the uncertainty lives.

For a project-level greenhouse-gas claim, ISO 14064-2:2019 addresses planning, baseline scenarios, relevant emission sources and sinks, monitoring, quantification, documentation, reporting, and data quality. The GHG Protocol Project Protocol is another established accounting tool for quantifying the greenhouse-gas benefits of mitigation projects.

At the feasibility stage, we can work with a provisional impact model. Label it clearly as provisional and list the assumptions. For example:

Be particularly careful with terms such as “carbon-negative,” “net-zero,” or “climate-positive.” They require more than a favorable calculation. We need a defined baseline, a transparent boundary, appropriate data, and an explanation of uncertainty. A lower-impact product is not automatically a zero-impact product, and a reduction in one part of a system may shift burdens elsewhere.

This rigor is not meant to slow the company down. It helps us discover whether the environmental benefit is large enough, durable enough, and visible enough to matter to the customer.

Synthesizing the business model: from evidence to a launch decision

Once the technical, adoption, customer, and impact work is underway, bring the findings into one lean business model. The SBA identifies nine common components:

• key partnerships;
• key activities;
• key resources;
• value proposition;
• customer relationships;
• customer segments;
• channels;
• cost structure;
• revenue streams.

For ClimateTech, these components need a physical-world layer. A software subscription may depend on sensor installation. A new material may depend on a contract manufacturer and a certification pathway. A carbon project may depend on monitoring, verification, land access, and long-term operational control. The business model should show those dependencies rather than treating them as future details.

Build the unit economics around the real deployment

Early estimates are allowed to be rough, but they should be explicit. Separate:

• one-time development costs;
• customer acquisition and sales costs;
• installation or integration costs;
• recurring operating costs;
• maintenance and replacement;
• insurance, certification, and compliance;
• energy, feedstock, logistics, or other variable inputs;
• financing costs where customers need capital to adopt.

Then ask what the customer is actually buying. Is it a device, a service contract, a guaranteed outcome, lower operating expense, compliance support, resilience, data, or access to financing? The answer affects pricing and the sales cycle.

A climate startup may have several possible revenue models:

• direct sale of hardware;
• hardware plus maintenance;
• subscription software;
• usage-based pricing;
• performance-based contracting;
• licensing;
• project development fees;
• savings share;
• financing or managed service.

Do not choose the most elegant model on paper. Choose the one that aligns with the customer’s budget authority, risk tolerance, and ability to measure the outcome. A performance-based model can reduce adoption friction, but it also places more measurement and balance-sheet pressure on the startup. A hardware sale may generate earlier revenue but leave the customer carrying more performance risk.

Make the next experiment decision-specific

A feasibility study should end each stage with a decision, not just a growing document. The decision might be:

• continue with the same customer segment;
• narrow the product scope;
• change the deployment model;
• run a field demonstration;
• pursue a different revenue model;
• pause until a regulatory or supply-chain question is resolved;
• stop because the impact or economics do not justify the complexity.

A helpful experiment has four parts:

1. Assumption: what must be true?

2. Test: what will we do to learn about it?

3. Evidence: what will count as a meaningful result?

4. Decision: what changes if the result is positive, mixed, or negative?

For example, the assumption may be that a food distributor will pay for a monitoring system if it reduces spoilage without adding daily work. The test could combine interviews, a short site deployment, and a review of purchasing authority. The evidence should include measured workflow impact and a commercial action—not only verbal enthusiasm. The decision might be to proceed to a paid pilot, redesign the interface, or move to a different segment.

This keeps the team from collecting evidence that feels impressive but does not change the launch path.

A practical sequence for the first 90 days

There is no universal duration for a ClimateTech feasibility study. The timeline depends on the technology, test environment, customer access, regulatory pathway, and availability of field data. Still, a first 90-day cycle can create useful momentum if each period has a clear purpose.

Weeks 1–2: define the claim and the constraints

Write the technical claim, target customer, intended use case, baseline, and known dependencies. List the assumptions that would most seriously damage the venture if they proved false.

At this point, avoid polishing a broad mission statement. The team needs a narrow problem definition and a short list of risks.

Weeks 3–6: speak with the system, not just the buyer

Conduct customer interviews across users, budget owners, technical reviewers, procurement, and potential implementation partners. Map the current workflow and the alternatives. Begin regulatory and supply-chain conversations in parallel.

If access is difficult, that is itself evidence. A product that cannot reach the people who must approve, install, operate, or pay for it may need a different go-to-market design.

Weeks 5–8: test the relevant environment

Move beyond controlled performance where possible. Test the inputs, operating conditions, maintenance requirements, and data collection process that the customer will actually encounter. Update the TRL assessment based on evidence.

At the same time, create a first impact model with explicit boundaries and assumptions. You do not need to pretend that the model is final. You do need to make it inspectable.

Weeks 8–12: connect the evidence to a commercial experiment

Choose the smallest credible pilot, paid trial, demonstration, or integration test that can answer the next commercial question. Define who pays, what the customer must provide, how success is measured, and what happens after the pilot.

Then review the whole picture together. A technical improvement that doubles installation time may weaken the business. A customer segment with strong demand may require a certification path the team cannot yet support. A high-impact use case may not have a workable route to market. These connections are the reason the stages belong in one feasibility framework.

The study is successful when the next move becomes obvious

A good climate startup feasibility assessment does not produce certainty. It produces alignment between the questions the team is asking and the evidence the venture actually needs.

By the end, we should be able to say:

• what the technology can do today and under which conditions;
• what must be demonstrated before deployment;
• who has the problem and who controls the purchase;
• which adoption risks could block the sale;
• what permissions, partners, and infrastructure are required;
• how the environmental benefit is defined and measured;
• how the company makes money without hiding the cost of delivery;
• what experiment comes next.

That is a much more valuable outcome than a polished presentation built around a single readiness number.

Start with one page this week: five hypotheses, one target customer, one baseline, and the next experiment that could disprove your favorite assumption. Then bring the technical and commercial evidence into the same conversation. That is how we move from a promising climate idea toward a launch path that can hold up in the real world.