← Back to the book
Free sample

Finding Traction in Partnerships

The operating system for partnerships that compound · Bart Dirksen

Introduction

Introduction. The Operating System Problem

I sat in a Quarterly Business Review (QBR) with a partner. They had just pointed out, patiently, for the third quarter in a row that the partnership number wasn't moving. The room had a head of partnerships, a partner lead, a marketing liaison, and sales. Everyone agreed partnerships mattered. Everyone agreed the numbers weren't where they needed to be. Everyone had an explanation.

The explanations were all reasonable. Sales comp didn't reward co-sell. Product wasn't prioritizing the integrations partners asked for. Finance wouldn't credit influenced revenue. The team was stretched. The Partner Relationship Management system (PRM) was painful.

None of them was wrong. And none of them was the actual problem.

The actual problem was that this company had hired a partnership function to execute a strategy the rest of the company wasn't wired to support. The team wasn't failing. The system was missing.

That is the pattern this book is about.

The diagnosis that's usually wrong

I have been inside enough of these conversations to know where they go next. Within a quarter or two, one of three responses gets chosen.

The first response is to change the leader. The board loses patience, the head of partnerships leaves, a new one is brought in with a fresh plan and six months of honeymoon. The new leader runs the same experiment into the same structural walls.

Somewhere between month nine and month fifteen, they discover that the problem isn't a leadership problem. By then the original thesis, that partnerships would materially extend the company's commercial reach, has lost credibility. The function gets rebuilt smaller.

The second response is to sign more partners. If current partners aren't producing, the logic goes, the network isn't big enough. The partner count doubles. The number of partners that are productive doesn't. A year later, the team is managing three hundred logos where they used to manage one hundred fifty, the portal looks impressive, and sourced revenue is flat.

The third response is to buy a tool. Usually a new Partner Relationship Management system. Sometimes an ecosystem intelligence platform. The assumption is that the operational friction is the problem, and automation will clear it. The PRM goes in. But partners still don't register deals. Account Executives (AE) still route around them. The team has a newer interface and the same ceiling.

None of these responses is stupid. Each one treats a real symptom. They are wrong for the same reason. They address the function, not the system around it. A partnership function cannot produce outcomes the operating system around it doesn't support. You can swap leaders, grow the partner base, or rebuild the tooling all you want. The ceiling stays.

What I mean by system

When I say partnerships is an operating system rather than a channel, I mean something specific, and it applies whether you are combining a partner motion with direct selling or building a model where the ecosystem carries the primary GTM weight. A channel is a pipe that a company attaches to the side of its existing commercial motion. Put partners in, get deals out. An operating system is the set of structures, decisions, and commitments that shape how the whole company behaves when partners are involved. Naming it a channel lets you treat partnerships as an add-on while recognizing it as an operating-system framing does not. It forces the questions most companies avoid. How sales comp changes. How product roadmap prioritization changes. How customer success capacity planning changes. How finance forecasts partner-influenced revenue in the model.

The distinction matters because it determines where you look for the problem when the number misses. In channel thinking, a miss is a partner problem. In system thinking, a miss is usually a problem somewhere else. A process the ecosystem depends on that never got built. A decision upstream that quietly capped the ceiling. A comp plan that pays the AE the same whether the partner was involved or not. The book is written from the second view.

What the operating model actually is

The operating model has seven layers.

The first is strategy. Which ecosystem the company is building, and what role partners play in the commercial motion.

The second is program. Tiers, benefits, policies, rules of engagement. What partners can predict.

The third is go-to-market. How deals actually close through partners.

The fourth is economics. The P&L of partnerships, the incentive design, the math that decides whether the investment is defensible.

The fifth is operations. The data spine, the PRM, the governance that keeps the system honest.

The sixth is leadership. Executive ownership across Chief Revenue Officer (CRO), Chief Product Officer (CPO), Customer Success (CS), and Chief Executive Officer (CEO), without which the function has a ceiling it cannot overcome.

The seventh is change. The permanent work of rewiring the company to support the model. Not a launch phase. A standing layer.

That reads like the setup for a consultant deck, and it isn't. It's a physics claim. Each layer depends on the others. A tight program without sales comp alignment produces partner frustration. A clean attribution model without executive ownership produces finance distrust. A sharp strategy with weak operations produces motion without outcome.

