Podcast
October 23, 2026
Episode 113: RevOps Is Your New Go-to-Market Product Team
Dan Jiao of Aircall makes the case for RevOps as a product org — and explains exactly what skills, structures, and bets will set operators apart.
Revenue operations has spent the better part of a decade proving it belongs at the table. The question now is what it does once it gets there. The old model — fielding requests, building reports, closing tickets, waiting for the next ask — has a ceiling, and most RevOps leaders have already hit it. The more interesting question is what comes next.
Dan Jiao, VP of Revenue Operations at Aircall, has a clear answer: RevOps becomes a product team. Not metaphorically, and not just because AI makes it possible — but because the business needs it, and the function has evolved enough to deliver it. Matthew Volm sits down with Dan to unpack what that shift actually looks like, where go-to-market (GTM) engineering fits into it, and what skills will separate the RevOps professionals who thrive over the next three to five years from those who get left behind.
Dan's path to this perspective is worth understanding. He started as a chemical engineer, pivoted into mid-market sales, rose through enterprise and sales director roles at Ekata (acquired by Mastercard), and eventually opened a commercial office in Singapore during the pandemic. It was there that something clicked: you could hire the best sales reps in the world, but their ceiling was always the operating system they ran in. That realization drove him into operations — first as chief of staff to Ekata's global head of sales and partnerships, then as Senior Director of Sales Operations at Signifyd, where he built RevOps from the ground up, and later at Wiz, the fastest-growing cloud and AI security business, where he got a front-row seat to what it takes to scale past a billion dollars in ARR. That career arc — from engineer to salesperson to operations leader — shapes everything about how he thinks about the function.
The service-oriented model of RevOps has a specific failure mode, and Dan names it directly.
"The old RevOps model was more ticket-driven, which is like a bit of how a service desk team typically operates. Someone would ask for a report or a dashboard to track pipeline or bookings, and the RevOps team goes and builds it, and then closes the ticket, and then waits for the next request. You're measured essentially there in that model on your throughput and SLAs on that throughput." — Dan Jiao
The problem isn't just that this model is reactive — it's that it caps value at the speed of firefighting. You become as useful as you are fast, which is not the same thing as being strategically valuable.
The product model inverts this logic. Instead of asking "what did someone request?", the question becomes "what does the go-to-market team need in order to effectively sell and service their customers — and what should I build so they don't have to ask for it?" As Dan describes it, this looks like owning a roadmap, maintaining a prioritized backlog, and shipping things with clear ownership, adoption metrics, and a defined lifecycle. It's the difference between being measured on throughput and being measured on revenue impact.
This shift hasn't been purely AI-driven, though AI has accelerated it. RevOps has been one of the fastest-growing functions in SaaS for the better part of a decade, and CROs have gradually recognized that the function's value isn't in report-building and data cleaning — it's in shipping things that accelerate how sellers, marketers, CS teams, and partnership managers work. AI compressed the time it takes to fulfill service-desk-style requests, freeing up capacity that can now go toward more strategic product work. The bandwidth exists. The question is what RevOps does with it.
Dan's framing of where this leads is worth sitting with: the RevOps teams that control a signal-based command center — and the workflows tied to it — are the ones that own the most valuable product in the GTM stack. Think of it as a custom-built version of Gong, Clari, and Outreach tailored specifically to your business, built and maintained by your own team. That's not a dashboard. That's a product.
One clarification that gets lost in the product-model framing: the product isn't always technology. It doesn't have to be a SaaS interface, internally built or purchased.
Dan's example here is the operating rhythm itself — the weekly cadence of staff meetings, PMO reviews, strategy sessions, business reviews, forecasts, and QBRs. When stitched together correctly, that cadence is a product. It requires inputs, pre-work, decision outputs, and cross-functional unity between marketing, sales, CS, and finance. It's something you're always shipping and iterating on. Getting that alignment right is what drives the decisions that improve the revenue engine.
This matters because it keeps the product-model framing honest. The shift from service to product isn't about building more technology — it's about taking ownership of outcomes. Whether the thing you're shipping is a signal-based command center or a well-designed QBR cadence, the underlying logic is the same: you're anticipating what the business needs, building it before anyone has to ask, and taking accountability for whether it works.
For RevOps practitioners thinking about how to evolve the function strategically, this distinction is the prerequisite for everything else. Product thinking doesn't require writing code. It requires owning a roadmap.
The conversation about RevOps-as-product team runs directly into a related question: where does GTM engineering fit?
Dan defines it precisely. GTM engineering is the discipline of building and automating revenue workflows — how you market, prospect, convert pipeline to bookings, and expand. The GTM engineer connects the technical infrastructure (APIs, data pipelines, MCP servers, AI-related tooling) to the workflows that RevOps has defined. What distinguishes it from traditional RevOps isn't the goal — it's the scope and speed.
"RevOps traditionally is the team that configures, but GTM engineering does everything from configuration — which is like CRM setup, admin work — to actually taking that all the way end to end in the lifecycle. Being able to draft the process documents, the playbooks, understanding how to bring the data engineering team to build a new pipeline for you, and then GTM engineering builds and stitches that all together from like the data warehouse, translates that into the signals, that then gets into the workflows of our sellers and customer success managers." — Dan Jiao
The structural question of where GTM engineering sits varies by organization. In some companies it rolls up directly into RevOps, particularly when RevOps is already running like a product org. In others, it reports directly to the CRO if it's viewed as sufficiently strategic. What matters more than the org chart is the function it serves: closing the gap between "we need X" and "X is live" — which Dan suggests has shrunk by roughly an order of magnitude with AI plus GTM engineering in the picture. What used to take a quarter now often takes a two-week sprint.
The through-line connecting GTM engineering to the product-model framing is the same signal-based orchestration logic. The GTM engineer isn't just configuring tools — they're translating data infrastructure into actionable workflow signals for frontline sellers and CS managers. That's connective tissue, not a separate discipline. And as RevOps teams increasingly look like product orgs, GTM engineering becomes the R&D arm that makes the product possible. This conversation builds naturally on what Episode 56: GTM Engineering — The R&D Arm of RevOps explored in depth.
Matthew raises a concern worth taking seriously: is GTM engineering just a new version of the Salesforce admin trap? The admin role was built on specialized knowledge — knowing how to configure the platform was the moat. AI is commoditizing exactly that kind of knowledge. Anyone can learn to build a flow or write validation rules quickly; increasingly, AI agents will do some of that work automatically. What's the skill that doesn't get displaced?
Dan's answer cuts to the core of what human workers bring in an AI-augmented environment.
"Really, the value we all bring as human workers is discernment — our ability to critically think and make judgment calls based off of the knowledge and the data and the processes presented before us." — Dan Jiao
This is the framing worth internalizing. The Salesforce admin differentiated through knowledge. AI flipped the script by making knowledge a commoditized asset. The question is no longer "can you build it?" It's "how should we build this, and why does it matter?" — and that's where human judgment remains irreplaceable.
Dan extends this to a related challenge for early-career professionals: if AI can do the entry-level analytical and research work that used to teach people how businesses actually function, how do you develop the business acumen that makes judgment possible? It's a genuine open question. His instinct — shaped by his own background — is that time spent in the field, carrying a bag or close to it, builds the kind of practical judgment that can't be shortcut. Understanding the human element of purchasing and the customer lifecycle is what allows the architect behind the scenes to build workflows that actually get used.
The lesson for practitioners: specializing in a particular tool or platform has always been risky. What holds across every wave of technological change is the ability to think critically about what the business needs, communicate that clearly across functions, and make sound judgment calls when the data and the technology present options. That's not an AI admin. That's a strategic operator. The RevOps Archetype Matrix covered in Episode 66 offers a useful frame for understanding which of these operator profiles you most naturally fit — and where to develop.
Matthew frames this explicitly as a two-persona question: what should an early-career RevOps professional prioritize, and what should a VP-level leader be doing to stay sharp? Dan has specific recommendations for both.
For earlier-career operators, the foundation is first-principles thinking — understanding how things actually flow in a business, without assuming that the process in the system is the right one. Couple that with product management instincts: knowing how to prioritize, where and why to say no, and what "done" and "adopted" actually mean. These aren't technical skills. They're ways of thinking that determine whether the things you build matter.
Beyond that, Dan singles out two attributes that are harder to teach but critical to develop: curiosity and storytelling.
"I think if you really learn how to sell and tell great narratives, that is a really important skill set that we should democratize through all RevOps and Go-to-Market engineering talent at the entry level. Because if you're a really good storyteller, I think that is something that AI won't be able to displace. It's gonna be able to displace the research. It'll be able to displace the technical code writing, the analysis, but it won't be able to tell the story in a way that resonates with another human." — Dan Jiao
Curiosity, in Dan's framing, is the precursor to cross-functional influence — the ability to build bridges between revenue, finance, and product teams by genuinely understanding what each function cares about and where their pain intersects. Matthew adds a practical corollary: curiosity isn't just a personality trait — it's a discipline. Even doing something as routine as adding a picklist value to a closed-lost field should prompt the question of why: who clicks this, when, and what decision does it inform? Asking those questions consistently is how you build the business context that AI can't give you. This aligns well with the frameworks in Episode 102: The RevOps Skills Nobody Teaches.
For VP-level leaders, Dan's advice shifts direction: get closer to the technology, not further from it.
"You should know what is the art of the possible. Because I think more and more of what you're gonna run in a RevOps team is more Go-to-Market engineers, AI operations professionals. And if you can't understand the language they speak with data models, APIs, MCP servers, you're gonna fall too far behind, and I think you're not gonna be able to build the roadmap and tell the stories you want to the board of directors and to the C-suite." — Dan Jiao
This doesn't mean becoming technically fluent in infrastructure, security models, or application code. It means knowing enough to evaluate what's possible, identify where the real constraints are, and avoid building roadmaps based on a playbook that was current five years ago. Dan's other recommendation for senior leaders: stay current on unit economics and the metrics that boards and CFOs actually care about — CAC payback, LTV ratios, ARR and net revenue retention (NRR) — because those evolve too, especially as AI changes what SaaS businesses look like and how they're valued.
The meta-skill at the VP level is captured in a phrase Dan borrows from a mentor: "You inspect what you expect, and you gotta be in the business, not on the business." Not micromanaging — but not so removed from the work that you lose the ability to call things accurately.
The forward-looking question Matthew poses — what can RevOps operators do right now that will differentiate them over the next three to five years? — gets a concrete answer from Dan.
Start vibe coding. Experiment with building things using Claude Code or OpenAI's Codex. Begin from the frame of signals-based orchestration: put yourself in the seat of an account executive (AE) or AE manager, map out the workflows they need to run each day, and identify what a single pane of glass with the right data connectors would actually look like for them.
"I would recommend every person right now to start experimenting — what's the art of the possible there, building out their own version of that, working with infrastructure teams, which will probably be the first time most RevOps people work with like infra teams and CISOs to figure out how do you host this, how do you deploy it, how do you maintain it, how do you secure it." — Dan Jiao
The recommendation lands for two reasons. First, the demand side: CROs and CFOs will increasingly want to hire RevOps operators who can build signal-based command centers that drive sales velocity and productivity gains — and who can reduce dependence on a sprawling stack of point solutions for forecasting, prospecting, intent data, and workflow execution. Second, the supply side: most RevOps professionals haven't yet worked with infrastructure teams or CISOs on deployment and security questions. Those who start now build a capability that remains rare.
Matthew's illustration of this principle is instructive. At RevOps Co-op, the event operations workflow had accumulated 13 different tools to manage what was fundamentally a consistent execution path — webinars, small-group dinners, conferences. Rather than continuing to patch together point solutions, he started building a product to solve the problem internally. That's turned into Eventful, now in the process of being brought to market. The point isn't that everyone should launch a product company — it's that the instinct to solve your own operational problems by building something, rather than waiting for a vendor to solve it for you, is exactly the muscle worth developing. And it doesn't have to start at work. Matthew's other example — building a team website for his kids' baseball team in 30 minutes using Claude, complete with calendar invitations to all parents and a styled landing page — illustrates how low the barrier to experimentation actually is.
The internal version of this for most RevOps teams, as Dan notes, is something almost every practitioner has wanted: a co-pilot or Slack bot that deflects routine questions about rules of engagement, attribution, comp, or sales process — so the team isn't fielding the same queries on repeat. That's a buildable thing, today, with the tools that exist right now. The gap between wanting it and having it has collapsed. The operators who close that gap first are the ones who will be hardest to replace. Building toward AI readiness in your revenue systems starts exactly here — with small, internal experiments that compound.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
