A team on the far side of the company stopped using an internal tool we had built for them. Quietly. No ticket, no complaint, no exit interview. They stood up their own version over a couple of weekends, wired it into their workflow, and moved on. I only found out later, and when I did, the reflex fired before I could think — the reflex every security and platform leader is drilled into. Unsanctioned. Off the paved road. A finding.
I have come to believe that reflex is one of the most expensive mistakes internal IT makes. Because that team was not committing a violation. They were writing a review. They had evaluated our product against the alternative of building their own, our product lost, and instead of reading the review my first instinct was to shut down the reviewer.
Here is the uncomfortable premise of this whole essay: if the people you serve are not allowed to say no to what you build, you will never know whether it is any good. Run internal IT as a monopoly and you get a monopoly's product — slow, unloved, and quietly routed around. Run it as a product that could lose the account, and you might build something people actually choose. The difference is not a technology. It is whether your users have the right to defect, and whether you have the discipline to treat defection as data.
Shadow IT is market feedback, not a violation
Analysts have estimated for years that a large and growing share of technology spending now happens outside the formal IT budget — bought on a corporate card, stood up in a SaaS trial, never routed through a procurement queue. The usual read on that number is a governance failure. I read it as a product review, aggregated across the whole company. Every instance of shadow IT is a team telling you, in the only language that is not cheap talk, that going around you was faster or better than going through you.
The compliance-only response is to hunt it down and shut it off. That response destroys the signal and the trust in one move, and it fixes nothing, because the reason the team went around you is still sitting there. The product response is to treat each instance as a bug report filed against your own offering. Why was the sanctioned path slower? What did the unsanctioned tool do that yours did not? What would it have taken for the team to choose you?
None of this means all shadow IT is benign. Customer data sitting in an unsanctioned SaaS with no data-processing agreement is a real problem, and in regulated fintech — where the platform I help run ultimately serves more than 1,500 financial institutions — some boundaries are not negotiable and never will be. But those are the exceptions. The overwhelming majority of shadow IT is not a team trying to exfiltrate data. It is a team trying to ship, telling you your road was too slow. Learn to tell the two apart, because the answer to a genuine risk is a control and the answer to a lost sale is a better product.
Every internal platform needs a product manager, not just an owner
Almost every internal platform has an owner — someone accountable for uptime, on the pager, closing tickets. Almost none has a product manager — someone accountable for whether anyone actually wants to use the thing. That single missing role is why so many internal tools feel like internal tools: technically alive, quietly resented, adopted only where adoption was compulsory.
A product manager for an internal platform does the unglamorous product work that ownership skips. Discovery before building — talking to the engineers who will use it, watching how they actually work, before a line of the roadmap is committed. A roadmap prioritized by user pain rather than by the loudest executive in the last meeting. The discipline to say no to features. A backlog treated as a product backlog, not a queue of internal favors. This is the idea Team Topologies calls "platform as a product," and it is not a metaphor — it is a staffing decision. We built AgentOS, our governed internal agent platform, this way from the start: someone owned the roadmap and the discovery, not just the on-call rotation. The question "does anyone actually want this" had a name attached to it.
Adoption is the metric that can't lie
Internal IT is addicted to vanity metrics, and the worst of them wear the costume of success. Seats provisioned. Tickets closed. "One hundred percent of teams onboarded." Every one of those can be true while not a single person uses the platform for real work. Mandated adoption is a number that lies to you, because you manufactured it by force. Voluntary adoption is the number that cannot lie, because nobody made it happen.
So measure the way a consumer product measures, and be honest about what each one is telling you:
- Activation, not provisioning. Not how many accounts exist, but how many reached first real value — shipped something, ran something, kept the result.
- Retention, not onboarding. Of the teams that tried it, how many are still using it eight weeks later without being told to. Onboarding is a spike; retention is the truth.
- The defection rate. How many teams evaluated the paved road and built their own anyway. This is the metric internal IT never reports, and it is the most important one you have.
- Delivery outcomes. The DORA metrics — deployment frequency, lead time, change-failure rate, time to restore — answer the only question that justifies the platform's existence: did it make delivery faster and safer, or merely more governed?
The SPACE framework, from the research group behind the DORA work, is a useful corrective here: developer productivity is multi-dimensional, and any single number you optimize will be gamed. But the tell is simple. If the only way you can report high adoption is by counting the people you forced onto the platform, you do not have adoption. You have attendance.
The paved road wins by being better, not by being mandated
The paved-road idea is not mine. Netflix popularized the term; Spotify shipped "golden paths" and open-sourced Backstage, the developer portal that made internal platforms legible; Team Topologies gave us "the thinnest viable platform." The common thread is a well-supported default path that makes the right thing the easy thing. The part most teams miss is the part that makes it work: the paved road only earns its name if you are allowed to leave it.
The moment you mandate the road and wall off the exits, you stop receiving the one signal that tells you whether the road is any good. A mandated platform never has to beat the alternative, so it never does. Optionality is a forcing function. It keeps the platform honest, because the platform has to keep winning the choice.
We ran AgentOS exactly this way. It is a governed agent platform, which means the guardrails — identity, logging, the control plane that keeps agents inside their lane — are the entire point. But teams did not have to use it. They could have wired up raw model access themselves. So the paved road had to win on its own merits: faster to build a safe agent with us than to roll your own without us, with the governance included rather than bolted on afterward. When the road wins because it is genuinely better, you get adoption and governance in the same motion. When it wins only because it is mandated, you get neither — compliance theater on the surface and a shadow copy underneath.
There is a boundary to this, and it matters. A handful of things are non-negotiable, and you do mandate them: nobody defects from encryption, from centralized logging, from your identity model. Those are the high curbs. But the curbs should be few and the road should be wide, and inside those boundaries you compete for every user the way an external product would. Mandate the boundary. Earn the surface.
Fund it like a product, staff it like a startup
Here I am reasoning toward a seat I do not sit in. I run a platform and I built an internal product with real users; I do not run an enterprise IT P&L, and I am not going to pretend the capital planning is simple. But I have watched the failure from close enough to name its shape. Internal platforms get funded like projects — a capital push, a launch event, a ribbon, and then slow starvation as the money moves to the next launch. Products do not work that way. A product is a standing team that keeps shipping because the work is never done, because the users keep changing, because the alternative keeps improving.
The framing that helps a CIO defend a standing team instead of a one-time project is cost transparency — Technology Business Management gives you the vocabulary to show internal customers what the platform actually costs and what it saves them against the do-it-yourself path. That is the argument that survives a budget cycle. Staff the team thin — the thinnest viable platform, not an empire — and hold it to the same standard you would hold a product with paying customers, because in the only sense that matters, it has them. They can leave. That is the whole point.
Run internal IT like it could lose the account
If you own an internal platform, or you are the executive deciding whether to fund one like a project or a product, four things carry most of the weight:
- Give every internal platform a product manager and a roadmap people can see. Not just an owner with a pager.
- Measure voluntary adoption and the defection rate. Treat shadow IT as your most honest user research, not your worst compliance finding.
- Mandate the few boundaries; compete for everything else. Win the surface by being better, not by removing the exits.
- Fund the paved road as a standing product. Launches starve; products ship.
I have made the shut-it-down mistake, and I have made the better one, and the better one felt worse in the moment and paid off every time. So I will put the question to you directly, and I would genuinely like the replies: what did your best internal tool do that made people choose it when they did not have to — and what did the shadow-IT version do better? Tell me in the comments. The defection you are embarrassed about is probably the sharpest product feedback you have ever gotten.
