EnergyData platformIncubation2023

From a working sensor network to a product grid operators can use

How I gave E.ON Brightfield's real-time grid data a clear product shape: three user groups, three use cases, one MVP.

Grid Planning over central Munich, with one transformer's live readings.

~600M
sensor data points per city per day: 3
user groups, each with its own use case: 2 of 3
use cases in development at handover

My role

From June to December 2023, I led product scope, prioritisation, and the design and data-engineering workstreams from MVP definition into development. Specialists owned sensor hardware, data science and cloud infrastructure. On the client side, I worked with Brightfield's COO and her development team.

Context

Germany's distribution grid is largely unmonitored where it matters most: transformers report almost nothing, so renewable integration and grid expansion are planned on historical estimates. Brightfield retrofits transformers with real-time data units, without infrastructure upgrades. The hardware and data pipeline already worked. What didn't exist was a product: the prototype was engineering-led, the requirements were fuzzy, and nobody had defined who it was for.

The challenge

Discovery showed three user groups with incompatible needs: grid planners who need network-wide load and capacity, dispatchers who need at-a-glance status to act on anomalies, and field staff who need to know which of dozens of transformers to visit first. One dashboard would have served none of them well.

What I did

Structured the platform into three use cases — Grid Planning, Load Management and Asset Management — and defined them against German grid operators' redispatch and network-planning obligations, so regulation shaped scope instead of sitting beside it.
Chose signals by reliability, not ease of build. Temperature and humidity first, load third; gas sensors deprioritised because passing cars, livestock and exhaust set them off.
Showed honest uncertainty. The load forecast wasn't yet accurate enough to display sharply, so we flattened it and wrapped it in an uncertainty halo — users saw the confidence they were actually entitled to.
Cut data volume by lowering the sampling rate. Transformer temperature can't change meaningfully second to second, so users lost nothing.
Piloted with an unpaid user rather than the first paying customer, to protect the client's confidence while the product was still unresolved.
Moved subnetwork-level detail to a v2 to keep the MVP inside the sprint window.

Dashboard showing a 24-hour average load chart, selection details and overall load statistics for a transformer. — Transformer Power: load patterns across a day, with peaks and unused capacity.

Time-series chart of transformer power against grid frequency, with a flattened forecast and a shaded confidence band. — Load forecast shown with its uncertainty band, rather than a false precision.

Key decision

Sequence against instinct. Asset Management was the strongest concept in the room, but I put it behind Grid Planning and Load Management to reach usable value sooner.

Outcome

Handed over a defined three-use-case product with a prototype: Grid Planning and Load Management in development, Asset Management drafted and reviewed.
The client's developers confirmed feasibility, not just the design.
My "Overall Grid Status" concept for dispatchers was singled out in the final review.
The client described the handover as a good way forward.

What I learned

Decide who a product is for before deciding what it does. And stay close to the field: the client, not our team, spotted that selecting a transformer wasn't intuitive — our validation loop needed to be tighter.