People, process, data, technology: why the order is the whole point
Everyone agrees these four things matter. Almost nobody gets the sequence right. The sequence is where the value lives.
If you’ve spent any time in revenue operations, GTM, or partner ecosystems, you’ve heard some version of this framework before. People, process, technology. Sometimes data gets its own seat. Sometimes it’s folded into technology. Sometimes the order shifts depending on who’s presenting and what they’re selling.
I use a specific version: People, Process, Data, Technology. In that order. Not because it sounds good on a slide, but because every operational failure I’ve ever diagnosed traces back to getting the sequence wrong.
This isn’t a framework for decoration. It’s a diagnostic tool, and it’s the operating lens behind everything I write here. So let me break down what each layer actually means in practice, why most organisations get the order backwards, and what happens when they do.
People
People isn’t about headcount. It’s about alignment.
The question isn’t “do we have enough people” - it’s “are the people we have working toward the same outcomes with the same definitions and the same accountability?”
In most B2B organisations, the answer is no. And it’s not because the individuals are bad at their jobs. It’s because the organisational structure creates competing incentives.
The partnerships team is measured on partner recruitment and certification numbers. The direct sales team is measured on closed-won revenue. Marketing is measured on MQLs. Customer success is measured on retention. Each team optimises for its own number. Nobody is accountable for the connected outcome.
This is where the problems start. A partner registers a deal, but the direct rep is already working the account and doesn’t want to share credit. Marketing runs a campaign that overlaps with a partner’s co-marketing activity, and nobody can tell which touch mattered. The CRO asks for a unified pipeline view and gets three different spreadsheets from three different teams.
The people problem isn’t about skills or capacity. It’s about whether your teams share a common understanding of what they’re building, how success is measured, and who owns what. Until you solve this, every tool you buy and every process you design will be undermined by humans optimising for different goals.
What “fixed” looks like: shared revenue metrics across direct and partner-sourced pipeline. Clear ownership maps for accounts and deals that both direct and indirect teams respect. Compensation structures that don’t punish collaboration. Regular cross-functional operating rhythms where partnerships, sales, marketing, and CS are in the same room looking at the same numbers.
None of this requires a platform. It requires decisions.
Process
Process is where most organisations think they’re strong and where most are actually weakest.
The problem isn’t that processes don’t exist. It’s that they exist in fragments. There’s a process for deal registration and a different process for direct pipeline management. There’s a marketing campaign workflow and a separate partner co-marketing workflow. There’s an onboarding process for new customers and a completely different one for partner-referred customers.
Each process works in isolation. None of them connect.
The result is handoff failures. A partner-sourced lead enters the funnel through deal registration but doesn’t appear in the same pipeline view as direct opportunities. An account is flagged for renewal by CS, but nobody tells the partner who originally brought the deal in. A marketing campaign targets accounts that a partner is already working, and neither side knows until the customer gets two conflicting messages in the same week.
Connected process means that partner-sourced and direct opportunities follow the same qualification criteria, move through the same pipeline stages, and are reported on through the same mechanism. It means that when a deal is registered, the response time is defined and enforced - not dependent on which region the partner sits in or how busy the channel manager is that week. It means conflict resolution has documented rules, not informal negotiations.
Here’s the diagnostic question: can you draw, right now, the end-to-end process from the moment a partner identifies an opportunity to the moment that deal is closed, invoiced, and attributed? Can you draw it without gaps or “it depends” steps?
Most teams can’t. They have pieces. They have workflows inside individual tools. They don’t have a connected process that survives contact with reality across functions and geographies.
What “fixed” looks like: a single pipeline management process that applies to all revenue sources. Defined SLAs for deal registration response. Documented handoff protocols between functions. Conflict resolution rules that exist on paper, not just in the channel manager’s head. Process maps that are maintained, not created once for an offsite and then forgotten.
Data
Data is the layer that determines whether everything above it is real or fiction.
You can have perfectly aligned people and well-designed processes, and if the data underneath doesn’t reflect reality, your reporting is a lie, your attribution is a guess, and your decisions are based on noise.
Most data problems in revenue operations aren’t about volume. Companies have plenty of data. The problem is structural. The data model - the way information is organised, stored, and related across systems - doesn’t match how the business actually works.
Common examples I see constantly:
Your CRM was configured for direct sales. Partner-sourced pipeline requires fields, objects, and relationships that don’t exist in the current data model. So partner data gets forced into fields that weren’t designed for it, or it lives in a separate system entirely with no reliable sync back to the CRM. Either way, the picture is incomplete.
Attribution has no single definition. Marketing counts touches one way. Partnerships counts them another way. Sales ignores both and credits whoever closed the deal. The same opportunity can be “partner-sourced” in the PRM, “marketing-influenced” in the MAP, and “direct” in the CRM. All three systems are technically correct by their own logic. The business has no truth.
Data hygiene is nobody’s job. Fields are populated inconsistently. Regions use different naming conventions. Duplicate records accumulate. The data degrades slowly enough that nobody notices until someone tries to build a report and realises the foundation is rotten.
The diagnostic question for data: if your CFO asked you right now to prove the ROI of your partner programme with a single, defensible number, could you do it? Not a rough estimate. Not a range. A number you’d stake your credibility on.
Almost nobody can. And the reason is almost always the data architecture, not the analysis.
What “fixed” looks like: a data model that explicitly supports partner-sourced, partner-influenced, and direct pipeline as first-class categories - not afterthoughts bolted onto a direct-sales schema. Shared definitions of key objects and fields across all systems. A reconciliation process that ensures PRM data and CRM data tell the same story. Ownership of data quality assigned to a specific function, not assumed to happen organically.
Technology
Technology comes last because it should. Not because it doesn’t matter - it absolutely does - but because technology purchased before the first three layers are solid will underdeliver every single time.
I’ve watched this pattern play out dozens of times. A company decides it needs a PRM platform. They evaluate vendors. They choose one. They implement it. Six months later, engagement is low, the data is messy, the processes are inconsistent, and the company blames the platform.
The platform isn’t the problem. The platform was asked to solve people problems, process problems, and data problems by being a better piece of software. Software doesn’t do that.
Technology amplifies whatever state your operation is in. If your people are aligned, your processes are connected, and your data is clean, a good platform will accelerate everything. It will automate handoffs, surface insights, reduce manual work, and scale what’s already working.
If your people are siloed, your processes are fragmented, and your data is unreliable, a good platform will automate the dysfunction. Faster. At scale. With better-looking dashboards that make the problems harder to see until something breaks badly enough that you can’t ignore it.
The diagnostic question for technology: for every tool in your revenue operations stack, can you articulate what process it supports, what data it depends on, and which teams are accountable for its outputs? If the answer for any tool is “it’s there because we bought it and now we use it,” that tool is probably not earning its cost.
What “fixed” looks like: a technology architecture where every platform has a defined role in the operational system. Integrations that are documented and maintained, not built once and forgotten. Tool selection based on process requirements, not vendor demos. Regular audits of whether the technology is delivering what it was purchased to deliver, with honest answers.
Why the order matters
Here’s the thing that makes this more than a list of four words on a slide.
If you start with technology - and most companies do - you’ve locked yourself into a structure before you’ve defined what the structure needs to support. The platform shapes the process instead of the other way around. The data model follows whatever the tool defaults to, not what the business needs. The people are forced to work around the system rather than through it.
If you start with people - alignment, shared goals, clear ownership - then the process design reflects how the business actually needs to operate. The data architecture is built to support that process. And the technology is selected to serve all three.
Same four components. Completely different outcomes depending on the sequence.
I’m not saying you need to spend a year on each layer before moving to the next. This isn’t waterfall planning. In practice, you’re often working on multiple layers at once. But you need to know which layer is driving the decisions. If a technology decision is driving your process design, you’re going backwards. If a data migration is happening before you’ve agreed on shared definitions, you’re building on sand.
The order isn’t about timeline. It’s about decision hierarchy. When there’s a conflict - when the tool can’t support the process you need, or the data model doesn’t fit the platform - which layer wins?
People, Process, Data, Technology. The first one in the sequence always wins.
The honest part
I’ll be straight with you. This framework doesn’t sell well. Nobody gets promoted for presenting “we need to align incentives and fix our data model” at the quarterly business review. Platforms get bought because they look like progress. They come with timelines and milestones and implementation partners who produce status reports.
Alignment work is invisible until it works. Process documentation is boring until the first time a deal conflict gets resolved in hours instead of weeks. Data architecture is thankless until the CFO asks for partner ROI and you can actually answer the question.
The companies that get this right aren’t the ones with the best tools. They’re the ones willing to do the slow work in the right order. Everything I write here is built on that conviction.
