Climate customer discovery: a four-stage interview project

That decision gets harder when the product is technically impressive, the climate problem is undeniably real, and early conversations are full of encouragement. A facilities director says the idea is interesting. A sustainability lead asks to see a prototype. An investor likes the category. None of that proves a buyer will change a workflow, approve a budget, or carry the internal risk of adopting something new.

Customer discovery is the discipline that separates a real commercial signal from polite enthusiasm. In climate businesses, that discipline has to account for unusually long sales cycles, multiple stakeholders, operational constraints, procurement rules, and the gap between the person who feels the problem and the person who can pay to solve it.

A practical climate customer discovery interview process can be run as a four-stage project over three to four weeks, with roughly 15–20 conversations. That is not enough to prove product-market fit. It is enough to expose weak assumptions before they become a product roadmap, a hiring plan, or a very expensive pilot.

The 43% failure trap: why ClimateTech needs structured discovery

CB Insights has attributed 43% of startup failures to poor product-market fit: companies build something customers do not actually need. The figure is not a prediction for any individual company, and it does not capture every way a climate startup can fail. But it points to a particularly uncomfortable truth: the technical solution is rarely the whole business.

Climate founders often begin with a legitimate problem:

• Buildings waste energy.
• Industrial processes emit too much carbon.
• Farms need better water or fertilizer management.
• Fleets need to transition away from fossil fuels.
• Manufacturers need more reliable low-carbon materials.
• Companies need credible emissions data rather than another reporting spreadsheet.

The mistake is moving directly from a broad problem to a specific product. A founder may assume that because an organization cares about emissions, it will buy a tool that reduces emissions. In practice, the purchasing decision may depend more on payback period, maintenance requirements, insurance, integration with existing systems, compliance exposure, staff capacity, or whether the project can be approved within the current budget cycle.

Climate customer discovery is therefore not a popularity exercise. You are not asking whether people like the mission. You are testing whether a particular customer has a painful, active problem and enough authority, urgency, and resources to address it.

The original Customer Development methodology, introduced by Steve Blank in 2003, treats customer discovery as the first stage before customer validation, customer creation, and company building. The logic remains useful for ClimateTech, with one important adjustment: environmental value and commercial value must be examined together, but they should not be treated as the same thing.

A solution can have a strong emissions-reduction case and still fail commercially. It can also sell successfully while producing a weaker climate outcome than the founder claims. Discovery does not eliminate either risk. It gives you a better chance of seeing both before scaling.

A real climate problem is not automatically a viable customer problem. Discovery begins when you separate the two.

Stage 1: Define the cohort and the problem hypotheses

The first stage is not writing a better interview script. It is deciding whom you are actually trying to understand.

“Companies that want to decarbonize” is not a customer segment. Neither is “sustainability teams.” These labels are too broad to support useful interviews because they mix different incentives, budgets, workflows, and levels of urgency.

Start with a narrow cohort. A cohort might be:

• Operations leaders at mid-sized food manufacturers managing refrigeration costs.
• Fleet managers responsible for regional delivery vehicles.
• Sustainability managers at property companies with a mandated emissions target.
• Procurement teams sourcing lower-carbon construction materials.
• Municipal energy managers overseeing public buildings.
• Finance or risk leaders responsible for energy price exposure.

The right cohort is not necessarily the group most excited by your idea. It is the group that experiences the problem often enough to describe its current behavior in detail.

For each cohort, write a small set of problem hypotheses. Keep them falsifiable. A useful hypothesis describes a customer, a situation, a current workaround, and a consequence.

For example:

• Property operators lose money because they cannot identify which building systems are causing avoidable energy use.
• Fleet managers delay electrification because they cannot confidently match charging capacity to route requirements.
• Manufacturers struggle to adopt lower-carbon inputs because procurement cannot verify supply consistency and cost.
• Sustainability teams spend excessive time assembling emissions data that still does not satisfy internal finance or external reporting needs.

These are starting points, not conclusions. The interview project exists to challenge them.

Separate the problem owner from the economic buyer

ClimateTech commonly has more than one relevant stakeholder:

Do not assume that one interview with a sustainability lead tells you how procurement, operations, IT, and finance will react. It may tell you that the sustainability lead wants progress. It may not tell you who can authorize a contract.

This is where many founders lose time. They interview the easiest people to reach, then build around the enthusiasm of one department. Later, the product reaches procurement and meets the real market.

Define what you need to learn

A strong discovery project has learning goals, not just a target number of calls. Before recruiting, write down the assumptions that could change your direction.

They may include:

• How does the customer recognize the problem today?
• How often does it occur?
• What does it cost in money, time, risk, or missed opportunity?
• Who owns the current workaround?
• What has the customer already tried?
• Why did that approach fail, stall, or remain in place?
• What event would make the problem urgent?
• Which budget would fund a solution?
• What evidence would the customer need before running a pilot?
• What would make the customer refuse even a low-cost trial?
• How would the organization measure climate impact?
• Which claims would require third-party verification or internal approval?

The last two questions matter because climate products have two validation layers. The customer must believe the product creates operational or financial value. The company must also be able to explain how the environmental outcome is measured. If you postpone the second question, you can end up with a product that sells on a climate promise it cannot substantiate.

