Building a Revenue Operating System Leadership Actually Trusts
A conversation with Aidan Nevin, VP of GTM Opas & Business Intelligence
Executive Summary
Most revenue teams don’t fail because of missing tools. They fail because leadership doesn’t trust the system.
At Fidelity Labs, Aidan Nevin built a revenue operating system from scratch that leadership relies on daily. Not by adding more dashboards, but by designing the system around data integrity, centralized ownership, and repeatability at scale.
Instead of cleaning data downstream, his team controls it at ingestion. Instead of fragmented ownership, they operate with a unified tech stack. Instead of reactive reporting, they built a structured system where every metric is defined, documented, and trusted.
Readers will learn:
- Start with structure, not tools: CRM is treated as both interface and warehouse, with strict validation at entry
- Centralize the core, flex the surface: Data models stay consistent while reporting adapts to each business
- Control data at ingestion: An “air traffic controller” system ensures clean data before it enters CRM
- Documentation builds trust: Data dictionaries, definitions, and workflows eliminate ambiguity
- Avoid one-off solutions: Optimize for repeatability across the portfolio, not individual team requests
- AI as a deflection layer: Enable self-serve insights to reduce RevOps support load
- RevOps as a strategic partner: Prioritization and discipline elevate the function beyond execution
From Sales to System Builder
Aidan’s path into RevOps didn’t start in operations. It started in sales.
He began in high-pressure sales environments, consistently ranking among top performers before moving into early-stage companies where roles were fluid and systems were non-existent.
That environment forced a shift. From Closing deals to understanding how systems enable deals.
At Fidelity Labs, he was given something most operators never get.
A blank slate! That constraint became the advantage.
Aidan Nevin
VP, GTM Ops & Business Intelligence
I joined and there was nothing here. No infrastructure, no systems. We were building from zero.
Designing RevOps Inside an Incubator
Fidelity Labs operates differently from the broader enterprise.
Each venture inside the incubator:
- Has its own sales, marketing, and product teams
- Functions like an independent startup
- Shares a centralized RevOps backbone
At the center of it all sits Aidan’s RevOps team.
They are not tied to one business.
They support all of them.
This creates a unique operating model:
- Multiple business units
- One shared RevOps system
- Constant context switching
The challenge is not just scale. It’s designing a system that works across fundamentally different go-to-market motions.
| Traditional Enterprise | Fidelity Labs Model |
| Siloed ownership | Single ownership of tech stack |
| Reactive processes | Designed systems |
| Tool-first | Architecture-first |
| Data cleanup later | Data integrity at ingestion |
| Reporting conflicts | Unified definitions |
The Core Principle: Centralize What Matters, Flex What Doesn’t
What Gets Centralized
- Core revenue architecture
- Lead to revenue flow
- Opportunity structures
- Field-level definitions
- Data schema
- Same field names across all businesses
- Same definitions and logic
- No room for interpretation
- Enrichment systems
- Data enriched once and reused
- Eliminates duplication and cost inefficiency
What Stays Flexible
- Business dashboards
- Tailored to how each team operates
- Reflects their KPIs and language
- Reporting views
- Custom at the surface
- Standardized underneath
Underneath it all has to be the same, but the way it’s presented should reflect the business.
Aidan Nevin
VP, GTM Ops & Business Intelligence
CRM as the System’s Backbone
Most teams treat CRM as a system of record.
Aidan treats it as both:
- A system of interaction
- A structured data warehouse
| Typical CRM Usage | Aidan’s Model |
| Input layer | Structured data system |
| Flexible entry | Restrictive by design |
| Clean later | Clean at entry |
| Reporting struggles | Reporting ready |
Start as restrictive as you possibly think we should get, and then open it up from there.
Aidan Nevin
VP, GTM Ops & Business Intelligence
Why This Matters
If data is clean at the CRM level:
- Warehousing becomes simpler
- Reporting becomes reliable
- BI becomes trustworthy
If it’s not:
- Every downstream system compensates
- Complexity multiplies
The Air Traffic Controller for Data
One of the most practical aspects of Aidan’s system is how it handles incoming data.
Instead of allowing raw data into CRM and fixing it later, they built a system that controls and processes it before it lands.
What Happens Before Data Enters CRM
Every record goes through:
- Attribution logic
- Metadata enrichment
- Scoring models
- Validation checks
Only after passing these steps does it become part of the system.
See how leading GTM teams build complete buying groups without relying on manual CRM updates with Nektar
Data Trust Is Built Through Documentation, Not Dashboards
Clean data is necessary. It’s not sufficient. Trust comes from clarity.
What They Built
- Data dictionaries
- Field definitions
- Data maps
- Validation logic documentation
When stakeholders question a metric, the response is not interpretive. It’s definitive.
I can tell you how it’s defined, how it’s structured, and where it comes from.
Aidan Nevin
VP, GTM Ops & Business Intelligence
The Hard Part: Internal Education
RevOps transformations are not just technical. They are organizational. When Aidan joined, RevOps meant different things to different people across Fidelity.
The first step was alignment.
At Fidelity, that meant:
- Explaining what RevOps actually does
- Aligning with legacy enterprise teams
- Running internal roadshows for months
The first task I was given was to explain to people what I do.
Aidan Nevin
VP, GTM Ops & Business Intelligence
AI’s Role: Reducing Dependency on RevOps
The biggest opportunity Aidan sees in AI is not automation for reps.
It’s reducing dependency on RevOps teams.
The Problem Today
- Constant Slack and Teams messages
- Reporting requests
- Basic system questions
The Opportunity
Enable users to:
- Ask questions directly to the system
- Access insights without intermediaries
How can we let users ask the system, not us?
Aidan Nevin
VP, GTM Ops & Business Intelligence
Building for Repeatability at Scale
The ultimate goal of the system is not just efficiency.
It’s scalability.
Without Structure
Each new business:
- Starts from scratch
- Rebuilds systems
- Repeats mistakes
With Structure
Each new business:
- Inherits infrastructure
- Uses proven workflows
- Launches faster
The next company doesn’t start at day zero. It starts at day 365.”
Aidan Nevin
VP, GTM Ops & Business Intelligence
The Takeaways
Aidan’s approach reframes what RevOps should be.
Not a support function.
Not a reporting layer.
But a system design discipline.
The Model
- Clean data at the source
- Structured systems underneath
- Consistent definitions across teams
- Flexible reporting on top
The Result
A system where:
- Leadership trusts the data
- Teams align on metrics
- Decisions move faster
You don’t fix trust at the dashboard level.
You build it at the system level.
Scroll below for more related resources.
Subscribe to The Revenue Lounge Brief for quick insights on every new episode.
If you liked what you read, please share it with your peeps.
In this blog
Get the Revenue Lounge Brief
3 takeaways from every new episode, straight to your inbox.
