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, marketing partnerships or ecosystem partnerships of a general kind.
Channels means the network of resellers, system integrators, managed service providers and distributors who resell or deliver the ISV’s product to end customers. Channel partners are distinct from hyperscalers; they may co-exist with the hyperscaler motion 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. Wherever possible this series uses the more specific term (hyperscaler, channel partner, ISV, system integrator) rather than the catch-all.
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. |
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.
“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.
“I’m setting up marketplace ops.” Start with Cloud Marketplace for the procurement-channel framing, then Cloud Marketplace Listings, then Private Offers, then Cloud Marketplace Operations.
“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.
“I’m building a multi-cloud motion.” Read all three pillars first, then the three per-platform co-sell posts (AWS Co-Sell, Microsoft Co-Sell, Google Co-Sell), then Co-Sell Operations for the cross-platform tooling considerations.
“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.
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.
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 