Climate MVP spec sheet: a one-page template

Two documents were competing for authority on her desk: a forty-page product roadmap she'd authored herself over six months, and an internal spec her lead engineer had rebuilt overnight as a spreadsheet of tabs. Neither could travel — not to investors, not to pilot customers, not back to her own team — without a translator attached. She scrapped both. The version that survived was a single page. The seed round closed. Two years and four pivots later, that same one-page spec is still the only document the entire company can point to without arguing over what it means.

That founder is not unusual. The version of her that exists in every accelerator cohort is the version I'm writing this for. The mess is the same in every vertical — software-side ML, hardware, services, hybrid — and the document has to carry the same load.

A spec sheet is not a roadmap. It is a treaty between people who have to make decisions before they agree on what they're building.

The Case for a One-Page Specification: Avoiding the 42% Failure Trap

The cleanest version of the bad news is the one Forbes has been quoting for years: roughly 42% of startups fail because there is no real market need for what they built. That figure is uncomfortable in any vertical. In climate, it is only the floor of a much larger failure surface. Hardtech startups can fail the same way software startups do — by building a product no one will pay for — but they can also fail in two additional ways that software rarely has to face. They can solve a problem that turns out not to exist at the field conditions they assumed. And they can build a system whose climate impact, even when it works, is too small or too indirect to clear anyone's diligence bar.

The pattern I keep seeing in the post-mortems that cross my desk is not "we built the wrong thing." It is "we built the wrong thing faster than we could notice." Teams move fast on the assumption that speed is the bottleneck. Speed is rarely the bottleneck. Alignment is. The team agrees on words, builds different products behind those words, and only notices the divergence when the next milestone misses. By then, the runway has paid for two different versions of the same idea.

A one-page MVP spec sheet exists to slow down — for one afternoon — exactly the decisions that go wrong fastest. It forces the question "what are we actually building this quarter?" out of slack messages and into a shared artefact. The sheet does not answer the question. The sheet pins the question down long enough that the team can disagree on it usefully. Disagreement on a pinned question is strategy. Disagreement on a question no one has written down is just a calendar invite that gets rescheduled.

For non-technical founders specifically, the spec serves a second job that nobody warns them about. It is the most reliable document for transmitting intent to a technical co-founder, a contract engineer, a no-code shop, or a piece of off-the-shelf climate software. A 40-slide deck tells them what you wish were true. A spec sheet tells them what you will pay for and when you will stop paying. The difference matters more than founders expect, because the people they are transmitting intent to are usually busy and usually expensive.

Defining the Core Hypothesis: What, Why, and When

The skeleton I keep returning to has exactly three boxes. They sound reductive until you try to fill them in. They are not reductive after.

WHAT — the problem, in one sentence. Not the solution. The problem. "Industrial cold-storage operators in coastal North America lose measurable inventory per summer outage" is a problem. "Our IoT temperature monitor prevents that loss" is a solution wearing a problem's clothes, and it has no business in a WHAT box. The discipline here is the discipline of a single defensible claim about a customer behavior you can measure, in a sentence that survives being read aloud at 7 a.m. before coffee. If the WHAT cannot survive 7 a.m., it is a slogan, not a hypothesis.

WHY — the climate and business value, with two numbers. Two numbers are better than one because each holds the other accountable. One measures the climate outcome in the unit your buyer cares about: tons of CO2e avoided, kWh shifted, liters of water saved, hectares of degraded land restored, units of plastic kept out of the marine environment. The other measures the business outcome: dollars saved, dollars earned, dollars avoided in regulatory exposure, dollars unlocked in offtake contracts. Both have to move together for a climate startup to compound. A document that nails the climate value but cannot defend a margin will not get funded. A document that defends a margin but cannot attach it to a measurable climate outcome will not get diluted at a sensible valuation. The WHY box holds both anchors, deliberately.