Stage 2: Run the three-week interview sprint

A standard customer discovery sprint takes three to four weeks. A workable rhythm is 15–20 interviews across one or more cohorts, with conversations conducted in weekly cycles rather than saved up for one final batch.

The weekly structure creates useful pressure. You recruit, interview, review notes, revise the next set of questions, and test whether a new insight holds across additional conversations. This is different from conducting a large batch of interviews with a fixed script and discovering afterward that you were asking the wrong questions.

Each interview will usually take 30–45 minutes. That is long enough to understand a workflow without turning the call into a workshop or sales presentation.

Recruit for relevance, not compliments

The best participant is not the person who says your product sounds exciting. It is someone who has recently dealt with the problem you are investigating.

Recruitment can begin through existing networks, industry associations, implementation partners, former colleagues, targeted outreach, or introductions from people who understand the sector. Ask for a conversation about the current process, not feedback on an undeveloped product.

A simple invitation should explain:

• Which operational area you are researching.
• Why the person’s experience is relevant.
• How long the conversation will take.
• That you are studying the current workflow rather than pitching a finished solution.

Avoid leading with the climate mission if it encourages people to reward you for having good intentions. Mission alignment is useful context, but it can distort the conversation. You need to know what the organization does when the mission competes with budget, staffing, safety, or delivery pressure.

Ask about the past, not the imagined future

The most useful questions are anchored in behavior.

Ask:

• Walk me through the last time this problem occurred.
• What did you do first?
• Who else became involved?
• Which system, spreadsheet, consultant, or manual process did you use?
• How long did it take?
• What was the consequence of leaving it unresolved?
• What did you spend money on?
• What have you tried that did not work?
• How was the decision approved?
• What would have to happen for you to revisit it?

Be cautious with questions such as:

• Would you use this?
• How much would you pay?
• Would a dashboard solve the problem?
• Would you buy a tool that reduced emissions?
• Do you like this prototype?

These questions produce opinions, and opinions are cheap. Past behavior is more demanding evidence. If a prospect says the issue is a priority but cannot describe a recent attempt to solve it, a budget line, an internal owner, or a consequence, the urgency may be weaker than the language suggests.

Show a prototype late, if at all, during the first round. An early demo anchors the participant on your framing. They start reacting to your interface instead of explaining their own workflow. That can make a weak problem look stronger because the conversation has quietly turned into a product critique.

Track signals across the cohort

After every few conversations, review the evidence against the original hypotheses. Do not count every positive comment as validation. Tag what you hear by evidence quality.

A useful distinction is:

1. Background concern: The customer recognizes the issue but is not actively addressing it.

2. Recurring pain: The issue appears repeatedly in a current workflow.

3. Existing workaround: The customer spends time or money to manage it.

4. Trigger: A deadline, regulation, contract, cost increase, operational failure, or executive target makes action more likely.

5. Commitment signal: The customer offers access to data, introduces the budget owner, agrees to define a pilot, or schedules a concrete next step.

The final category is where conversations become commercially meaningful. A warm introduction or a request for another presentation may still be useful, but it is not equivalent to access, money, or internal action.

Your notes should capture exact meaning without inventing quotations. Record what the participant described, how the workflow operates, and what evidence supports the interpretation. Separate observed facts from your own conclusions. That distinction becomes essential when the founding team is emotionally attached to the original idea.

Stage 3: Master the two-person interview dynamic

A two-person team is one of the simplest operational improvements in customer discovery. One person leads the conversation, while the other takes detailed notes and watches for gaps.

This arrangement is not about creating a formal research atmosphere. It protects the quality of the conversation. The interviewer can build rapport, listen for inconsistencies, and ask follow-up questions without trying to transcribe every detail. The observer can notice when the participant changes terms, skips a step, or describes a workaround that deserves investigation.

The roles should be clear before the call.

The interviewer’s job

The interviewer keeps the participant in their own world. That means resisting the urge to explain the solution, correct the customer, or fill every pause.

Good follow-ups are often short:

• What happened next?
• Who handled that?
• How did you decide?
• What made that difficult?
• How are you doing it now?
• What did that cost?
• Why did you stop using that approach?

Silence is useful here. A participant may offer a surface answer and then continue if you do not immediately move to the next question.

The interviewer should also notice the difference between a strategic statement and an operational reality. A sustainability leader may say the company is committed to net zero. The follow-up is not whether the commitment is sincere. It is how that commitment changes a current purchasing process, project approval, supplier requirement, or operating decision.

The observer’s job

The observer should capture more than a transcript. Useful notes include:

• The participant’s role and proximity to the problem.
• The current workflow in sequence.
• Tools, vendors, and internal teams involved.
• Costs, delays, risks, and recurring friction.
• Trigger events and decision deadlines.
• Language used to describe the problem.
• Evidence of an existing budget or workaround.
• Objections that appear before the product is discussed.
• People who must be involved in a purchase.
• Climate measurement and reporting requirements.

