Proven to Optimized is a short blog series drawn from lived experience on both sides of the implementation table. After more than two decades working within a utility, I’ve seen how early, well-intentioned market decisions tend to persist long after their original context has changed.
Now working from the vendor side with many utilities at once, I see those same patterns repeat. Markets+ creates a rare before designs, workflows, and integrations get locked in again.
This series explores that moment — what tends to stick, why it does, and how experience can be used before go‑live to move from what’s proven to what’s truly optimized.
In Part 3, I look at how to find those opportunities once a market has gone live and the early decisions have settled into routine. The focus here is on the workflows that still work exactly as intended, and why those are often the ones most worth a second look.
One of the most common misconceptions about optimization is that it starts by identifying something that’s broken. In practice, the workflows most worthy of review are often the ones that appear to be working exactly as intended.
They produce reliable results, people understand them, and new employees learn them as a matter of course. Nothing about them generates enough frustration to trigger concern. Over time, those characteristics create a sense of permanence. The process works, so it remains in place – “why do we do it like that?” … “because we always have…?”
That’s easy to miss coming out of Part 2, where the focus was on how technical debt originates from good decisions made under real constraints, and how those workarounds rarely disappear once the constraints do. The question this post asks is different: How do you determine which processes still add value and which have simply become familiar?
That stability can be an asset, or it can be the thing nobody questions. It makes optimization opportunities difficult to recognize.
When preparing for a new market implementation, attention naturally flows toward what has to be built: new interfaces, new reports, new integrations, new operating procedures. That focus is necessary. Some of the most meaningful improvements are found by looking in the opposite direction: at the processes already in place, the ones no one thinks to question.
That’s where optimization actually begins: not by asking what’s broken, but by asking whether what works today is still the best answer for tomorrow.
A useful way to start is to take a single business outcome and trace it end to end. Pick a settlement validation, a market operations workflow, or a daily reporting activity, and follow the information through every handoff, review, export, import, reconciliation, and approval. At each step, ask one question:
What problem does this solve in the current operating environment?
Not the problem it solved when it was created, or the concern that justified it during certification. What does it solve now?
What does it do today?
Workflows are often built around conditions that no longer exist. A reconciliation step may have been added when trust in a new platform was still forming. A manual review may have been necessary because the system couldn’t yet surface a calculation. A report may have become essential simply because it was the only practical way to get at the data.
Each of those was probably the right call at the time. The challenge is that successful processes tend to outlive the circumstances that created them.
The largest opportunities are usually not inside the core system. They’re at the boundaries between systems.
Consider a common pattern. Market results are exported to a file, reformatted in another tool, reviewed in a spreadsheet, emailed for approval, and then entered somewhere else. Every one of those steps looks reasonable on its own. Together, they add delay, effort, and dependencies that may no longer need to exist. When that export-reformat-reconcile loop was built, the platform was new and its outputs needed independent verification. Once direct integration handles that validation, the export-reformat-reconcile loop stops protecting anything. It’s just added delay.
The same thing happens with reconciliation between two “source of truth” lists. Standing up a new market means mapping one organization’s inventory against a target list and truing up the gaps. That is essential work during implementation. But if it hardens into a manual step repeated every cycle, it’s worth asking what it’s still solving. It was built to answer the question, “Do we trust that these two lists agree?” Once the mapping is stable, that is a different problem, or no problem at all.
These activities rarely draw attention, because they accumulate gradually. A review step is added after a market event. A validation is introduced following an audit request. A checkpoint stays in place because it has always been there. Eventually they become part of the operating rhythm and get accepted as simply how the work is done.
This is where experience becomes valuable in a way earlier implementations couldn’t access. Organizations entering a new market now carry years of operational history. They’ve seen which risks actually required oversight, and which controls were mostly there to build confidence early on, before anyone trusted the new platform.
Used well, that history becomes a filter: a way to tell which workflows are still earning their place and which ones are just left over from an earlier setup. Some workflows continue unchanged because they still deliver value. Others reveal room to reduce manual effort, simplify data movement, or take advantage of capabilities that didn’t exist when the process was first designed.
Not every legacy step needs to go. Some still earn their place. The goal is deciding on purpose, instead of by default.
Because once a new market goes live, today’s decisions become tomorrow’s standard operating procedures. And if history is any indication, they’ll likely remain in place far longer than anyone expects.
In Part 4, I’ll move from finding the friction to acting on it: weighing which processes to carry forward, which to rebuild, and which to let go, without trading away the control that made them worth having in the first place.
If you’re just joining the series, start with Part 1: Why Early Market Decisions Are So Hard to Undo and Part 2: How Proven Decisions Become Technical Debt. Both lay the groundwork for what’s covered here.
