Hey there! 👋
Skander here.
You want to ship faster. You want to ship right. You want the kind of product discipline that let Amazon scale from nothing to one of the most valuable companies on the planet.
You’ve probably read the Working Backwards books. You’ve listened to the Bezos interviews. You’ve bookmarked the six-pager templates. And none of it has changed how you actually make product decisions, because a book can’t call you on your decision theater.
The methodology works. We’ve seen it. But copying Amazon rituals without a continuous feedback loop and someone who actually lived the process is how you end up with generic PRDs and the same bad decisions.
Scott Renda has spent 11+ years as a Principal at AWS, shipping products across AI infrastructure, edge computing, and data centers. He ran and participated in the Working Backwards process, dozens of times, at a scale most climate founders will never touch.
A few months ago, Scott came to us with a proposal: let’s build something that forces founders to be wrong sooner, on paper, when pivoting costs weeks instead of millions.
A forcing function with peer feedback from founders who actually want to ship, and direct coaching from someone who won’t let you pull punches.
Today, we’re introducing Working Backwards for Climate Founders: an 8-week program to ship fast & right.
Here’s what we’re covering:
- Why most climate products fail at the business layer, not the science layer
- The six failure modes that kill climate startups before they scale
- How Amazon’s PR/FAQ methodology adapts to the specific physics of climate tech
- Why the fastest founders aren’t the ones who build first, they’re the ones who are wrong sooner
🌊 Let’s dive in, handing over to Scott Renda
But first, who is Scott?
Scott Renda has spent 11+ years at Amazon Web Services as a Principal Product Manager, where he led product and pricing strategy for hyper-scale AI infrastructure, architecting the training and inference clusters used by the world's leading foundational model providers, including Anthropic and OpenAI.
He launched AWS Wavelength (the world's first hyperscaler 5G Edge Cloud) and designed $100M+ partnership frameworks across AWS's infrastructure portfolio.
Before AWS, he served as Chief of Strategy, Policy and Communications at the White House, where he co-authored the US Federal government's first cloud computing strategy and oversaw $80 billion in annual Federal IT spend.
His career has been one long thread: deploying capital-intensive infrastructure at scale in deeply constrained environments. He now applies that lens to climate tech product strategy through Climate Drift.
Hey there! 👋
Scott here. :)
The graveyards of climate tech are filled with products that worked. Worked in the lab. Worked at pilot scale. Worked on paper. Right up until they didn’t work as a business.
Most climate startups fail not because the science is wrong, but because product decisions get locked in too early, with irreversible capital consequences. By the time founders discover the mistake, it’s too late. This essay is about why, and what to do about it.
Let me put the pitch first:
Working Backwards for Climate Founders is an eight-week cohort program that teaches you to surface product assumptions before they harden into capital commitments.We adapt Amazon’s Working Backwards and PR/FAQ methodologies (proven at AWS from zero to billions in revenue) for the unique challenges of climate tech.
Participants will learn to pressure-test their products against the specific failure modes that kill climate products: variability that destroys bankability, cost parity traps, workflow friction, and the three-way collision between manufacturing, supply chain, and operational readiness.
The program isn’t about writing better documents. It’s about being wrong sooner, on paper, when pivoting costs weeks instead of millions. Because in climate tech, the decisions that matter most are often one-way doors.
Climate founders operate with a different kind of confidence than typical startup founders. They’ve often spent a decade building expertise in a specific domain. They’ve done thermodynamics, materials science, and systems analysis. They know their solution needs to exist. This conviction is essential, as you cannot build hard things without it. But it creates a failure mode: the belief that technical merit alone will carry a product to market.
A scientist who has spent five years optimizing an electrolyzer’s efficiency at bench scale can easily confuse “this technology should exist” with “customers will buy this specific product.” The lab metrics become the product definition. The breakthrough becomes the value proposition. But industrial or enterprise buyers don’t purchase physics. They purchase solutions to operational problems with predictable economics. The gap between those two frames is where products go to die.
Let me be specific about the failure modes, because they’re more mundane than most founders expect. These modes rarely appear alone. But they are distinct, and fixing one does not fix the others.
The planet-as-customer fallacy. Carbon removal, clean energy, and circular economy ventures all start with global impact as the goal. The problem: “the planet” has no procurement budget. If your sales pitch leads with avoided emissions rather than operational value, you’re asking buyers to pay more for doing good. They won’t. The product must deliver bottom-line value, whether cost savings or operational gains, with sustainability impact as a built-in consequence. If your business model breaks when subsidies expire, you’ve built a policy bet, not a product.
The Variability Trap. Climate products routinely demonstrate consistent performance in controlled settings, only to experience unpredictably in the field. The issue isn’t that a product wears out, it’s that you can’t predict how or when because the degradation curve isn’t reproducible. One unit performs as promised while an identical unit fails twice as fast under seemingly similar conditions. Lab testing can’t simulate the chaotic combinations of stress factors that real deployments encounter. If troubleshooting requires flying in specialists to diagnose site-specific failures you’ve not seen before, your product isn’t scalable. Variability kills project economics. Lenders can model graceful degradation; they cannot model outcomes you can’t predict.
Workflow Friction. If your climate solution creates friction in how people actually work, it will remain sidelined regardless of its technical merit. You either build drop-in solutions or provide overwhelming value. True “overwhelming” value must account for hidden switching costs; otherwise, the path of least resistance for a buyer is simply to stick with their existing carbon-intensive incumbent. Most founders underestimate how much “overwhelming” actually requires.
The Cost Parity Trap. Climate tech doesn’t compete in a vacuum; it competes against fossil-fuel incumbents optimized over decades and buoyed by subsidy tailwinds. Startups routinely develop products with premiums that are structurally incapable of reaching parity. In industrial markets, 50% premiums are a non-starter at scale, no matter how much better your product is. If your path to profitability depends on a 100x production increase you can’t fund, you haven’t built a business; you’ve built a niche curiosity. Founders consistently underestimate the steepness of the learning curve and the capital required to descend it.
The Bankability Gap. Hardware-intensive startups often design for venture milestones while ignoring project finance requirements. Scaling from pilot to fleet requires moving beyond equity to secure low-cost debt. Products deemed unbankable by cautious lenders trap startups in the FOAK “Valley of Death.” If a bank cannot model your technical risk, or if you lack the contractual offtake and performance guarantees required for underwriting, scaling stalls. You can’t just build a functional machine; you need to build a bankable asset that traditional lenders will finance at scale. Many founders don’t think about this until they’re too far into a funding burn.
The Readiness Gap. Scale in climate tech is a three-way collision between what you can build, what you can source, and what customers can actually run. Manufacturing Readiness (building Unit #100 identically to Unit #1), Supply Chain Readiness (no 18-month component lead times), and Operational Readiness (running without expert babysitting) don’t move independently. The real breakthrough isn’t proving the science works on a bench. It’s shipping a system where manufacturing produces consistent outputs, supply chain doesn’t create single points of failure, and field operations don’t devour your team. You’re not just selling technology. You’re selling a predictable, sourceable, and serviceable asset that works when you’re not in the room.
In software, many most decisions are reversible. You ship, you learn, you iterate. The code is malleable. The infrastructure scales elastically. You can pivot a product in weeks. Climate tech often doesn’t work this way.
When you commit to a manufacturing process, you’re committing capital that can’t be recovered. When you sign an offtake agreement, you’re locking in product specifications for years. When you select a battery chemistry, a materials supplier, or an interconnection point, you’re making decisions that propagate through every subsequent choice.
The tragedy is that founders make these decisions based on assumptions that haven’t been tested. They commit to manufacturing architectures before validating cost parity is achievable. They design products for durability specifications that don’t match field conditions. They build for customers who turn out to have different operational constraints than anticipated.
By the time they discover the mistake, it’s baked into their product.
This isn’t just a hardware problem. Climate SaaS solutions such as carbon accounting platforms, grid forecasting tools, marketplace engines operate inside regulated, operationally brittle environments. Once embedded, changing assumptions becomes slow and painful. Trust, not code, becomes a one-way door. Whether you’re pouring concrete or shipping code, founders commit to product decisions based on untested assumptions, only to find the market won’t absorb what they’ve built.
Here’s the question you should ask yourself: can you defend your product’s existence in a six-page document? Not defend the technology. Not defend the market opportunity. Defend why a specific customer will pay for this product to solve this problem, with a clear path to cost parity, bankability, and scalable manufacturing.
In the early 2000s, Amazon developed a methodology called Working Backwards precisely for environments like this. Not because Amazon is full of cautious business leaders, but because Amazon makes considerable infrastructure bets with long payback periods. Sound familiar?
Working Backwards is exactly what the name suggests: you start with the customer outcome you want to create, then work backward to the product, the technology, and the roadmap required to deliver it. Instead of building something and hoping customers want it, you define what “want it” looks like first, then pressure-test that definition until you’re confident enough to commit capital.
The core artifact is the PR/FAQ: a press release announcing your product as if it’s already launched, followed by an FAQ answering essential questions and difficult objections.
The press release is typically a single page. It forces you to articulate the customer, the problem, and the outcome in plain language. No jargon. No efficiency metrics. No appeals to climate urgency. Just: which customer is this for, what problem do they have today, and how does their situation change after they use your product? You also write fictional customer quotes describing the value they realized by using your product. If you can’t write a believable quote, you probably don’t understand what the customer actually values.
The FAQ section, typically around five pages, is where you confront the essentials and the objections, including visible risks. What happens when the product degrades after six months in the field? How does this integrate with existing workflows without shutting down operations? What’s the total cost of ownership compared to an incumbent? Can a bank underwrite this asset for project finance? Each answer surfaces an assumption you’d otherwise discover at the manufacturing line.
Here’s why this matters more than pilots or demos: a pilot proves your technology works under controlled conditions. A spreadsheet proves your unit economics work under optimistic assumptions. Neither forces you to confront durability, workflow friction, bankability, and at-scale economics simultaneously, in writing, where contradictions become visible.
The PR/FAQ does. When you write that your product “reduces maintenance costs by 30%,” you’ve created a falsifiable claim you can take to real customers. When you write that “local technicians can service the unit with standard tools,” you’ve made a commitment your engineering team has to deliver. When you answer the bankability FAQ, you discover whether your product architecture is even compatible with project finance, long before you’ve built the manufacturing line.
Counterintuitively, writing often exposes assumptions faster than building. In complex systems, the fastest teams aren’t the ones that build first. They’re the ones that are wrong sooner. And in a sector where most decisions are irreversible, exposing assumptions early is how you avoid walking through the wrong door.
Writing a PR/FAQ sounds simple, but most founders either pull punches or lack pattern recognition for which assumptions matter most. That’s what Working Backwards for Climate Founders: Ship Fast, Ship Right provides: structured pressure to stress test durability, workflow fit, cost parity, and financing readiness before those assumptions become capital commitments. I spent 11+ years at AWS building cloud services that scaled to millions of customers. The methodology isn’t magic; it’s a forcing function for intellectual honesty when conviction would otherwise carry the day. In the program, founders will apply specific Amazon ways of thinking:
Primitives beat platforms. Focused building blocks expand your degrees of freedom; platforms hard-code constraints you’ll regret.
Write the launch story before you write code. Speed without clarity on the real customer just gets you to the wrong outcome faster.
Use the FAQ to kill your favorite idea early. Killing weak ideas on paper isn’t failure; it’s how strong ones survive.
The document is the prototype. A six-page document costs weeks; a wrong pilot plant costs years.
Let me be honest: there are plenty of valid criticisms of this approach.
Critics often dismiss the PR/FAQ as a “waterfall” relic that locks teams into static solutions Startup teams, especially, see it as a luxury they can’t afford, “We’re racing a funding clock here.” Others worry that writing “fictional” customer quotes drifts into creative writing, or that the process rewards documents over shipping the right product. And yes, there’s a blind spot here: some products depend more on aesthetic intuition than rigorous prose.
But this is exactly where the PR/FAQ earns its keep. It becomes the source of truth for stakeholders. It forces intellectual honesty. You get ready-made marketing language. Finance gets unit cost assumptions and business-model inputs. Legal sees implications early. Product and Engineering align on what they’re actually building.
Most importantly, the PR/FAQ is not static. It should evolve. That’s the point. The real discipline is not writing it, but rewriting it when customers prove you wrong. That’s the hinge. Your source of truth evolves as your customers evolve.
Yes, Claude or ChatGPT can draft it. But if AI writes it for you, you miss the point. Think first. Write first. Then refine with AI.
As Amazonians say: strong principles, loosely held.
Working Backwards for Climate Founders is an eight-week cohort program for founders building hardware, software, or integrated products in energy, renewables, industry, agriculture, and infrastructure.
The program includes three 2.5-hour group sessions, two private 30-minute coaching sessions, and structured peer review. Total founder time investment: 15-20 hours including customer interviews and PR/FAQ iterations. Cohort size is limited to five founders.
Founders leave with five deliverables:
1. You’ll know what your customer is actually buying, articulated in plain language, without jargon, in a way a real buyer recognizes.
2. You’ll know the price your customer will pay based on the operational problem you’re solving instead of your cost structure or manufacturing assumptions. And you’ll have the interview data to defend that number to an investor.
3. You’ll be able to articulate, specifically, which of the six failure modes is your highest-risk exposure right now. And, what would have to be true for you to be wrong about that
4. You'll have a repeatable process for testing product assumptions, whether now or at different product inflections
5. You’ll learn how to run a story-based discovery interview, and how to extract the unmet need from the story rather than from the answer.
Your peer cohort isn’t a networking group; it’s a product review board. These are five founders navigating the unforgiving physics of hard tech and trying to raise capital in tough environments. When a peer flags an optimistic yield in your business case or questions assumptions in your FAQs, they aren’t guessing; they are speaking from the scars of their own failure modes. Shared constraints are infinitely more valuable than unearned platitudes from those who haven’t lived the gap.
The next cohort starts June 29, 2026 and runs through August 28, 2026. Two cohorts available, five founders each. Spots are limited. Early applicants receive priority.