Introduction: The Line Nobody Owns

Every product org I've worked with has a line item for compute. Almost none of them have one for the electricity that compute actually burns, or the water it takes to keep it cool. And basically none of them have a person whose job it is to ask about either before the decision gets made, instead of after the bill shows up.

That's what this piece is actually about. Not "AI is bad for the planet" — that's a different essay, and honestly a less useful one. I'm talking about something narrower and a lot more practical: product and engineering teams make build-vs-buy calls, model-selection calls, and architecture calls every single week that carry a real, quantifiable energy cost, and in most rooms I've sat in, nobody's pricing that in.

We spend on compute and consume the power behind it like both are unlimited and consequence-free. They're not. Not anymore.

This isn't some future problem for a future architect to worry about. It's already showing up in three places at once — on the balance sheet, in the risk register, and on the strategic roadmap of the handful of companies that got ahead of it. I want to walk through all three: where a PM's own decisions touch energy cost, why this has quietly become a real business risk, and why energy deserves an actual seat on the strategic roadmap instead of getting buried in a facilities line.

I asked a colleague, Joy Peterson, Principal Software Engineer at Tech9, when energy or compute cost had last come up explicitly in a build-vs-buy conversation on one of his projects. His answer: "Last time for me was about 15 years ago 🤷." Then, a beat later, he added the line that's really the reason this piece exists: "The trend is changing again, so I expect this will start coming up more."

Part One: The PM's-Eye View — Where Energy Hides in Ordinary Decisions

PMs don't set utility rates. We don't get a vote on which power plant feeds which data center. What we do control, every day, is the shape of the workload — and that's exactly where energy cost lives, whether we're looking for it or not.

Build vs. Buy Isn't Just Cost and Control Anymore

The old build-vs-buy framework runs on cost, control, speed, and differentiation. I'd argue energy exposure deserves to be a fifth axis now, because "buy" — calling a frontier model's API — and "build" — running or fine-tuning your own model — carry genuinely different energy footprints. And increasingly different risk profiles, tied to where that power actually comes from and how reliable it is.

When you buy inference from a frontier-model API, you're handing the energy problem to a hyperscaler who, by necessity, is already thinking about grid capacity, power contracts, and siting years out. When you build — running your own model on dedicated infrastructure, on-prem or in a cloud region you control — you inherit a piece of that exposure yourself. That's not an argument against building. It's an argument for asking the question up front instead of finding the answer in an infrastructure bill or a capacity ceiling six months later.

Buying hands the energy question to someone else. Building hands it to you.

I've watched both versions of this play out. On one project — an accounting software client building AI-powered call intelligence for their sales and customer service teams — we took inbound calls, ran the audio through a Whisper model, and used it to populate Salesforce: which calls were sales versus service, whether reps stuck to the approved script or veered off it, risk flags based on what customers actually said, so the right team got alerted fast. It's a genuinely good product. It tightened up sales coaching and helped standardize process across the whole company. But the build decision came down to one thing: speed. We went with the largest, fastest, highest-quality models on the market by default, because the ask was "build it as fast as you can," and energy or infrastructure footprint never came up as a factor once. Cost came up exactly once, as "what's the number — I'll get it through finance." Not a bad outcome. Just an unexamined one, and in my experience that's the far more common story than a team consciously deciding to spend more for a reason.

Model Selection Is an Energy Decision Wearing a Performance Costume

Here's where it gets concrete, and where I think most product conversations still don't go.

There's a recent analysis using the InferenceMAX benchmark suite that compared per-query energy draw across model sizes.2 A large mixture-of-experts model — DeepSeek-R1, roughly 671 billion parameters — running a typical 8,000-token-in / 1,000-token-out workload landed somewhere around 3–16 Wh per query on standard 8-GPU setups, depending on output length, dropping to around 1 Wh on the most efficient large-cluster hardware. A much smaller model built for comparable tasks — GPT-OSS-120B, 120 billion parameters — used roughly 0.1–0.6 Wh per query on the same workloads. That's 10 to 25 times less energy for work that, in a lot of cases, a product team could hand to either model.

That spread is worth sitting with for a second. It's not a rounding error you shrug off into "cloud costs." At the scale most real products run — thousands or millions of queries a day — that gap is the difference between an energy footprint you can defend to a sustainability-minded enterprise buyer and one you'd rather nobody asked about.

