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.