You can have an A-team in six of seven layers and the system will still cap out. Headcount won't compensate. Marketing won't compensate. Partner recruitment certainly won't. What compensates is fixing the missing layer, which is almost always the one no one formally owns. Change. Leadership. Or the economics no one has done the math on.

You can't work around a missing layer for long.

What this book will do, and what it won't

This book is a working map of the operating model. It walks through each layer, explains how the interlocks work, names the common failure modes, and gives the reader the decisions to make. Not things to believe about partnerships.

It assumes you know the basics. If you are reading this, you have probably signed a partner agreement, sat in a QBR, argued about attribution, or watched a co-sell deal stall in the handoff. The book is not going to define what a Value Added Reseller (VAR) is or explain why ecosystems matter in the abstract. The reader this is for is three or four iterations past those conversations and trying to figure out why the next level of outcome isn't showing up.

This book won't tell you how to be a good partner manager. That is a different book, for a different reader. It will not rank PRM vendors or walk through hyperscaler incentive mechanics in exhaustive detail. It will reference hyperscalers where they matter.

It also does not pretend that the operating model is finished and won't evolve or change. Some of what is here will shift in the next three years, particularly at the intersection of AI and ecosystem operations. The book will name where the claims are still forming. The other option is to pretend it's all figured out, which we all know isn't true.

Who this book is for

If you are a CRO who owns the number. The CEO who signed off on the investment. The VP of Partnerships trying to turn commitments into compound results. Occasionally the CPO, Chief Marketing Officer (CMO), or Chief Financial Officer (CFO) whose function touches the partnership model in a structural way. This book is for you.

If you are a partner manager, you will still find useful material here. But the book is not aimed at your daily craft but will provide you with context of what shapes a successful partner organization. The arguments are framed for the people who make decisions about investment, org design, compensation, and cross-functional priority. Those are the decisions that determine whether partnerships compounds.

Stage matters too. The book is most useful for Business to Business Software as a Service (B2B SaaS) companies with serious enterprise or mid-market motion. At startups, the operating-model conversation is usually premature. The function is too small for the interlocks to matter yet. Above $1B, the specifics matter in ways that require specialization the book does not try to replace. In the middle band, the operating model is the difference between a partnership function that contributes meaningfully to the number and one that produces activity without compounding. Something I've seen many companies struggle with throughout my career.

How to read this book

The book moves through the operating model in a logical order:

Part I argues the case and lays the map. Two chapters. If you are already convinced partnerships matters, skim Chapter 1 and focus on Chapter 2, the thesis chapter. Every following chapter returns to the map of Chapter 2.

Part II is the strategic layer. What ecosystem you're building and what program you're putting around it. These are the chapters for the leader deciding where to invest and what to offer partners.

Part III is the revenue layer. It is the book's longest part for a reason. Recruitment, co-sell, economics, enablement, and Net Revenue Retention (NRR). This is where the operating model either produces money or it doesn't. If you are a CRO, this is the section you will reread.

Part IV is the operating layer. Operations, data, and the cadence that keeps the system governable. These chapters are craft. They are what separates programs that compound from programs that don't.

Part V is the leadership layer. Org design, executive ownership, change management, and where the function is heading. The leadership work. The rewiring of the company that no partnership function can do from inside its own boundaries.

These five parts describe the reading sequence. The seven layers introduced from Chapter 2 onward are the operating system itself. The parts tell you how to move through the book. The layers tell you what the book is about.

The closing chapter is a diagnostic. Seven questions, one per layer, designed to be answered in fifteen minutes. Your answers will tell you where the system is strongest, where it is weakest, and what to do on Monday.

Read it in order if you want. Or start with the gap that's costing you most. Each chapter works alone.

One last thing

There is a version of this book that would be longer, more balanced, and more careful. It would name every alternative position, describe every exception, and arrive at the end without a clear view.

This book has a position. Partnerships is an operating system. It compounds when every layer is designed and led as one. It does not compound in any other mode. I have watched the alternative often enough to say that with confidence.

Let's get into it.

Chapter One

Chapter 1. The Deal Before the Deal

Before your AE opens the first call, someone has already been talking to the buyer. A consultant who implemented your product at their last company. A systems integrator managing their infrastructure, carrying opinions about vendors in your category formed from deals they've been involved in over the past three years. A developer who ran a trial six months ago and sent a Slack message to their team about it. The shortlist was not built by your marketing campaign. It was built by conversations you weren't part of.