I want to be honest about the caveat here rather than bury it: these are benchmark numbers, not confirmed production numbers, and the person who ran the analysis says as much — real-world deployed workloads can look different than controlled benchmark conditions. So treat the specific Wh figures as illustrative, not gospel. What I do think holds up is the ratio — an order of magnitude or more between "the biggest model available" and "the right-sized model for the job."

The implication for PMs is pretty direct: every time a team defaults to the biggest, most capable model because it's the safe technical choice, that's an energy decision made by not deciding.

Model selection is a lever. Most roadmaps still don't treat it as one.

Not every project skips that conversation, though, and it's worth showing what it looks like when a team actually has it. On a different project — a veterinary health system, again unnamed, building a Whisper-based transcription tool so vets could dictate patient details straight into the chart — we trained on thousands of hours of audio, and the model-size question got worked through in the room with architects, business stakeholders, and engineers together. The business knew it was expensive. They said so, plainly, and then said: if that's what it takes, we'll absorb the cost. They wanted the fastest, most efficient, highest-quality voice model available, no compromises. Honestly, a smaller model probably could have done the job. But this was going straight into a patient's medical record, and quality wasn't something they were willing to negotiate down. I don't think that was the wrong call. The point isn't that they should have picked a cheaper model — it's that they actually had the conversation, with the real cost on the table, and made a deliberate choice. That's the exception. Most projects never get that far.

There's a second pattern I keep running into that I think is a genuinely underused lever: teams reach for the "frontier" model — the newest, most capable one on the market — even for tools that are entirely internal, where nobody's actually timing the response. If I'm an internal employee running a tool that takes two extra seconds because it's running on a smaller, cheaper model instead of the flagship one, I probably don't notice, and if I do, I probably don't care. But almost nobody asks that question. The default across the market right now is: we want the latest and greatest, and we'll pay whatever it costs to get it — for customer-facing products and for internal tools alike. Nobody's offering the business the tradeoff of "slightly slower, meaningfully cheaper, and your own staff won't notice the difference." That's a real gap, and it's one PMs are specifically positioned to close, because we're the ones who actually know whether the user on the other end will notice.

Nobody's shipping a two-second delay as a badge of honor. Maybe someone should.

The Roadmap Question This Should Actually Raise

None of this is an argument for always picking the smallest model, or always buying over building. It's an argument for one unglamorous habit: when a feature gets scoped, somebody in the room should ask what it costs in energy at the scale it'll actually run — and whether that changes the call — the same way we already ask about latency, cost-per-call, and data residency. Right now that question mostly doesn't get asked at all. Which means it isn't being decided. It's being defaulted.

Part Two: This Isn't Just an IT Cost — It's a Business Risk

Here's the part that turns this from a nice sustainability talking point into something a CFO should actually lose sleep over: the energy this industry needs is increasingly not available on demand, at any price, on the timeline everyone's been planning around.

The Scale of the Demand Curve

Start with where we are. Global data center electricity use hit roughly 485 terawatt-hours in 2025, up 17% in a single year, and AI-focused data center demand specifically surged around 50% over that same stretch.1 The IEA projects total data center electricity use will roughly double, to somewhere around 950 TWh, by 2030 — with the AI-focused slice alone roughly tripling over that five-year window — pushing data centers to something like 3% of global electricity demand.

Numbers at that scale are easy to skim past, so here's the plain version: this industry is trying to roughly triple its AI power footprint inside five years, on top of a grid that was never built, sited, or permitted for that kind of growth curve.

The Bottleneck Moved From Chips to Power

For the last few years, the thing capping AI capacity was GPUs. That's still true. But a second constraint has shown up right behind it, and it might actually be the harder one: getting electricity to the building.

For years we worried about the chips. Nobody was watching the wire.

One industry analysis found that of roughly 16 gigawatts of data center capacity targeted for 2026, only about 5 GW had actually broken ground, with an estimated 30–50% of the remaining capacity at risk of slipping into 2027 or later.3 The main culprit is interconnection delay — the median time from requesting a grid connection to actually operating has roughly doubled, from under two years for projects completed 2000–2007 to more than four years for projects completed 2018–2024. One detail from that reporting stuck with me: a utility reportedly told Google's own sustainability team it could take up to 12 years to evaluate a single interconnection request.

The regional numbers back this up. In ERCOT (Texas), the interconnection queue jumped from 63 GW to 226 GW in a single year — a 3.6x increase — and CenterPoint Energy reported a 700% jump in large-load connection requests. In Northern Virginia, still the biggest data center market on earth, vacancy sits around 0.72%, with 87% of 2025–2026 inventory already pre-leased.

