Founder note
The grid opportunity was obvious. The product boundary was not.
I learned this lesson twice before WattShift. The first time was as the founder of a small distributed-energy device company called Cyberpowered Home, where I was trying to build something closer to what Span and Lumen now do. The second time was as product manager for thermostats and energy at Alarm.com.
In both cases, I knew there were real dollars and real customer value to be found from grid optimization. I knew about the duck curve. I knew there were cheap, cleaner times and expensive, dirtier times. I knew connected products should be able to respond to that reality intelligently. The hard part was not believing the opportunity existed. The hard part was making it survive contact with product scope.
The second time
At Alarm.com, we were not coming at this from a naive starting point. We had a smart team. We had an energy-forward posture. We even had a subsidiary, EnergyHub, that is a leader in demand-response programs, and we already had a relationship with Genability for what was, at the time, best-in-class utility rate data.
We ran trials. We had the right instincts. But even with the right relationships and a strong setup, it was obvious we were not going to build the product at the scale we needed by doing it utility by utility. The spreadsheet always made sense until we asked how many customers a given utility represented, how many exceptions the product would inherit, and who would maintain the next one.
The economic signal matters enough to change product behavior.
Each territory adds tariffs, programs, export logic, and policy edge cases.
A single utility may represent only a couple percent of the reachable base.
The problem was not just technical difficulty. It was product economics. To keep going deeper, we were going to have to do far more work per utility than we could justify for the number of people affected, inside a company that was also trying to grow across many markets, including internationally.
So even at a company that was relatively energy-forward, with real capabilities and the right partnerships, we still could not invest into these opportunities the way we would have liked. That is the part that stuck with me. If a team with EnergyHub nearby, Genability in the stack, and strong product instincts still could not justify the surface area, then the missing piece was not just another data source.
The pattern
The problem was structural, not informational. The issue was not that we needed one more feed or one more pilot. The issue was that the abstraction kept leaking into product code. What should have been one reusable economic layer kept turning into territory-specific branches, market exceptions, and one-off operational logic.
Internal versions usually start as a reasonable shortcut for the first market. Then they become partial integrations, brittle policy branches, and logic that only makes sense to the person who added the last exception. The problem is not that teams are careless. The problem is that the system boundary is wrong.
Messy utility and market context in. One product-ready signal out.
That is the thesis behind Price Signals. Not a prettier dashboard of inputs. Not five feeds handed to every product team to reconcile on their own. A product boundary that gives software one answer it can actually build on.
That is what pushed me toward a stronger abstraction and eventually toward building WattShift. I wanted the kind of layer I had wished for when the opportunity was obvious but the product surface area kept making the right thing hard to justify.
The product page explains what Price Signals looks like in practice. This page is just the reason I think it needed to exist.