WHEN — the boundary, the trigger, the stop date. This is the box most founders skip, and it is the box that quietly saves them. WHEN establishes two things: the deadline by which the MVP must demonstrate the hypothesis, and the explicit triggers that tell the team when to pivot rather than persist. "If, after twelve weeks and X pilot customers, retention is below Y%, we revisit the WHAT." That is a sentence you write once and then thank yourself for every quarter afterward. Without it, persistence becomes indistinguishable from stubbornness, and stubbornness is the most expensive word in the climate founder's vocabulary.

Mapping the Four-Stage Hardware Validation Roadmap

Climate startups that touch hardware — and most of them do, even when they describe themselves as software — have a validation sequence that software startups do not. Software can ship a build at 4 p.m. and find out at 5 p.m. whether the on-screen button works. Hardware cannot. The validation cadence for climate hardware roughly maps to four stages, and it is genuinely useful for founders to know which milestone the spec sheet is currently pointing at.

The mistake this table is designed to prevent is the prototype theater trap. A company reaches Alpha, builds a beautiful lab unit, then raises a seed round as if the problem has been solved because the unit exists in a controlled room. It has not been solved. It has been demonstrated in a controlled room. Three further stages of evidence stand between that benchtop and a customer-facing claim. Founders who do not internalize this routinely over-promise and then spend a year explaining the gap to investors who feel — often justifiably — misled.

For the spec sheet, the implication is concrete. The spec should declare which of the four stages is the current target and which is the next gate. When the current stage changes, the WHAT shifts — slightly — and the sheet revises. This is not failure. This is the document doing its job, which is to admit reality at the speed reality changes. A spec sheet that pretends the validation stage has not moved is the kind of document that quietly costs a seed round its narrative six months later.

Transitioning from Manual Spreadsheets to Scalable MVP Logic

There is a moment, usually between months six and fourteen of a climate startup's life, when the spreadsheet stops working. The signals are specific and worth naming, because the team almost always misses them the first time.

The same activity data — a customer site visit, a meter reading, a unit shipped, a unit returned, a customer complaint logged — is being entered by hand across an intake sheet, a calculation tab, a reporting file, and the model sent to investors. The math has been re-derived three times by three people and no two of them agree. A small change to one input breaks the others in ways that take half a day to reconcile. A new sales hire cannot answer a customer question without asking an engineer who is on vacation. When these patterns appear, the team is not having a tooling problem. The team is having a scaling problem dressed as a tooling problem. The two have very different solutions.

The spec sheet is where this transition gets named, before the tooling vendors get into the room. A line that reads "Q3: replace intake sheet and calculation tab with a shared backend; preserve current outputs verbatim until investors confirm parity" turns the decision from a tooling debate into a milestone. The WHAT, in other words, is currently this spreadsheet. The WHY is "we lose two engineering days per week reconciling it." The WHEN is "before we onboard the next three customers." That is a clear scope. It is also the scope that no off-the-shelf software vendor will quote for you cleanly — they will sell you the platform, not the migration — and so the spec needs to anticipate that the actual work is half platform and half change management. Pretending otherwise is how teams overspend on software they underuse, and then spend the next quarter explaining the gap to a board that has already seen the invoice.

A static spreadsheet is fine for a pre-seed founder working alone. It stops being fine on the day a second person needs the same answer.

Balancing Customer Demand, Operational Viability, and Climate Impact

A climate MVP has to do three jobs at once, and the spec sheet is where the jobs get written down so the team can argue about them honestly. The three jobs are not negotiable, and they are not sequential.

The first is customer demand and willingness to pay. Someone, somewhere, has to put a signed contract or paid pilot in front of the team. A 1,000-customer waitlist with no signed deals is a marketing claim, not a market.

The second is operational viability in real field conditions. The unit, the software, the service has to keep working when a customer is angry, when the field is muddy, when the data network drops, when the inspector visits unannounced, when the field engineer has the flu and a substitute shows up. A pilot that runs only in a vendor's lab, or only with a full-time person onsite, has not cleared this gate.

