In software, product people obsess over funnels.
Acquisition, activation, retention, expansion. We draw the steps, measure conversion, identify drop-offs, argue about friction, and look for leverage. We know that a product can be desirable and still fail if the path from interest to value is too slow, too confusing, or too expensive.
Clean energy has a funnel too.
It is called interconnection.
A project starts as a promising idea: a solar site, a battery, a fleet depot, a data center, an industrial load, a charging hub. The business case may be strong. The customer may be real. The land may be attractive. The technology may be mature.
Then the project enters the process of asking the grid a simple question with a complicated answer:
Can this connect here?
The answer determines whether the project is real.
The Funnel Nobody Can Ignore
Interconnection is often described as a technical or regulatory process, which it is. But from a product and business perspective, it behaves like a funnel with expensive drop-offs.
At the top, there are many possible sites and many possible projects.
Then the funnel narrows:
- Which locations have plausible capacity?
- Which points of interconnection avoid obvious overloads?
- Which projects trigger network upgrades?
- Which upgrades are tolerable?
- Which queue positions are viable?
- Which assumptions survive formal study?
- Which projects still make economic sense after the study result?
Every drop-off costs time, attention, capital, and organizational confidence.
In normal SaaS, a bad funnel might waste marketing spend or lose a trial user. In energy, a bad funnel can waste months of diligence, legal work, engineering effort, land spend, customer expectation-setting, and executive attention.
That is why interconnection intelligence matters.
It helps teams understand the funnel before they are trapped inside it.
Interconnection Is Not Just Permission
A common mistake is to think of interconnection as permission.
Permission is part of it, but the more useful framing is this: interconnection reveals the cost of a project's assumptions.
If you want to inject power at this substation, what else has to change? If you want to serve this load, what constraints appear under contingency conditions? If a nearby project comes online first, how does your result change? If the queue changes, which assumptions break? If the utility model is updated, what happens to your upgrade exposure?
This is why the process feels so frustrating from the outside.
The project developer wants a decision. The grid gives back a model-dependent answer.
That answer is not static. It is shaped by other projects, transmission topology, study methodology, reliability rules, and timing. The grid is not a vacant lot waiting for a tenant. It is a live system with many parties trying to use scarce capacity at once.
The practical implication is that a project team needs to manage uncertainty, not just wait for certainty.
Queue Position Is Strategy
Queue position sounds administrative until it decides the business.
If a project is early enough, it may have access to capacity that later projects do not. If it is late, it may inherit upgrade costs created by a crowded queue. If it is in the wrong cluster or study process, it may wait through cycles of rework while assumptions shift underneath it.
This makes interconnection timing a strategic variable.
Product teams understand this in other contexts. A feature launched before a regulatory change may win a market. A platform built before a partner ecosystem matures may sit unused. Timing changes the value of the same work.
Energy projects are no different.
The same site can be excellent or terrible depending on when it enters the queue, which other projects are nearby, what upgrades are already planned, and how load growth changes the local picture.
Treating this as pure execution misses the point.
It is strategy.
The Cost of Late Learning
The most expensive learning happens after a team has become emotionally and financially attached to a plan.
By the time a formal study result arrives, many organizations have already built a story around the project. The site has a name. The model has assumptions. Customers have heard timelines. Executives have seen slides. Partners have been briefed.
Then the interconnection result breaks the story.
The upgrade cost is too high. The timeline is too long. The network impact is worse than expected. The apparently obvious point of interconnection was not obvious at all.
Good product organizations try to move learning forward.
They prototype before building. They test before scaling. They talk to users before hardening requirements. They validate pricing before investing too much in packaging.
Energy teams need the same posture around interconnection.
Move the learning earlier.
Not because early models are perfect. They are not. But because imperfect early insight can still prevent obviously bad decisions, sharpen the shortlist, and give the team a better set of questions when it does engage with utilities, ISOs, consultants, and formal studies.
Software's Job In The Funnel
Software should not pretend to replace the interconnection process.
That would be the wrong ambition.
The right ambition is to improve the decisions around the process:
- Screen more sites before committing resources.
- Compare points of interconnection under consistent assumptions.
- Estimate upgrade exposure early enough to matter.
- Track queue changes and competing projects.
- Preserve the reasoning behind site selection.
- Give commercial teams language that matches technical reality.
- Help executives understand risk before it becomes a surprise.
This is where product thinking becomes useful.
The user is not asking for a prettier map. The user is trying to avoid false confidence. They need to decide where to spend scarce development effort. They need to know which projects deserve diligence and which should be dropped before they become expensive.
The product has to serve that decision.
Interconnection As A Company Capability
The teams that win in constrained markets will not treat interconnection as a late-stage specialist function.
They will treat it as a company capability.
Development, finance, engineering, product, sales, and leadership all need a shared understanding of what the grid is allowing, what it is resisting, and which assumptions are doing the most work.
That does not mean everyone becomes a transmission planner. It means the organization learns to respect the funnel.
In a world of rising load, crowded queues, and scarce capacity, the best commercial idea is not enough. The best hardware is not enough. The best customer relationship is not enough.
The project still has to make it through interconnection.
That is why interconnection deserves product-level attention.
It is the funnel between ambition and electrons.