Power isn't the only resource under this kind of strain, and it's worth naming the second one plainly: water. U.S. data centers consumed roughly 66 billion liters of water directly for cooling in 2023 — more than triple the 21.2 billion liters they used in 2014 — and indirectly consumed another roughly 800 billion liters through the electricity generation needed to power them that same year.5 Water scarcity is becoming the same kind of local flashpoint that grid capacity already is: communities near major data center buildouts are increasingly pushing back on facilities competing with them for water, not just power. It's a distinct risk from grid capacity — different mechanism, different local politics — but it rhymes with it.

Another resource everyone assumed was abundant and free of friction, until it very visibly wasn't. We've spent two years worrying about GPUs and zero minutes worrying about the groundwater underneath them.

This is the part that belongs in a risk register, not a sustainability slide: capacity plans that assume power will just be there when the project needs it are, increasingly, making a bet that isn't paying off on schedule. A roadmap commitment tied to a data center coming online in 18 months is, in a real number of cases now, actually tied to a grid interconnection queue that nobody on the product team can see into.

I want to be honest about where my own experience sits on this spectrum, because it's a useful contrast to the macro numbers above. On both projects I mentioned — the veterinary transcription tool and the accounting software's call intelligence — we did hit real capacity limits: Azure and AWS quotas, GPU availability. But every time, the fix was a configuration change, not a multi-year wait. The conversation with the client was basically "we're hitting a ceiling, we need to raise the quota now or testing stalls and the system won't scale the way you want it to" — and the client said yes, every time, usually within days. That's the reality for most product teams right now: capacity risk feels like a quick budget conversation, not an existential one. The IEA and grid data above is what tells you that cushion isn't guaranteed to hold as this scales — the gap between "raise your Azure quota" and "wait years for a grid interconnection" is exactly the gap between where most of us are operating today and where the largest players already are.

What This Means for a Roadmap, Concretely

If your roadmap assumes elastic, always-available compute at a predictable price, the risk here isn't abstract. Three things I'd actually put a name on:

None of this needs an apocalyptic frame to matter. It just needs to be treated like any other supply-chain dependency — a planning input with real uncertainty attached, not a utility that's always going to be there.

Part Three: Why Energy Belongs on the Strategic Roadmap — Not the Facilities Budget

This is really the heart of it, and I think it's where most companies still get it wrong: energy gets treated as an operating expense to be squeezed down after the fact, while the companies moving fastest and most credibly here are treating it as a strategic asset to lock down years in advance.

Look at what the biggest players are actually doing — not what's in the sustainability report. Microsoft signed a 20-year power purchase agreement with Constellation Energy to restart Three Mile Island's Unit 1, now rebranded the Crane Clean Energy Center — 837 megawatts of dedicated nuclear capacity, committed two decades out.4 Amazon expanded its power purchase agreement with Talen Energy for output from the Susquehanna nuclear plant in Pennsylvania — roughly 1,920 megawatts, running through 2042. Between those two deals alone, that's more than 2.7 gigawatts of firm nuclear power locked in under contracts measured in decades, not budget quarters.

That's not a company managing an expense line. That's a company treating energy access the way an airline treats fuel hedging, or the way a chip company treats a fab partnership — a strategic dependency worth securing years before you actually need it, because if you wait until the need is acute, you've already lost the negotiation. Possibly the capacity, too.

Microsoft didn't restart a nuclear plant because it was cheap. It restarted it because waiting was more expensive.

"Companies Just Spend and Consume" — And That's the Real Problem

I want to say the uncomfortable part plainly: most companies below the hyperscaler tier aren't doing any version of this. They're spending on compute and consuming the power behind it with no strategic layer above it at all — no multi-year energy posture, no visibility into where their own compute demand sits in the regional grid picture, no plan for what happens if capacity or pricing or regulatory pressure shifts under them. Energy sits in the model as an undifferentiated cost of doing business, filed next to office electricity and cloud storage.

It's not being managed. It's being absorbed — right up until it can't be anymore.

That gap is exactly where a strategic roadmap earns its keep. You don't need to sign a nuclear PPA to have an energy strategy — that's a hyperscaler-scale move most companies will never need or be able to make. But any company building AI-dependent products at real scale can ask a much smaller version of the same question the hyperscalers are answering with billion-dollar contracts: where does our compute-driven energy exposure actually sit today, where's it headed given our own growth, and who owns the answer?