The third is measurable climate impact. A documented, credible path to a number the buyer can defend — their own emissions reduction, their own avoided cost, their own compliance position. Not a back-of-envelope timeseries. A number someone outside the company would accept and, ideally, audit.

These three have to coexist. The spec sheet should make the trade-offs between them visible, because the trade-offs are where the founders who succeed are made. Sometimes the climate impact test is the one that loses — the science works in the lab, but the field lifetime is shorter than the audit window requires, and the impact number does not survive contact with reality. Sometimes the operational test loses — it works perfectly, but only with a full-time engineer onsite. Sometimes the customer test loses — there is demand, but it is the wrong demand, from buyers who will not scale. The trade-offs are real. Founders who do not make these trade-offs visibly are usually the ones whose company has to make them for them, in court or in a down round, three years later.

Three jobs, one page, one quarter: that is the load the spec is built to carry.

A Field-Tested Template

What follows is the structure I keep recommending. It is not original. It is what survives the most founders who use it, which is a better recommendation than originality.

• Header line. Company name. Date. Current validation stage — drawn from the table earlier. Founder or PM owner.
• The hypothesis, in three short paragraphs. WHAT, then WHY, then WHEN. Each paragraph no longer than the previous one. The shrinking length is intentional and worth keeping.
• Scope, in bullets, max six. What we are building this quarter. Each bullet is a user- or operator-observable behavior, not a feature inside the engineering team. "Login works for a new customer" is a behavior. "Auth service endpoints support password reset" is an internal milestone wearing a behavior's clothes.
• Out of scope, in bullets, max six. What we are explicitly not building. The list is supposed to be uncomfortable. If it is not uncomfortable, the WHAT is too soft. Out-of-scope bullets also seed the next spec — they stay alive on a separate page as the deferred idea bank.
• The three tests, one short paragraph each. Customer, Operational, Climate. Each paragraph names how the team will know the test has been passed and what observable artifact proves it.
• The two triggers. When do we pivot the hypothesis (the result that falsifies the WHAT), and when do we stop the experiment to keep the team's capacity for the next one (the result that says "we have learned enough"). Both should be numeric or falsifiable. "If we feel stuck" is not a trigger.
• Sign-off line. Three names. The non-technical founder, the technical lead (or contract engineer or no-code integrator), and one outsider — advisor, mentor, peer founder — who is allowed to break ties. The sign-off is symbolic and real at the same time. After the first quarter, it is what the next investor diligence call asks for, and the team's answer should never be "actually, we hadn't updated it."

The Hard Part

The hard part is not the document. The document is a Tuesday afternoon. The hard part is what happens two months later, when a customer offers a contract for a feature the WHAT does not cover, and a co-founder has quietly agreed to a corner-cut a technical lead warned against. The spec sheet is asking to be ignored. Every team will, at some point, want to ignore it.

The discipline is not that you write the document once. The discipline is that you revise it before you act outside of it, not after. Acting outside the sheet and then retroactively editing it is how the document loses authority and the company loses the only thing the spec was protecting — the capacity to make the next decision on shared ground instead of on the residue of the last one.

A one-page spec is a contract the founders make with their future selves. It is small enough to keep in a head, short enough to read on a phone before a customer meeting, and specific enough that a stranger can tell you within thirty seconds which hypothesis is being tested and what would falsify it. That is the entire job of the climate MVP spec sheet. It is not glamorous. It is, in my experience, the single highest-leverage artefact a non-technical climate founder can produce in the first hundred days. Everything else in the company — the tech stack, the hiring plan, the brand, the regulator relationships, the offtake pipeline — is downstream of getting this page correct, and keeping it honest when the next pressure to betray it lands.

Resilience, in a climate startup, is rarely a product feature. It is a document that survives being argued over.