Post-Launch: A Product Story
Last week, we finally launched Aria. We announced our Series A funding and put the product out into the world. Launches are exciting, and I’m still riding the high. But once the dust settles, the funding numbers and the press coverage are actually the least interesting parts of a startup. The interesting part is what you’re building, and why.
I joined Aria as the first product manager last April. There is a standard piece of advice in the tech industry that you should never be the first PM at a startup. If you have never read any of them, they generally go something like: not enough product clarity, structure, or repeatable processes for a PM to be maximally effective, and half of the employees aren’t sure why you exist yet.
Usually, this is good advice, and yet I’d do it again tomorrow. It turns out that when a technological shift is large enough, the old rules break. The chaos is exactly where you want to be. AI infrastructure is that kind of shift. Also, the founding team had the experience and vision. Customers were already validating it. And I’d spent two decades living the problem they were solving.
I started in networking as an operator with almost two decades building and running networks. First doing tactical communications in the military, then at much larger scales for the intelligence community. When someone reports an issue, it is always “it’s a network problem”. I was the person on the other end of those calls for a long time.
Eventually, I moved to the vendor side and became a product manager for one of the top network management platforms in the industry. That shift gave me a different view of the same problem.
As an operator, I lived inside fragmented tools. As a PM, I helped build them.
Every competitive bake-off I sat through ran the same way. PowerPoint, then Grafana, then network donut charts, then terminal, then back to the PowerPoint.
In the cloud era, you could get away with this. Cloud networks were built around independent microservices. If one service slowed down, the rest kept running. Because the blast radius of a failure was small, your monitoring tools could be a fragmented mess. The architecture was forgiving.
AI is different. It is profoundly unforgiving. Whether it’s a distributed training run or a multi-node inference pipeline, these are tightly coupled workloads where every GPU in the cluster is synchronized. If you have one congested link, one bad cable, or a firmware mismatch on a single network card, the entire multi-million-dollar cluster slows down to the speed of that one broken component. The fragmented operational posture that was good enough for the cloud is completely inadequate here.
That’s what brought me to Aria. Not because Aria had a better version of what already existed. What convinced me was that the founding team here understood that the next networking company had to be built from the ground up to handle a workload that didn’t exist five years ago.
And then actually built it. In fifteen months.
In fifteen months, this team shipped purpose-built switching hardware, a telemetry architecture embedded directly in the ASIC, and an agent-first software stack. Not a chat window bolted onto a dashboard. A system designed to reason across your entire infrastructure.
During our launch event, we showed what that looks like in practice. Normally, investigating a congested network requires typing commands into a terminal and cross-referencing half a dozen tools. With Aria, you just ask a question: “Why is my training job slow?” The system looks at your network, your MLOps tools, and the data on your GPUs to give you the answer.
We showed how Aria can spot a 200-microsecond buffer exhaustion that other platforms can’t even see. When dealing with hardware, we showed how we can run workflows like a signal integrity test on a bad transceiver and tell you exactly which end of the link is broken, and whether you need to replace the optic or the cable.
In one instance, the system noticed GPU temperatures dropping. The GPUs weren’t healthy. They were idle and starved for data due to a congested network link. The evidence was on the GPU, but the root cause was the network.
And the operator didn’t have to switch contexts even once to figure it out.
None of those investigations required a single CLI command, a custom script, or a context switch between tools. One interface. One question.
Fifteen months of building in silence, one week of showing it to everyone. Those who know me know I’m far from the jumping up and down with excitement persona. I am more of the quiet “do the work” and prefer the building, but I’ll admit that showing Aria for the first time was exhilarating.
To the customers and partners already running and engaged with us, we built this for you. I’m looking forward to seeing how it makes a difference in your environments, and I want to hear what’s working and what isn’t. Your deployments are where this product gets real.
In the next post, I want to dig into the harder questions behind the product. How does a product team decide what to build when AI models improve every quarter? What compounds over time, and what gets absorbed by the next foundation model?
This is the first in a series of posts about building products for the AI infrastructure era.