Right now, for most companies, the honest answer to "who owns it" is nobody. It falls in the gap between infrastructure and DevOps, who feel the bill; finance, who approves it; and product, who drives the demand that creates it in the first place. Because it's nobody's explicit job, it never makes it onto a strategic roadmap next to market expansion or hiring or platform investment — where, frankly, it belongs.

I see this gap from both sides in my own work. When I'm scoping growth initiatives for our PM team, energy and compute cost absolutely comes up as a strategic consideration — but almost always framed as an opportunity for us to help a client optimize it, not as something we need to solve for ourselves. Internally, it's still purely an IT/ops line item, full stop — it gets pushed straight to that budget and nobody outside of it thinks about it again. And even the clients who do this better than most aren't really doing it well. One client — I can't say who, but it's a wellness company — breaks down its roughly $75,000-a-month cloud budget into about ten categories and estimates that, say, $5,000 of that belongs to the AI department. That's genuinely more visibility than most companies have. It's still a guess.

That gap is exactly what I keep coming back to, and I'll be honest — I don't have a clean answer for it. Extreme ownership is a constant theme on my team and across our company, but when I ask myself how a technical PM, or even a software team generally, would actually own infrastructure or energy cost risk, I don't have a tidy answer. This has traditionally been an IT infrastructure cost, not a software development cost, and there's a real seam between those two worlds that I don't think anyone's fully mapped. My honest guess is that it currently lands with a CTO, a VP of IT, or a CISO — someone with both functions reporting up to them, who has to go into the weeds to sort out which costs belong to which side. Part of why this whole project matters to me is that open question: as a technical PM, what's the actual bridge for me to own this myself?

I haven't personally had to stand in a room and force that question yet — I'll be honest, I'm not senior enough in any org I've worked with for that to have been mine to ask. But I want to be. We already track engineering cost down to the hour — an engineer works an hour, I pay him a dollar, and that's a line item in how we build and deliver software. The infrastructure and energy cost required to actually run what we build should sit in that same accounting, as part of the software wheelhouse, not something we hand off and stop thinking about the moment it leaves our budget.

Extreme ownership stops at the electricity meter. That's the part nobody's claimed yet.

What Putting Energy on the Roadmap Actually Looks Like

This doesn't have to be complicated to be real. A roadmap that takes energy seriously tends to have a few things most don't have yet:

  1. A named owner. One person — not a committee — accountable for understanding the org's compute-driven energy exposure, the same way someone owns security posture or platform reliability.
  2. A forward-looking capacity view, not just last quarter's bill. Not "what did we spend on compute," but "given our growth, what does exposure look like in 18–36 months, and where are the pinch points."
  3. Model and architecture choices treated as energy choices — per Part One — with the cost of defaulting to the biggest model made visible when the decision gets made, not when the invoice shows up.
  4. An actual risk posture on capacity and price volatility — even something as simple as "we won't build a core product dependency on a compute assumption we haven't stress-tested against a 2x price jump or a six-month capacity delay."
  5. Honest reporting — internally and to customers — about where the exposure sits, because the regulatory and reputational wind is blowing toward disclosure, not away from it.

None of that requires nuclear PPAs or a sustainability department. It just requires deciding energy is a strategic input worth a line on the roadmap, not an expense to be managed downward after the fact.

Part Four: A Working Framework for Product Teams

Pulling this together — here's a version a PM could actually use. Not a manifesto, just a checklist for the next roadmap review.

At the feature level:

At the risk level:

At the roadmap level:

That last question is the one I'd want readers to walk away with.

We're currently consuming without a strategy — is that a decision, or a default?

Most companies haven't actually decided to ignore their energy exposure. Nobody's ever asked the question in a room where it could become a decision instead of a default.

Conclusion

You don't have to believe AI's energy trajectory is catastrophic to believe it's under-managed. The demand curve is real, the grid's ability to keep pace with it is genuinely strained, and the companies moving with the most confidence right now are the ones treating energy as a strategic asset worth securing years in advance — not a bill to minimize after the fact. Everyone else is, in effect, choosing not to decide. And that choice has a cost, even if nobody's tracking it yet.

The line item is hidden mostly because nobody's opened the ledger. That's a fixable problem, and it starts with a PM willing to ask the question at the next roadmap review.

The bill for not deciding always comes due. It's just late.