What This Series Is
Most ISV alliance functions are quietly running the wrong playbook. The standard cloud GTM advice in circulation – the conference-stage talks, the vendor-published guides, the practitioner content from cloud-tooling vendors – implicitly assumes a particular kind of ISV: multi-tenant SaaS, hosted in the ISV’s own cloud account, with marketplace as both the discovery channel and the procurement channel. For the substantial population of ISVs whose software actually runs in customers’ cloud accounts – infrastructure, data platforms, security, observability, networking – that standard playbook actively misleads on the things that matter most. The result is alliance functions that produce administrative excellence (clean ACE submissions, current marketplace listings, well-attended joint webinars) and no field traction.
This is a comprehensive playbook on building and scaling a software vendor’s go-to-market motion with the three major hyperscalers – AWS, Microsoft Azure and Google Cloud. It covers the three load-bearing disciplines of the function: cloud alliances (the partnership-management discipline), hyperscaler co-sell (the day-to-day joint-selling motion) and cloud marketplace (the procurement and transaction channel that increasingly closes those deals). One cluster post – ISV-Hosted vs Customer-Deployed – develops the tenancy-archetype distinction at length; the rest of the series cross-references that post heavily because the implications cascade through every other decision.
A second structural argument runs through the series: cloud GTM is fundamentally different from traditional B2B software GTM, because the procurement channel sits inside the hyperscaler rather than in the ISV’s direct commercial relationship with the customer. The customer’s committed cloud spend, the hyperscaler’s incentive structures and the marketplace’s procurement-friction-reduction mechanics reshape which sales motions work, which programs matter and which functions inside the ISV need to be staffed. The standard B2B GTM playbook is recognisably the same but operates against a different set of structural constraints.
The series is deliberately vendor-neutral. It cites named research and practitioner models but doesn’t promote any specific tooling vendor or cloud platform. It’s also deliberately honest about where the mechanics are awful or contradictory – most public material on cloud GTM is produced by vendors with commercial reasons to be cheerful, and the resulting practitioner education is patchy.
A word on timing. Cloud GTM is a young discipline, and its youth is part of the story. Public cloud dates to 2006. Structured co-sell programs arrived more than a decade later. It is understood that Microsoft launched IP Co-sell publicly in 2017; AWS followed with ISV Accelerate in 2019; Google’s equivalent infrastructure developed later still. Most of the operational tooling, practitioner vocabulary and institutional knowledge that now exists has been built since 2019. This series exists partly because the written practitioner record hasn’t kept pace with how fast the discipline has moved. Much of what experienced cloud alliance leaders know is passed on verbally, in conference hallways and customer meetings, rather than documented anywhere a new hire or a curious CFO could read it. This playbook is an attempt to fix that.
A word on terminology. “Alliances”, “channel”, “partners” and “partnerships” mean different things at different companies. This series uses these terms in specific ways and it is worth being explicit about them before the series begins.
Alliances in this series means specifically hyperscaler GTM alliances – the commercial and co-sell relationship between an ISV and AWS, Microsoft and/or Google Cloud. It does not mean technical alliances (product integrations between two ISVs or between an ISV and a non-hyperscaler technology vendor), marketing partnerships (co-branded campaigns or joint events with third parties) or ecosystem partnerships of a general kind. At some companies “alliances” is used as an umbrella term that includes all of the above; in this series it is used narrowly to mean the hyperscaler GTM motion.
Channels means the network of resellers, system integrators, managed service providers and distributors who resell or deliver the ISV’s product to end customers – what many organisations call their “partner program” or “VAR network.” Channel partners are distinct from hyperscalers; they may co-exist with the hyperscaler motion (the multi-party private offer is the clearest example) but they are a different type of relationship with different mechanics.
Partners / Partnerships is deliberately avoided as a standalone term in this series because it is too broad to be useful. In some organisations “partners” means channel; in others it includes hyperscalers, technical allies and co-marketing collaborators. “Partnerships” as a function title covers an equally wide range. Wherever possible this series uses the more specific term (hyperscaler, channel partner, ISV, system integrator) rather than the catch-all, and uses “alliances” or “cloud alliances” for the hyperscaler GTM function specifically.
Technical Alliance refers to a partnership centred on product integration, API connectivity or joint technical development rather than on commercial co-sell or marketplace activity. Distinct from a cloud alliance in this series.
Who This Is For
Primary audience: ISV alliance, GTM, RevOps and finance leaders at infrastructure and platform vendors entering or scaling on AWS, Azure and Google Cloud. The series assumes the reader knows what an ISV is, has at least passing familiarity with the cloud-vendor landscape and is engaged with co-sell or marketplace as more than a future hypothetical.
Secondary audience: cloud-curious sellers, BDRs and partner managers new to the hyperscaler motion who want an end-to-end primer. The pillar posts are designed to stand alone for someone arriving cold.
The series is not for: hyperscaler-internal teams (the perspective is firmly partner-side); buyers of cloud software (different motion, different stakeholders); or readers looking for tooling-vendor product comparisons (the Cloud GTM Platform category is treated as a category throughout, with no endorsement of any specific vendor).
The Structure
Three pillars, each with cluster posts beneath. The full directory:
| Pillar | Cluster posts | Topic |
|---|---|---|
| Cloud Alliances | Cloud Partner Programs and Specialisations · Cloud Alliance Team · Cloud Provider Funding · ISV-Hosted vs Customer-Deployed | The partnership function: how to build, structure, fund and scale the cloud alliance team, plus the tenancy-archetype dynamic that reshapes every downstream decision. |
| Hyperscaler Co-Sell | AWS Co-Sell · Microsoft Co-Sell · Google Co-Sell · Co-Sell Operations | The joint-selling motion: how to engage hyperscaler field organisations, operate per-platform co-sell mechanics and run co-sell operations at scale across CRM, partner portals and marketplace. |
| Cloud Marketplace | Cloud Marketplace Listings · Private Offers · Cloud Marketplace Operations | The procurement channel: how to list on marketplaces, structure private offers (including channel-partner variants) and operate the back-office that supports marketplace transactions including metering, reconciliation and revenue recognition. |
Plus a cloud GTM glossary of 50+ entries covering the acronyms, program names and terms of art that recur across the series.
Suggested Reading Paths
The pillars stand alone; the cluster posts dive into specifics. Common reading paths depending on what you’re trying to do:
“I’m new to this discipline.” Start with Cloud Alliances for the conceptual foundation, then Cloud Partner Programs and Specialisations for the formal program structures, then Cloud Alliance Team for how to structure the team that operates it. By the end of this path you’ll have a working mental model of the function, who staffs it and how it interacts with direct sales.
“I’m trying to fix our co-sell motion.” Start with Hyperscaler Co-Sell for the model, then read the per-platform cluster relevant to your primary hyperscaler (AWS Co-Sell / Microsoft Co-Sell / Google Co-Sell), then Co-Sell Operations for the tooling and attribution mechanics. The pillar identifies which of the seven co-sell building blocks is your bottleneck; the per-platform post tells you how to operate against the specific hyperscaler’s mechanics; the operations post covers what to build vs buy.
“I’m setting up marketplace ops.” Start with Cloud Marketplace for the procurement-channel framing, then Cloud Marketplace Listings for the listing process and technical validations, then Private Offers for the transaction mechanics including CPPO and MPO, then Cloud Marketplace Operations for the back-office stack covering metering, reconciliation and revenue recognition.
“My product is customer-deployed and the standard playbook isn’t working.” Start with ISV-Hosted vs Customer-Deployed – this is the definitive reference for the tenancy-archetype dynamic that reshapes everything else in the series. Then Cloud Alliance Team for the role-design implications (particularly the Co-Sell PDM-vs-field-alliance-manager split). Then Hyperscaler Co-Sell for the field-engagement mechanics, and the per-platform cluster relevant to your primary hyperscaler for the specific AE / specialist-seller / technical-counterpart relationships you’ll need to build.
“I’m building a multi-cloud motion.” Read all three pillars first (Cloud Alliances, Hyperscaler Co-Sell, Cloud Marketplace) for the cross-platform model. Then the three per-platform co-sell posts (AWS Co-Sell, Microsoft Co-Sell, Google Co-Sell) for the operational specifics. Then Co-Sell Operations for the cross-platform tooling considerations including bidirectional sync between CRM and the three hyperscaler partner portals.
“I’m in finance and inheriting marketplace ops.” Start with Cloud Marketplace Operations – the revenue recognition, principal-vs-agent treatment and reconciliation rhythm sections are written for your audience. Then Cloud Marketplace for the broader context and Private Offers for the transaction-structure mechanics that affect your accounting policy decisions.
How to Read This
The pillar posts are longer (~5,000–6,000 words each) and serve as standalone definitive guides on their topic. Cluster posts are tighter (~2,500–3,500 words each) and assume the reader has either read the pillar or knows the foundational vocabulary.
External citations link to vendor primary sources where available, named industry research where cited and practitioner models where attributed.
Numerical claims throughout the series are tiered by hedging strength. Vendor-published or directly verifiable figures (marketplace fees, program eligibility structures, fiscal-year cycles) are presented as practitioner facts. Practitioner-cited figures that circulate through vendor and analyst channels (the Omdia / Canalys and Tackle stats that recur in the pillars) are directly flagged as directional and as practitioner-cited rather than independently verified primary-source research. Composite mini-case figures in the “What this looks like in practice” sections are drawn from patterns across multiple real situations.
This is a living series. Each post carries a “last reviewed” date stamp; pillars are reviewed twice yearly after the major hyperscaler conferences (AWS re:Invent and Microsoft Ignite in late November / early December; Google Cloud Next in late April / early May), and clusters are reviewed on a mix of rhythms depending on how vendor-specific the content is. Major program changes between reviews are recorded in each post’s Updates section.
Updates and Feedback
Comments on individual posts and substantive engagement on LinkedIn are welcomed. Each post has an Updates section at the foot that captures dated corrections and program changes – these credit contributors where appropriate and help keep the series accurate as hyperscaler programs evolve.
Disclosure
Commercial relationships. The author has a professional relationship with CONNACT, whose published materials are among the sources this series draws on. This series also draws on published materials from Tackle, Suger and the hyperscaler documentation sites, and aims to be vendor-neutral across all three hyperscaler ecosystems. Readers should weigh that relationship accordingly.
Copyright. Unless otherwise stated, all written content in this series is © Chris Buckel / flashdba. For permissions beyond reading and linking, please get in touch via the contact details on the About page.
AI use. AI tools are used to assist with research, drafting and editorial review across this series. The ideas, analysis, practitioner judgements and final published content are the author’s own.
Accuracy and citation. This series is provided in good faith. Reasonable efforts are made to ensure accuracy, but no warranty is given regarding completeness or reliability; any reliance you place on the information here is at your own risk. If you quote or reproduce content from this series – whether in writing or as training or retrieval material for AI systems – please attribute it to Chris Buckel / flashdba.com and link to the source post.
Last reviewed: 2026-07-01. The hub is reviewed when the underlying post directory changes (new posts added, post titles or URLs changed) and at least annually.
Updates
(No updates yet. This section will record dated corrections, structural changes to the series and notable post additions or revisions as they happen.)
© Chris Buckel / flashdba. Full disclosure and terms: flashdba.com/about/legal/. If you quote or reproduce content from this series – in writing or as material for AI systems – please attribute it to Chris Buckel / flashdba.com and link to the source.
flashdba 