After the call, the pair should debrief while the details are still fresh. Keep the debrief disciplined. Record what was heard, what remains uncertain, and which hypothesis changed. Do not turn every interesting comment into a new product feature.

Keep founders out of defensive mode

Founders naturally want to defend the product. Climate founders may feel an additional burden: defending the importance of the environmental problem itself. That can make interviews subtly argumentative.

If a participant says the solution would be difficult to implement, do not explain why the implementation is actually manageable. Ask what makes it difficult. If they say the emissions benefit is not enough to justify the purchase, ask what would make the economics work. If they use a competitor or internal workaround, study why it has survived.

The customer is not grading your moral seriousness. They are showing you the conditions under which change is possible.

Discovery is not a referendum on your mission. It is an investigation into the customer’s constraints.

Stage 4: Synthesize patterns and decide what to do next

The last stage is where many teams become vague. They finish the calls, feel encouraged, and move straight into building. The hard work is converting conversations into a decision about the next test.

Start by grouping evidence by cohort, not by the order in which interviews happened. Look for repeated patterns in:

• The moment the problem appears.
• The current workaround.
• The person responsible for solving it.
• The cost of delay.
• The event that creates urgency.
• The purchasing path.
• The proof required before adoption.
• The reason a customer rejects existing alternatives.

A pattern is not simply a topic mentioned by several people. It is a repeated relationship between a problem and a behavior. For example, several sustainability managers may mention poor emissions data. That becomes more commercially relevant if they also describe manual reporting, missed deadlines, consultant spending, or an upcoming requirement that forces action.

Build a problem evidence matrix

A simple matrix can prevent the loudest interview from dominating the conclusion.

This matrix is not a scoring system that magically produces truth. It is a way to expose where the evidence is thin.

Decide whether to persevere, pivot, or narrow

The outcome of discovery is not always a green light. There are at least three useful decisions:

Persevere: The cohort has a recurring problem, a credible trigger, an existing workaround, and a path to a paid or strategically meaningful test. Your next step is to design a minimum viable test around the customer’s current workflow.

Narrow: The broad market is interested, but only one segment shows urgency and access. Focus there. A climate startup may discover that “commercial buildings” is too broad, while a particular class of building operators has a clear budget and a repeated operational problem.

Pivot: The proposed problem is not painful enough, the buyer cannot be identified, or the solution depends on behavior the organization has no ability to change. A pivot does not necessarily mean abandoning the technology. It may mean changing the customer, use case, pricing logic, or deployment model.

The minimum viable test should prove behavior, not admiration. Depending on the business, that might involve a paid diagnostic, a manual service delivered before automation, a limited deployment using existing data, or a narrowly defined operational pilot.

For B2B climate startups, a pilot is not automatically validation. An unpaid pilot can create activity while avoiding the commercial question. Before agreeing to one, define what the customer will provide, who owns the project, what result is being measured, how long the test runs, and what decision follows if the result is useful.

Connect product-market fit to climate-market fit

A ClimateTech product has to fit the buying organization and the physical or environmental system in which it operates.

That creates practical questions that ordinary software discovery can underweight:

• Does the product work with the customer’s existing equipment?
• Who installs, maintains, or verifies it?
• Does the solution require new infrastructure?
• What happens when data is incomplete or inconsistent?
• Can the customer distinguish modeled impact from measured impact?
• Are the emissions claims based on a clear baseline?
• What operational trade-offs could reduce adoption?
• Does the buyer need regulatory, safety, or third-party assurance?
• Does the proposed intervention shift emissions elsewhere in the system?
• Can the customer continue using the product after the pilot team leaves?

These are not reasons to make discovery impossibly elaborate. They are reasons to bring the real constraints into the conversation early.

A founder may learn that the customer wants the outcome but cannot accept the deployment burden. That is not a minor objection to solve with better messaging. It may require a different business model, channel partner, installation approach, or product boundary.

What the four-stage process should produce

At the end of a three- to four-week sprint, you should have more than a pile of interview notes. You should be able to state:

• Which cohort has the clearest recurring problem.
• What the customer does today instead of using your product.
• Why the current workaround is no longer sufficient, if it is.
• Who experiences the pain and who controls the budget.
• What event could create a buying window.
• What evidence is needed for a first test.
• Which climate outcome can be measured credibly.
• What assumption remains most dangerous.
• What you will test next, and what result would change your plan.

You should also know what not to build yet. That is often the most valuable output.

The process will feel messy because the market is messy. Different customers will use the same words for different problems. Some will care deeply about emissions but lack authority. Others will purchase for cost or reliability and only later connect the result to climate goals. A few will ask for features that belong nowhere near your first version.

This is normal. The job is not to force clean consensus. It is to find the narrow intersection of urgent customer behavior, viable economics, feasible delivery, and defensible climate impact.

Customer discovery will not guarantee funding, eliminate technical risk, or prove that your emissions model is correct. It can do something more practical: stop you from confusing a worthy mission with a validated business.

The hard-earned lesson is simple. Before you build for the climate market, find the people already paying—through money, time, risk, or operational pain—for the problem you claim to solve. Then earn the right to build the smallest useful intervention around what they actually do, not what everyone hopes they will do.