I don’t come from energy, and nothing here pretends otherwise. Instead, this memo walks through how I’d scope and run a customer PoC for you, with each judgement call tied to something I’ve actually done.
The customer below is invented. The method, and the evidence in the margins, are not.
On paper the site is full: capacity contracted out, AI tenants being turned away. In practice, metered load peaks in the low 60s. A bigger connection is quoted years out, so the gap between paper and practice is dead capital. The question the customer would pay to have answered: how much more load can we safely host on the connection we already have?
That’s the question I’d anchor the PoC to. Not because it’s the easiest one, but because it’s the one with money already riding on it: a PoC that answers a question the customer was already asking doesn’t need to be sold twice.
My back-of-envelope for the first scoping conversation: a hard connection ceiling, an untouchable reserve, and between them the band this PoC exists to size. Drag the slider to see why that band is worth eight weeks of anyone’s time.
< drag > or use the buttons: raise the operating limit and watch what comes free.
Illustrative and directional: my own model built from public material, not Zendo’s numbers. I’d expect the founders to redline it in the first conversation, and the plan below assumes exactly that.
Agree the single question, the one site, and what success looks like, with the people who’ll have to defend the result. Define “safe” with the customer’s engineers before touching any data: their redundancy rules, their contractual limits, written down and agreed.
Pull historical metering and load data, then walk the site and interview the ops team on how they actually run it versus what the paperwork says. Audit data quality in week 2, not week 6. That’s where pilots quietly die.
Profile actual against contracted load, size the stranded band, and stress test how much comes back under forecast driven limits. Every estimate carries a range and a written assumption.
One number with confidence bounds, the operating changes needed to capture it, the risks, and a clear go / no-go with a rollout path. If the honest answer is “less than hoped”, that’s still a good PoC. It just saved everyone a bad rollout.
Historical power draw and IT load at whatever granularity exists, cooling headroom, contracted versus connected capacity, incident history. Collected via metering exports, structured ops interviews and one site walk.
A reclaim number the customer’s own ops team will put their name to, and a clear yes or no on rollout. The deliverable is a credible decision, not a flattering one.
Data gaps: audit first, model second. Ops scepticism: co-author the safety definition with them in week 1. Overpromising: the number ships with its error bars.
Prove one undeniable number on one site before surveying anything broadly. The fastest route to a paid rollout is a single result the customer’s ops team will co-sign: depth over breadth. Start where the gap between contracted and actual load is widest and the freed capacity already has a buyer’s name on it. Then write everything down, because the write-up of the first PoC is the first page of the playbook the next ten run on.
EquiTie is a private markets platform: early team, roughly 200 investors, $30M+ of deployed capital. Leadership wanted a full investor app and portal: months of engineering, no evidence anyone would use it. I made the case to test demand first, and got the mandate to run it.
Ten structured interviews, then working prototypes built with AI coding tools, because what people adopt and what they say they want are different data. The friction lived in onboarding and deal structuring, not the wishlist. Four of seven features were cut before build; the roadmap moved to where the pull was.
internal analytics platform I co-owned at Barclays, grown 60x and trusted with front office workflows
Finance and Risk data operations rebuilt across regions
recovered for the business through automation
The system changes. The method doesn’t.
At EquiTie it was investor workflows. At Barclays, markets and risk data. At Zendo it’s energy and load: I’d be learning that layer from your team while running the parts I already know cold.
The useful version of me on day one isn’t a half-trained energy analyst. It’s an operator who takes ambiguous, cross-functional problems and drives them to a decision: scope it, get the data, build the artefact, force the call. That’s been the job at a global bank, at a private markets startup, and now at my own consultancy, where every engagement starts in a domain I didn’t know the month before.
Nobody asked for this memo. That’s the point.
SQL, Python and BI tooling in daily use since 2020, plus the habit of showing my working.
CS degree, production code shipped, agentic tools daily. This page: one file, built by hand, no framework.
Three industries in six years, energy next. “We don’t know yet” is a place I can work from.
Why this role, after starting my own consultancy? Because Lean Multiple was built for breadth, and it taught me I want the opposite next: one hard problem, a small team that owns it, and enough surface area for judgement to show. A physical constraint with a software lever is exactly that problem.
Every system I’ve worked on had more in it than its owners could see. Finding that capacity is the job I want.