Most commercial systems are still designed for a world where this wasn't true. In that world, the vendor controlled the narrative at the point of contact. Outbound delivered a fresh introduction. Discovery was discovery. Product demonstrations moved buyers from unaware to convinced.

That world does not exist anymore in most enterprise software markets. By the time the buyer opens the first vendor call, the shortlist has already narrowed. Categories have been dismissed. Competitors have been promoted or demoted based on conversations the vendor was never part of. The decisions that used to happen in the middle of the sales cycle now happen before it starts.

This is not an outbound-quality problem. Tighter Ideal Customer Profile (ICP) targeting will not fix it. Better sequences will not fix it. Sharper discovery will not fix it. The problem is structural. Credibility has already been distributed across the buyer's network in ways the vendor's team has never touched, by people the vendor's team may not know exist.

That is where partner strategy has to start. Not with program tiers. Not with margin structures. Not with the PRM rollout. With an honest accounting of who already holds trust with the customers you're trying to reach, and what it would take for them to carry your product into those relationships.

Who shapes the deal before you arrive

A mid-market SaaS company, enterprise product, average Annual Contract Value (ACV) around $120K. The rep opens a discovery call with a new prospect. The prospect is polite, informed, and thirty minutes into the call mentions by name the two competitors the vendor is most often compared with. One is dismissed casually. "We talked to them. They don't scale." The other is described in neutral terms. The rep's own product, the prospect says, "came up a lot from people we trust."

The rep files a clean call note. Competitive bake-off with one competitor. Positive early signal. Next step, technical demo.

What the rep did not learn, and had no way to learn, was that three months earlier the prospect's VP of Engineering had asked a systems integrator for their take on the category. The System Integrator (SI) had deployed the vendor's product twice. Both deployments went well. They had deployed the dismissed competitor once. That deployment did not go well. The SI, without ever pitching anything, had moved the category ranking in the prospect's head before anyone at the vendor heard their name.

That is the deal before the deal. The vendor's sales motion was not selling from zero. It was selling from a position that had already been assigned to it by a conversation between two people the vendor's team was not in. If the SI had deployed the competitor's product twice instead, the ranking would have reversed, and the call the rep walked into would have been a different call.

You can put that conversation on a slide and call it influenced pipeline. That framing understates what is actually happening. The SI did not influence a deal that was otherwise going to move. The SI determined which vendors would be seriously considered. The vendor team, working outbound, was reacting to a decision that had already been half-made.

The trust layer you don't control

Three kinds of people inside a buyer's environment hold credibility the vendor cannot replicate with a sequence or a campaign.

The first is the implementation partner. The SI, the boutique services firm, the agency, the occasional internal consultancy. They carry a track record. When they say a product works in production, the buyer weights that statement heavily, because the person making it has lived through the consequences of deployment. They will also tell the buyer which products generate support tickets and which ones behave. A warm endorsement from a partner of this kind, offered inside a working context rather than a sales context, is worth more in the late stages of an enterprise evaluation than any qualification call.

The second is the technology partner. The Independent Software Vendor (ISV) whose product sits beside yours in the customer's stack. Their endorsement is narrower and more technical. They will say which products they integrate with cleanly, which APIs they trust, which teams respond when something breaks. Buyers running a competitive evaluation ask this question directly, because an integration that works on paper and fails in production is a known source of operational pain.

The third is the peer operator. A technical leader or buyer at a comparable company who has lived with your product long enough to have a credible view. These connections run through communities, conferences, former-colleague networks, Slack groups, LinkedIn threads the vendor does not see. Peer references produced by the vendor's team, the curated customer quotes in the case study, carry a small fraction of the weight of a peer reference produced by the buyer's own network.

The buyer does not formally list these sources in any evaluation matrix. They absorb the inputs. By the time the formal evaluation starts, the inputs have already shaped which vendors are on the list and which are near the top. That is the trust layer. The vendor does not control it, cannot buy it, and cannot short-cut it with messaging. The only way to influence it is to invest in the partners who live inside it.

Keep reading

The rest of Chapter 1 lays out the four sources of ecosystem value and the business case that actually wins the CFO meeting. Twelve more chapters build the full operating model from there.

© 2026 Bart Dirksen · PartnerImpact · Sample excerpt.