Most Enterprise Platforms Die at Hour 50
The Broadcast Team That Needs to Integrate#
There is a broadcast operations team at a European football league. They have been producing matches for fifteen years. They know their workflows. They know their equipment. They know the exact sequence of decisions that turns six camera feeds into a live broadcast that half a million viewers watch without ever thinking about how it gets made.
They have heard about OZ. They understand the proposition: AI-powered spatial intelligence running at the venue, real-time player tracking, the Venue Graph as a live data layer for everything happening on the pitch. They can see how spatial data could transform their production workflows: automated camera selection based on the state of play, dynamic graphics driven by player positions, post-match analytics generated from spatial data instead of manual tagging.
They are interested. They are also wary. Because they have been here before.
"Every integration partner has a story like this," Sunil says. "They've been burned. They invested six months learning an enterprise platform only to discover that the API changed between versions, that the documentation was optimistic about edge cases, that 'real-time' meant 'eventually, under ideal conditions.' They carry scar tissue from vendor relationships that consumed more time than they saved."
This team is the hero of this story. Not OZ. Not Sunil. The team trying to do their job (produce great broadcasts) with a new piece of infrastructure they didn't build and don't fully trust yet.
Powerful Platforms Become Shelfware#
The integration team's fear is specific and justified: that OZ will be yet another powerful platform that requires a six-month onboarding cycle, endless configuration, and a dedicated engineer just to keep the integration alive.
"The failure mode of powerful platforms isn't that they don't work," Sunil explains. "It's that they work brilliantly once you've invested 500 hours of configuration and integration effort. The problem is that most teams never get to 'once.' They stall at hour 50. The learning curve defeats them. The configuration complexity overwhelms them. The platform becomes shelfware: installed, licensed, unused."
He has seen this pattern from both sides. As an engineer building platforms, and as someone who has watched integration partners abandon them. The root cause is always the same: the platform was designed for the capabilities it provides, not for the journey from zero to production.
"Enterprise platforms optimize for feature completeness. They ask: 'What can the platform do?' We ask a different question: 'What does the user experience in their first hour?' Because if the first hour is configuration files, data format definitions, and login troubleshooting, you've already lost. The user has formed an opinion of your platform, and that opinion is: this is going to be painful."
Designing for Time-to-First-Value#
Sunil's role at OZ is to ensure that the time between first login and first value is measured in minutes, not months. He leads the OZ Studio tech stack, the operational console through which integration partners interact with OZ's spatial intelligence platform.
"Time-to-first-value is the only onboarding metric that matters," he says. "Not time-to-first-config. Not time-to-first-API-call. Time-to-first-value, the moment where the user sees their own data, in their own workflow context, and thinks 'this actually helps me do my job.'"
This distinction (between configuration and value) drives every design decision in OZ Studio. The system doesn't begin with a setup wizard that walks you through 47 configuration screens. It begins with a live spatial feed.
"When you log into OZ Studio for the first time, you see entities being tracked in real time. Players moving on a venue map. Trajectories rendered. Zones highlighted. Events firing. You see the Venue Graph alive, not described in documentation. Within the first two minutes of your first login, you have visual confirmation that the system works, that entities are being tracked, and that the spatial data is structured and accessible."
Time-to-first-value is a critical but often overlooked moat in infrastructure platforms. A platform that delivers visible value in minutes creates a fundamentally different adoption curve than one that requires weeks of integration work before the first benefit appears. For OZ, reducing this time isn't a UX nicety; it's a strategic imperative, because every venue operator who reaches production workflows quickly becomes a reference customer, a training data contributor, and a switching-cost anchor.
From First Login to Production#
The onboarding journey has five steps, each designed to deliver value, not configuration.
Step one: First login, live spatial feed. The user logs into OZ Studio and immediately sees real-time spatial data from their venue. No setup required for this step. The OZ VI Venue hardware is already deployed and the perception pipeline is already running. The user's first experience is visual confirmation that the system works.
Step two: First spatial question. Within the same session, the user is guided to ask their first question of the Venue Graph. Not through documentation. Through an interactive explorer built into OZ Studio. They pick a spatial question ("who is inside this zone?", "who is nearest to this point?", "does this path cross that boundary?"), apply it to the live data, and see the answer in real time. They are now interacting with the spatial data, not just watching it.
"This step is where most platforms lose people," Sunil says. "The documentation is a PDF. The login flow requires a special account. The first query requires reading 30 pages of technical docs. We compress all of that into an interactive experience where the user builds a question visually, sees the result immediately, and then (only then) sees the equivalent code they can copy into their own system."
Step three: First integration test. The user connects their own system to OZ's Spatial API. Sunil's team provides ready-made integration templates for common broadcast systems, analytics platforms, and graphics engines. These aren't placeholder demos; they are working integrations that connect to the live data and produce output in the format the user's system expects.
Step four: First real output. The integration produces its first result in the user's own workflow: a spatial-data-driven graphic, a camera automation rule, an analytics dashboard, a tagged event feed. Not OZ's demo. Their product. Their workflow. Their output.
Step five: Production workflow. The integration moves from test to production. Monitoring is activated. Reliability targets are published for every integration endpoint. The system transitions from exploration to infrastructure, always there, always working.
Sunil Kashyap
Head of OZ Studio Tech Stack
“I measure success by how quickly someone stops thinking about the platform and starts thinking about their actual work.”
The Three Ways Platforms Fail#
Without proper onboarding, powerful platforms become shelfware. Sunil has watched it happen enough times to have a taxonomy of failure modes.
"Mode one: configuration paralysis. The user opens the admin panel, sees 200 configuration options, and freezes. They don't know which settings matter and which are safe to ignore. They schedule a meeting with the vendor's solutions engineer. That meeting is in two weeks. Momentum dies."
"Mode two: documentation mismatch. The API documentation describes version 2.3. The deployed system is running version 2.4.1. Three endpoints have changed. The user discovers this at hour 15 of their integration effort, not hour one. Trust erodes."
"Mode three: the integration cliff. The user follows the getting-started guide and has a working 'hello world' integration in 30 minutes. Then they try to build something real and discover that the getting-started guide covered 5% of the API surface. The remaining 95% is documented in a 400-page reference that assumes knowledge the user doesn't have. The gap between the tutorial and the real integration is a cliff, and most users fall off it."
OZ Studio is designed to prevent all three. Configuration is progressive: the system starts with sensible defaults and only surfaces configuration options when the user's specific workflow requires them. The interactive query explorer generates code against the exact API version deployed at the user's venue. And the integration templates bridge the gap between tutorial and production. They aren't 'hello world' demos but working integrations that handle the edge cases the user will encounter.
Infrastructure That Disappears#
"The broadcast team integrated spatial data into their production pipeline within their first week. Not because they are exceptionally skilled engineers (though they are). Because the platform was designed to get out of their way."
The team now uses OZ spatial data for three production workflows. Camera selection assistance: the system suggests which camera has the best angle on the current play based on entity positions and zone activation. Graphics triggering: player identification graphics fire automatically when entities cross screen regions. Post-match analytics: every spatial event during the match is captured, timestamped, and exportable for analysis without manual tagging.
"They stopped thinking about OZ as a vendor about three weeks in," Sunil says. "They started referring to the Spatial API the way they refer to their video router, as infrastructure. Something that's always there, always working, always producing the data they need. That's success. The platform disappeared."
He pauses, choosing his next words carefully.
"I think there is a misconception in enterprise software that complexity signals value. That a platform with a steep learning curve must be more powerful than one that's easy to use. The opposite is true. Complexity signals that the builder optimized for the builder, not the user. The most powerful platform is the one the user forgets about, because it's doing its job so reliably, so transparently, that it recedes from conscious attention and becomes part of the workflow."
The transition from "vendor" to "infrastructure" in a customer's mental model is the ultimate switching cost. When a broadcast team stops thinking about OZ as a product they evaluate and starts thinking of it as infrastructure they rely on, the relationship has shifted from commercial to operational. Infrastructure gets renewed. Products get compared. Sunil's onboarding approach is designed to accelerate this mental model shift by delivering production value quickly enough that the user never has time to think of OZ as anything other than infrastructure.
The Bridge Between Deep Tech and Real Work#
The interview has covered the journey, from a wary integration team's first login to a broadcast operation that uses spatial intelligence as infrastructure. But there's a broader point that Sunil keeps returning to.
"Everyone at OZ builds deep technology. Rushikesh builds hardware that survives five seasons outdoors. Bhagyashree builds AI models that track 22 players 60 times per second. Suresh builds a spatial engine that answers questions about the physical world faster than a human blink. This is extraordinary engineering. And none of it matters if the person who needs it can't use it."
"My job is the bridge. I take everything this team builds (the venue hardware, the AI perception, the Venue Graph, the Spatial API) and I make it accessible to someone who has never heard of spatial queries, who doesn't know what Arcflow is, who just wants to produce a better broadcast. The deep technology has to become invisible. It has to work so well, so transparently, that the user's entire attention stays on their own craft, not on ours."
He leans forward.
"The best platform disappears. You just do the work. That's the goal. That's the design principle. And every time an integration partner tells me they forgot they were using OZ, that they just did their job and the spatial data was there, I know we got it right."