Early in my product career, I worked on software that was being used to make daily bidding and scheduling decisions in U.S. electricity markets.
Then in February 2021, Winter Storm Uri pushed the Texas grid into crisis. As the cold set in, our forecasts showed an unusually wide gap: day-ahead price forecasts well below our real-time price forecasts.
A customer called us with a question we should have seen coming: “should I actually trust this enough to act on it?”.
They operated a portfolio of different asset types and had to decide how much capacity to commit in the day-ahead market and how much to hold back for real time. Because our forecasts were showing much higher prices in real time than for the day ahead, acting on the forecast meant holding back more capacity and taking the risk that the price spike might never materialize. In the end, they split it roughly 50/50.
What happened next showed why the decision was so difficult. The most severe scarcity ultimately appeared in the real-time market. ERCOT real-time prices sat at the $9,000/MWh system-wide offer cap for most of February 15–19, partly because regulators directed ERCOT to hold prices there. Day-ahead prices rose too, but they underestimated how long the scarcity would last. So the direction of our forecast was useful: real time became substantially more valuable. But before the event unfolded, the customer had no easy way to see why the forecast was making that call or how much uncertainty was behind it. That was the trust gap.
Our customer’s problem revealed an important distinction: in electricity markets, a technically correct product is not the same as a useful one. The experience changed how I thought about analytical products. The output itself was only part of what we were delivering.
In markets where forecasts are uncertain and decisions carry real financial consequences, users also need to understand why a recommendation is being made and what could cause it to be wrong. That idea followed me into later work on battery optimization and electricity-market design, where the hardest product problems were often not about generating more intelligence, but making that intelligence usable.
1. Correct isn't enough. The output has to be actionable.
From the development side, the natural question after Uri was: was our price forecasting model working correctly? On the customer's side, there was a different set of questions: what should I do with this number, and how much should I bet on it?
So we stopped treating the price forecast as the whole deliverable. We added the drivers behind it: the forecast day-ahead/real-time spread (DART Spread), the probability of a real-time price spike, and confidence intervals around the forecast. We also added alerts tied to ERCOT Energy Emergency Alert levels 2 and 3, so users knew when the grid had entered conditions where normal price behavior no longer applied.
While none of this made the forecast more accurate it definitely made it easier to act on. A customer facing the Uri decision again would see not only that real-time prices were forecasted to spike, but how likely the spike was, how wide the uncertainty was, and that the grid was already in emergency operations.
This made a visible difference. During Winter Storm Elliott in December 2022 and Winter Storm Heather in January 2024, we received noticeably fewer calls asking whether to believe the numbers and customers were more willing to let the forecast-driven recommendations stand.
As a product manager, that taught me to spend more time asking what decision the customer was actually trying to make instead of what outcome we could produce. A sophisticated product that customers second-guess in a crisis is less useful than one whose drivers they can see.
Figure 1. Actionability builds in layers. After Uri, we added drivers, uncertainty and decision context on top of the forecast itself.
2. Build around uncertainty instead of pretending it doesn't exist
That lesson became even more important when I worked on battery optimization, a problem that is growing quickly: according to the Energy Information Administration (EIA), planned additions would take ERCOT battery capacity from about 15 GW in 2025 to 37 GW by the end of 2027.
At any moment, a battery operator has to decide whether to charge, discharge, hold energy, or provide ancillary services. The best decision depends on what prices will do next, and much of the revenue comes from a small number of price spikes. Miss those, and a good month becomes a mediocre one.
Our original optimiser was stochastic: it planned against a set of price scenarios and produced a single hedged schedule. But in summer 2023 and winter 2024, it missed several price spikes. We had two options: we could stay with the stochastic approach and spend the little development time we had on other features or rebuild the core of the optimiser.
We decided to rebuild it. Instead of asking one stochastic optimiser to produce a single compromise schedule across many possible futures, we ran a deterministic optimization against six different versions of the price forecast, from very conservative to very aggressive. Think of the forecasts as six possible futures: the middle one represented our most likely case, while the outer bands represented less likely but more extreme price outcomes.
We then used those bands to build the battery’s bids and offers. For example, part of the battery could be offered at a price consistent with the central forecast, while another portion could be held for a much higher-price scenario. If the price spike never happened, that higher-priced capacity simply would not clear. If it did happen, the battery still had capacity positioned to capture it.
State of charge remained a hard constraint throughout, so the optimizer could not make a financially attractive recommendation that the battery was physically unable to deliver.
This also changed what users could see and control. They could choose which band to follow in their bidding strategy and they could always override the optimiser’s recommended bidding strategy if they disagreed with it.
The real trade-off for users was control. A stochastic model hides its reasoning inside a blended schedule, which makes it hard to question, but also hard to tamper with. A banded, deterministic approach is easier to understand, but that also makes it easier for users to adjust individual settings or override the recommendation. We observed that users who frequently tweaked settings and overrode the model had more missed spike days than users who let it run autonomously.
As Box and Draper put it, all models are wrong, but some are useful. We had stopped trying to build a model that was always right and focused on building one that stayed useful even when the forecast was wrong.
The harder lesson was that making a model understandable does not automatically make every intervention a good one. Interpretability builds trust, but it also gives users more ways to overrule the model, and the product has to be designed with that in mind.
Figure 2. Offers placed at different forecast bands let a battery capture a spike that the central (P50) forecast misses.
3. Sometimes education is part of the product
Even a well-designed product is hard to use if customers don't understand the market it operates in. I saw this most clearly during ERCOT’s move to Real-Time Co-optimization plus Batteries (RTC+B) in December 2025. The change meant batteries would no longer be treated as a special case in the real-time market: ERCOT would continuously evaluate how they could provide both electricity and grid-support services while accounting for how much energy they actually had stored.
Before RTC+B, a battery’s ancillary-service commitments were largely treated as fixed input when ERCOT determined its real-time energy dispatch. In simple terms, if a battery had already committed part of its capacity to help stabilize the grid, the real-time market took that commitment as given and optimized around it.
Under RTC+B, those decisions became connected. Every five minutes, ERCOT could evaluate energy and ancillary services together while also checking whether the battery actually had enough stored energy to support what it was being asked to provide.
For our optimization software, that changed the problem. We could no longer think only about which market product offered the highest price. We also had to account for how one award reduced the energy available for another opportunity later.
The biggest misunderstanding customers struggled with was about duration: how many hours of stored energy a battery has to hold in order to back each megawatt of an ancillary service. Many assumed those requirements would carry over unchanged. As it turned out, they did not.
Under Nodal Protocol Revision Request 1282 (NPRR1282), an ERCOT market-rule change, the minimum duration requirements for several ancillary services changed. These services are essentially different ways batteries can get paid to help keep the grid balanced. Regulation and Responsive Reserve Service (RRS), which provide fast grid support, dropped to 30 minutes. ERCOT Contingency Reserve Service (ECRS) dropped to one hour, while Non-Spinning Reserve (Non-Spin), a backup reserve product, remained at four hours. The important change was how those requirements would now be enforced. In practice, batteries had often treated Non-Spin and ECRS as roughly one-hour commitments in real time. Under RTC+B, ERCOT began checking whether the battery actually had enough state of charge to support the full duration of its award. For Non-Spin, that could mean reserving roughly four times as much energy as before, leaving less of the battery available for other revenue opportunities.
Some customers had asked us to preserve their existing Non-Spin “stacking” strategy under RTC+B. In simple terms, they wanted to commit part of the battery to Non-Spin while still using the remaining capacity to pursue other market opportunities. Supporting that approach was on our roadmap. In the RTC+B customer webinar and in internal sessions, I walked through the new duration rules and showed what they meant for the battery’s state of charge. Once customers and our own teams saw how much more energy a four-hour Non-Spin commitment could tie up, the economics changed under these new rules. The feature we had planned was based on assumptions that would no longer hold under the new market design, so we dropped it from the roadmap.
That changed how I think about adoption in complex industries. Sometimes, the barrier is not functionality, but the fact that users can’t yet understand why the product behaves the way it does. Part of the PM’s job is translation: connecting market rules to software behavior, and software behavior to the customer’s next decision.
Figure 3. Ancillary-service duration requirements before and under RTC+B.
What these experiences changed for me
Now, when a customer asks for another feature, I first try to understand the decision they are struggling with. When a model produces a recommendation, I ask what happens when its forecast is wrong, and what happens when the user overrides it. And when users aren’t adopting something we’ve built, I ask whether the problem is really functionality, or whether we haven’t explained the system well enough.
Sometimes the most important product decision is not adding more intelligence. It is making the intelligence you already have usable when it matters most.
