Cloud Alliances Explained: How to Build and Scale a Hyperscaler Partnership Function

Most enterprise software vendors reach a point where direct selling alone stops scaling. The accounts are right but the relationships aren’t, the deals are in customers’ budgets that have already been committed to hyperscalers, and the sales team has no easy way in. That is the problem a cloud alliance function is designed to solve – and this guide covers how to build one.

TL;DR

A cloud alliance is the operating relationship between a software vendor and one or more hyperscalers (AWS, Microsoft Azure, Google Cloud) – distinct from traditional channel partnerships, and necessary because cloud consumption economics have made hyperscaler co-sell and marketplace channels the dominant procurement path for enterprise B2B software.
The discipline has four operational pillars: Sales (joint pursuits, opportunity sharing, co-sell), Business Development (programs, contracts, tier progression), Partnership Enablement (technical readiness, marketplace operations) and Marketing (joint narrative, MDF-funded activity).
The function lives or dies on three outputs: hyperscaler-influenced or sourced pipeline, marketplace transactions and joint solutions / customer references. Everything else – badges, content, conference presence – is means, not end.
The most significant strategic pre-decision is whether the product runs in the ISV’s cloud account (SaaS) or in the customers’ (deployed software). That choice reshapes every other downstream decision and is the central question of ISV-Hosted vs Customer-Deployed.
A cloud alliance function is not a marketing exercise, not a BDR pipeline and not a glorified deal-registration desk. Treating it as any of those is the most common reason alliance functions fail to move revenue.

What a “Cloud Alliance” Actually Is

A cloud alliance is the operating relationship between a software vendor and one or more hyperscalers – Amazon Web Services, Microsoft Azure, Google Cloud Platform. It encompasses formal program membership, co-sell and pipeline-sharing motions, marketplace listings and transactions, technical validations, joint marketing activity and the named people on both sides who make all of that work.

Cloud alliances are distinct from traditional channel partnerships in several material ways. A traditional channel partnership is about distribution: a reseller takes the vendor’s product, marks it up and sells it to end customers, often combined with services. The economics flow through margin and resale. A cloud alliance is about consumption and joint origination. The hyperscaler does not (usually) resell the ISV’s product – the ISV sells directly to the customer, frequently through the hyperscaler’s marketplace, while the hyperscaler collects revenue from the underlying cloud consumption the product drives. The hyperscaler’s commercial interest in the ISV is therefore as a consumption multiplier and a procurement convenience for the customer, not as a margin generator.

That distinction matters because it changes who the relevant people are, what they care about, how they’re compensated and what counts as a successful interaction. Partner Development Managers (PDMs) and customer-facing Account Executives (AEs) sit on different incentive structures, and the structural reasons are one of the most significant dynamics in the discipline – see ISV-Hosted vs Customer-Deployed for why.

The macro shift driving all of this: the procurement of enterprise B2B software has moved from “buy a perpetual licence, deploy on-premises” through “buy a SaaS subscription, billed by the vendor” to “buy through the hyperscaler’s marketplace, applied against pre-committed cloud spend.” Where the cloud sits, the procurement channel follows.

How the Three Hyperscalers Compare at a Glance

The same discipline plays out somewhat differently across the three hyperscalers. Detailed mechanics are in the cluster posts; the orientation table below is the high-level map. (Marketplace fees vary by platform, offer type and deal attributes; a 3% figure is a useful shorthand only for some baseline transactions.)

Dimension	AWS	Microsoft	Google Cloud
Partner program	AWS Partner Network (APN)	Microsoft AI Cloud Partner Program (MAICPP) – replaced Microsoft Cloud Partner Program	Google Cloud Partner Network – replaced Google Cloud Partner Advantage in Q1 2026
ISV-specific co-sell program	ISV Accelerate (ISVA)	Solutions Partner designations + ISV Success + Azure IP Co-Sell Eligible status	Co-sell Partner path
Co-sell pipeline-sharing system	AWS APN Customer Engagements (ACE), inside Partner Central	Partner Sales Connect (PSC), inside Partner Center	Google Cloud partner portal (lighter than AWS / Microsoft)
Pre-committed spend mechanism	Enterprise Discount Program (EDP)	Microsoft Azure Consumption Commitment (MACC)	Google Cloud Minimum Commitment Obligations (marketplace drawdown); MCCP is a separate Google Marketplace Customer Credit Programme
Marketplace	AWS Marketplace	Microsoft Marketplace (unified from Azure Marketplace and AppSource on 25 September 2025)	Google Cloud Marketplace
Technical validation	Foundational Technical Review (FTR)	Well-Architected Review	Architecture Review
Term for customer’s cloud environment	Customer account	Customer tenant	Customer project (sometimes customer organisation)

The “customer’s cloud environment” terminology row matters for customer-deployed ISVs: each hyperscaler uses its own term for the cloud environment in which the software runs. AWS documentation refers to “the customer’s account”; Microsoft uses “the customer tenant” (the Entra ID identity boundary) and “the customer subscription” (the billing and resource-management scope within that tenant where resources actually run) – both terms are common in practice; Google Cloud most often says “the customer’s project” (the fundamental resource container in GCP’s hierarchy) though “customer organisation” is also used. This series uses the neutral term “customer’s cloud environment” throughout; see ISV-Hosted vs Customer-Deployed for the full treatment.

The names and the specifics differ; the underlying motion is recognisably the same. A working alliance function operates these as parallel rails, not as three independent disciplines.

Why Cloud Alliances Now Matter to Almost Every B2B Software Vendor

The strategic case used to be optional. It is no longer.

Industry research has converged on a consistent picture. Omdia figures (including research formerly published under the Canalys brand, which Omdia acquired in 2023) circulated by AWS put the SMB cloud-attached partner-managed market at roughly $87 billion by 2027, with partners forecast to manage 65% of public cloud spend by 2026. According to AWS’s ISV Accelerate page, 51% of partners report higher average revenue growth as a result of co-sell motions. Omdia’s AWS Partner Ecosystem Multiplier 2025 Study, cited by AWS, states that AWS partners can achieve up to US$7.13 in services revenue for every US$1 of AWS technology sold. Tackle’s annual State of Cloud GTM paints a similar picture: marketplace as procurement channel has accelerated from niche to mainstream in three years, and ISVs that aren’t operating co-sell motions are systematically losing deals to ISVs that are.

Treat the specific numbers as directional and as practitioner-cited rather than independently verified primary-source research. The figures circulate through vendor channels (Omdia / Canalys data typically via AWS partner-network communications), move year over year and rely on methodologies that aren’t always fully transparent. The direction is what matters. Co-selling ISVs grow faster. Marketplace-transacting ISVs close faster. Hyperscaler-influenced pipeline is larger and converts better than equivalent direct-only pipeline. Verify the specific percentages against primary sources before quoting them as fact in customer-facing or board-facing material.

The reason for all of this sits with the buyer, not the seller. Enterprise customers under EDPs (AWS), MACCs (Microsoft) or Google Cloud’s CUDs and MCCP have pre-paid for cloud capacity and would rather draw it down by buying third-party software through the marketplace than open a fresh procurement cycle. The marketplace is therefore not principally a discovery surface – it is a procurement system. ISVs that aren’t accessible through that procurement system are functionally invisible to the part of the customer base that has the largest budgets and the most committed spend.

The mechanics of how a customer’s commit drawdown actually works through each cloud’s marketplace are treated in depth in Cloud Marketplace and Private Offers. The point for this pillar is that the procurement shift is the reason the alliance function exists in its modern form – not partner-program tier badges, not co-marketing budgets, but the underlying fact that cloud commit is now the dominant procurement currency for enterprise software.

The Four Pillars of a Cloud Partnership Function

A working cloud alliance function has four distinct pillars of activity. This framing is adapted from CONNACT’s Cloud Partnership Pillars model, which is the closest thing to a consensus practitioner taxonomy in the discipline. The four pillars are not interchangeable, and underinvestment in any one of them produces a recognisable failure mode.

Sales

The day-to-day operating motion of co-selling specific opportunities with the hyperscaler. The pillar’s activities include opportunity sharing through ACE (AWS), PSC (Microsoft) and Google Cloud’s partner portal; account mapping the ISV’s customer and prospect list against each hyperscaler’s; field-to-field engagement between the ISV’s sellers and the hyperscaler’s customer-facing AEs and specialist sellers; structuring transactions through the marketplace where customer commit drawdown matters; and running disciplined follow-up rhythms on shared opportunities to prevent stall. This pillar is most directly responsible for producing the influenced and sourced pipeline that the rest of the function is measured against. It is also the pillar most often shortchanged when an alliance function is first stood up, because it requires hiring people with operating credibility in sales motions – not marketing managers reassigned, not BDRs promoted – and giving them mandate to work inside both the ISV’s sales process and the hyperscaler’s. The full operating manual is in Hyperscaler Co-Sell.

Business Development

The program-level work that creates the structural conditions for sales activity to happen at all. Activities include enrolling and progressing through the formal partner programs (AWS Partner Network, MAICPP, Google Cloud Partner Network); earning and renewing Specialisations and tier advancement; negotiating program-tier-gated commercial benefits; structuring the legal and pricing terms of marketplace listings and private offers; managing the partner-side contractual relationship; and rationalising effort across the three hyperscalers as their programs change over time. Business Development tends to be the most over-rotated pillar when alliance functions are bolted onto marketing departments – badges accumulate, revenue doesn’t follow. It is also the most under-rotated when alliance functions are bolted onto sales, because programme work isn’t deal-sized and gets crowded out by the next quota call. The right answer is dedicated capacity that understands both sides of the discipline, usually the alliance leader’s direct responsibility before headcount can carry it. See Cloud Partner Programs and Specialisations.

Partnership Enablement

The technical readiness side of the function. Activities include passing – and, importantly, re-passing – FTR (AWS), Well-Architected Review (Microsoft) and Architecture Review (Google); building marketplace listings of the appropriate type (SaaS, AMI/VM, container, etc.) and keeping them current as the product evolves; integrating into hyperscaler-native services where it produces measurable customer benefit; and operating the back-office of marketplace billing, metering and reconciliation. Partnership Enablement is the most demanding in practice of the four pillars and the most often understaffed in mid-size ISVs. Underinvestment shows up as expired listings, failed renewals, technical reviews that drag on for quarters rather than weeks and marketplace transactions arriving at finance unreconciled. It is also the pillar most prone to silent decay – a Specialisation that lapses, a Well-Architected pass that ages out, an FTR rendered invalid by a product architecture change. See Cloud Marketplace Listings and Cloud Marketplace Operations.

Marketing

Joint go-to-market activity, scoped tightly to what produces pipeline rather than to general brand work. Activities include co-branded content, joint webinars, conference presence (re:Invent, Microsoft Ignite, Google Cloud Next and regional partner events), MDF-funded campaigns tied to named target accounts, joint customer reference development and the production of better-together narratives that field sellers can take to specific customer conversations. The Marketing pillar is most useful when tied directly to Sales – campaigns produce opportunities that feed joint account plans – and least useful when run as a standalone activity disconnected from pipeline outcomes. The conventional failure mode is alliance-marketing as cost centre: large MDF budget, plenty of activity, no attributable pipeline and no theory of why the activity should produce pipeline in the first place. See Cloud Provider Funding for the funding-program mechanics and Cloud Alliance Team for where the marketing role sits within the team structure.

A consistent failure mode at every stage of company maturity: under-investing in one or two of these pillars. Most commonly the Sales and Partnership Enablement pillars get neglected – they are demanding in practice and produce less visible activity than program badges or co-branded events. The discipline does not work without all four operating together.

Direct Sales vs Cloud Sales: Fundamentally Different Motions

The temptation, particularly for ISVs hiring their first alliance lead, is to treat cloud alliance work as “sales with a different counterparty.” That framing produces sub-optimal hires, mis-designed comp plans and disappointment within 18 months.

The differences are structural. A direct seller’s KPIs are pipeline generated, qualified opportunities, closed-won revenue, quota attainment. A Cloud Alliance Manager’s KPIs are influenced and sourced pipeline with the hyperscaler, marketplace transaction count and value, ACE / PSC / partner-portal opportunity acceptance rates, joint account plans in place and hyperscaler relationship depth (named PDMs, named AEs, named Customer Engineers (CEs) / Solutions Architects (SAs) / Cloud Solution Architects (CSAs) across regions).

A direct seller’s counterpart is a customer buyer. A Cloud Alliance Manager’s counterpart is a hyperscaler PDM, plus the customer-facing field of that hyperscaler. The conversations are different. The rhythm is different. The political and organisational dynamics are different. A skilled enterprise AE who has never operated in this environment will find roughly half of their muscle memory unhelpful for the first six months.

A direct seller’s success comes from closing customer transactions. A Cloud Alliance Manager’s success comes from engineering an ecosystem in which co-selling and marketplace transactions become the default path of least resistance – with the right comp incentives and the right hyperscaler relationships in place to make that happen. It is a more systems-y kind of work than direct selling, with longer feedback loops and less daily dopamine.

Comp design follows the same logic. Direct sellers are typically on base-plus-commission tied to bookings. Alliance manager comp structures vary widely: commission on sourced or influenced pipeline, MBO against programme milestones and relationship targets, commission on marketplace transaction volume, or hybrids of these. The right structure depends on how cleanly attribution can be measured in the ISV’s systems – where deal-registration infrastructure is strong, pipeline commission is defensible; where attribution is murky, MBO sidesteps disputes at the cost of some incentive alignment. The detailed mechanics – including the perennial problem of how to pay both an AE and an alliance manager for the same deal without double-counting or under-paying either – sit in Cloud Alliance Team.

The Three Things a Cloud Alliance Function Must Produce

Cut through the activity and a working cloud alliance function produces three outputs:

Influenced or sourced pipeline with the hyperscaler. Deals the hyperscaler is aware of, working jointly with the ISV and motivated to help close. Measured by ACE / PSC / partner-portal opportunity records, joint account plans in flight and follow-through to closed-won.
Marketplace transactions. Customer purchases of the ISV’s product made through AWS Marketplace, Microsoft Marketplace or Google Cloud Marketplace – typically (though not always) structured as private offers, often drawing down customer commit. Measured by transaction count, transaction value, public-vs-private mix and commit-tagged share.
Joint solutions and customer references. Reusable joint value propositions and named-customer evidence that future co-sell pursuits can lean on. Measured by named-reference count, joint solution publication and qualitative depth of hyperscaler-side endorsement. This is the hardest of the three to operationalise and the easiest to neglect.

Different ISVs over-rotate on different outputs. The most common pattern is over-rotation on output 2 (marketplace transactions) at the expense of output 1 (sourced pipeline) – listings get built, but no co-sell motion ever materialises and the listings produce only the deals the customer was always going to do. The second-most-common pattern is over-rotation on output 3 (marketing-led joint content) at the expense of outputs 1 and 2 – beautifully produced joint narratives that no field seller ever uses.

What “produces pipeline” actually looks like in practice depends critically on whether the product runs in the ISV’s own cloud account or in customers’. The substantial population of ISVs whose products run in customer cloud accounts – infrastructure, data platforms, security, observability, networking – experiences fundamentally different field dynamics from ISVs hosting multi-tenant SaaS in their own accounts. The standard playbook implicitly assumes the SaaS archetype; for the customer-deployed population, it actively misleads. The structural reasons sit in ISV-Hosted vs Customer-Deployed, which is the definitive resource the rest of this series links back to. Worth reading early – many of the practical decisions in this pillar flow from it.

Maturity Model Overview

The discipline maps onto four broad stages of maturity. The names are adapted from the Tackle model with attribution:

Establishing Foundation. A single person – often the founder, a senior product or marketing leader or a first dedicated alliance hire – builds initial hyperscaler relationships. Marketplace listings may exist but are not transactable at meaningful scale. Co-sell is opportunistic, conversation-driven and largely undocumented. You’re at this stage if: no dedicated alliance hire, no transactable marketplace listing, no formal opportunity-sharing flow in operation, technical validations not yet passed. Advance by: making the first dedicated alliance hire, standing up a transactable marketplace listing on the primary cloud, passing first technical validation (FTR / Well-Architected Review / Architecture Review).
Building Adoption. A small alliance function exists, with named CAMs per hyperscaler. Opportunity-sharing through ACE / PSC / partner portals is operational. Specialisations are in place for at least one hyperscaler. Marketplace transactions are a regular but minority share of new business. You’re at this stage if: 1–3 dedicated alliance hires, opportunity-sharing operational with acceptance rates above 40%, first Specialisation earned, marketplace transactions a regular occurrence but primarily renewals routed through marketplace at customer request. Advance by: building tooled bidirectional sync between CRM and partner portals, taking the second hyperscaler to co-sell-eligible status, growing marketplace transaction volume to a consistent cadence – the right absolute number varies significantly by deal size and product category; roughly 10 per quarter is a reasonable marker for mid-market or high-volume ISVs, but infrastructure and enterprise ISVs with high average deal sizes will reach this stage at materially lower transaction counts – with the net-new mix exceeding renewals.
Driving Adoption. Multiple CAMs per cloud, often regionalised. Tooling automates the bidirectional sync between CRM and partner portals. Marketplace is the dominant procurement path for a significant share of new and renewal business. Joint account plans cover the top-50 to top-100 named accounts per cloud. You’re at this stage if: regional CAMs in place, Cloud GTM Platform tooling operational, marketplace transactions running at a consistent high cadence (15+ per quarter for mid-market or high-volume ISVs; proportionally fewer for infrastructure and enterprise ISVs where individual deal sizes are large), joint account plans on top-50 named accounts per cloud, second hyperscaler at Building Adoption maturity. Advance by: marketplace transactions becoming the majority of new enterprise business in the engaged customer segments, hyperscaler-led pipeline reaching parity with partner-led, comp alignment fully resolved across alliance and direct sales.
Scale. Cloud GTM is integrated into the rhythm of business – direct sales, alliance, RevOps, marketing and finance all operate on a shared rhythm. Co-sell is the default motion, not the exception. Marketplace transactions are a majority share of new business. The function is comp-aligned, tool-supported and run by a VP-level leader with peer-equal standing to the direct-sales CRO. You’re at this stage if: marketplace is the majority of new enterprise business in target segments, hyperscaler-led pipeline at parity or above with partner-led, all five hyperscaler engagement layers (see Hyperscaler Co-Sell) actively cultivated, finance and RevOps both running marketplace-specific playbooks alongside direct-invoicing playbooks.

The progression is not strictly linear, and not every ISV needs to reach Scale. The question is whether the function’s maturity is appropriate to the company’s stage, its addressable market and the share of that market that prefers to procure through marketplace. These stages are described for a single hyperscaler; running all three simultaneously requires either dedicated per-cloud owners or an honest acceptance that the second and third clouds will lag the first by more than per-cloud effort estimates suggest. The team-shape implications of each stage are covered in more depth in Cloud Alliance Team.

How Alliance Functions Usually Fail

Some of the most common anti-patterns, in roughly the order they tend to appear:

The “alliance team bolted onto product marketing” failure. The function is handed to a marketing leader who builds joint webinars, conference presence and badged collateral, none of which produces pipeline. Two years later the company can’t understand why the partner relationship hasn’t moved the revenue needle. The fix is structural: alliance work is sales work first; marketing is the fourth pillar, not the first. Reporting-line decisions follow.

The “no comp alignment” failure. Consistently cited by practitioners as among the most expensive and most damaging failure modes in the discipline – and, in the experience this series draws on, one of the most frequently encountered. The alliance team brings opportunities to direct AEs. The AEs ignore them, or work them grudgingly, because co-sold deals carry coordination overhead that direct deals don’t – joint account plans, hyperscaler submissions, alliance team involvement – without a proportional uplift in quota credit to compensate for that overhead. Where comp structures also give the alliance manager partial credit on the same deal, some AEs perceive their own attainment as diluted even when the arithmetic says otherwise. The downstream compounding is severe: alliance pipeline ages out in the AE’s queue, the alliance function looks like it’s producing motion without outcomes, leadership questions the investment, the alliance team’s standing erodes and the cycle accelerates. The fix is structural: AEs need explicit quota retirement or a credible incentive on partner-influenced deals, not just permission to work them. The detailed mechanics of what “credible” looks like in practice – quota multipliers, shared credit structures, MBO components – are in Cloud Alliance Team.

The “silent marketplace bypass” failure. Closely related to comp misalignment and often invisible until the damage is already done. Individual deals are taken direct rather than through marketplace – each one justified in isolation as the right commercial decision for that specific situation. The AE makes the call; the alliance manager is not in the room; the customer doesn’t know the difference. Individually each bypass is invisible. Cumulatively, over four to eight quarters, they accumulate in hyperscaler reporting as an ISV that generates low marketplace transaction volume relative to its ARR and co-sell pipeline. That pattern directly affects Specialisation tier progression – tier re-qualification increasingly depends on demonstrated marketplace transaction volume – and PDM engagement quality, as hyperscaler field teams quietly deprioritise ISVs whose marketplace presence looks thin relative to their stated partnership ambitions. The fix requires comp design (gross-revenue-quota rather than net-revenue-quota on marketplace-routed deals), explicit routing policy with approval gates for exceptions and AE education on committed-spend mechanics. Full treatment in Cloud Marketplace Operations.

The “no executive sponsorship” failure. The alliance leader has no peer-level executive sponsor (CRO, CEO or a strong board member). When direct sales or product leadership push back on resource allocation, alliance loses every contest. The fix is rare and usually means hiring at the right level – a senior alliance leader with credibility to push back on a CRO, or operating under a CEO who treats cloud GTM as a strategic priority rather than as a marketing line-item.

The “single-cloud strategy” failure. The ISV invests heavily in one hyperscaler – usually whichever one its largest customers are on – and ignores the others. As the customer base grows, the ISV finds itself locked out of customer commit-drawdown on the other clouds, losing deals it had a credible technical fit for. The fix is to multi-home early enough that the second and third clouds are a cost-effective parallel investment, not a panicked catch-up two years too late.

The “treating co-sell like deal-reg” failure. The team submits every opportunity in pipeline to ACE / PSC / partner portals, drowning the hyperscaler in noise. Acceptance rates collapse. PDMs stop returning calls. Joint pursuits get hidden among undifferentiated submissions. The fix is selectivity – submit opportunities where joint engagement actually changes the outcome, and let the rest run as direct deals.

The “vanity tier” failure. The ISV pursues the top tier of one or more partner programs without a clear theory of which tier-gated benefits produce revenue. Effort goes into badge work; deals go to competitors with lower tiers but better field motions. The fix is to start from the benefit (which AE incentive, which marketplace fee reduction, which co-sell tooling), work backward to the tier or designation that unlocks it and resist tier chasing for its own sake.

The honest reading: these failures are common because the discipline is genuinely difficult and the feedback loops are long (12–18 months to know whether an investment is working). Many of the people brought in to run cloud alliance functions arrive carrying one of the failure modes above as a default. The habits that produced the failure tend to travel with the person.

What “Good” Looks Like at Scale

The mature state, when an ISV is operating cloud GTM well:

The alliance function is not asking direct sales for permission to engage on accounts. It is engaging by default, and direct sales is comp-aligned to welcome that engagement. The hyperscaler PDMs return calls within a working day, not a working week. Joint account plans are written for the top-50 named accounts per cloud and are referenced in QBR-rhythm reviews on both sides of the table. Specialisations are renewed annually through real-deal execution, not through preparation pushes – which, since 2026, is the only way some of them can be renewed at all.

Marketplace transactions are the default path for net-new enterprise business in the customer segments where commit drawdown matters. Private offer cycle time is measured in days, not weeks. The metering, billing and reconciliation stack is automated end-to-end, with the disbursement file reconciled to the ERP within five working days of receipt. Disputes are rare and resolved without escalation.

The alliance team has named contacts inside the hyperscaler at the AE level (for customer-deployed products), at the PDM level (for SaaS-archetype products), at the SA / CE / CSA technical level, at the regional and industry-leadership level and at the marketplace-category lead level. Field enablement happens on a recurring rather than ad-hoc basis. MDF and migration funding are tracked through to attributable pipeline outcomes, not treated as discretionary marketing budget.

The KPIs in the alliance metrics model are reported on a monthly rhythm, presented in board materials and meaningfully drive resource allocation between clouds, regions and partner programs.

That’s the destination. Few ISVs are there. Most that get there took three to five years to do it. The interim states are valuable in their own right – building Adoption maturity on one cloud is a real, revenue-producing achievement even before the second cloud catches up.

Beyond the 3P Motion: The First-Party Path

Everything in this series describes the 3P motion: the ISV sells its own product through hyperscaler channels – marketplace, co-sell, alliances. A distinct and considerably rarer outcome is the 1P path: the hyperscaler licenses the ISV’s technology and delivers it as a native platform service, with the hyperscaler owning the selling, billing, support and customer relationship. Azure NetApp Files is the clearest example – delivered natively inside Azure’s management plane, billed through Azure, supported by Microsoft, built on NetApp’s underlying technology. Amazon FSx for NetApp ONTAP and Google Cloud NetApp Volumes complete the picture across all three clouds.

The 1P path is vanishingly rare – achieved by a very small number of ISVs, typically at significant scale and after years of deep hyperscaler partnership. It is worth understanding precisely because the distribution reach and validation signal are so significant, but ISVs that spend meaningful time pursuing it are almost always better served by investing that energy in the 3P motion that precedes and, in most cases, replaces it.

It is a corporate development event, not a GTM motion. Achieving 1P status requires a licensing negotiation, a technical integration at the platform level, a revenue-share structure and a long-term commercial relationship that is entirely deal-specific and largely confidential. There is no repeatable playbook for how to get there. The most relevant point this series can make is that outstanding 3P execution – demonstrable consumption impact, a strong named-customer reference base, Specialisation status, marketplace transaction history – is the most credible foundation from which to be considered as a 1P candidate. Hyperscalers are not offering 1P status to ISVs without a proven 3P record.

The trade-offs are material. The gains are real: native platform distribution, hyperscaler field selling the product, surfacing in the main cloud console alongside native services rather than in the marketplace, and removal of the customer’s “do we buy the 3P product or use the native service?” objection. The losses are equally real: pricing autonomy (the hyperscaler sets the price), direct customer relationship ownership (the hyperscaler owns the contract and support obligation), GTM independence (the ISV becomes an OEM supplier rather than a vendor with its own field motion).

The cannibalisation problem is severe and consistently underestimated. When an ISV achieves 1P status, its existing 3P products almost inevitably become competitive with the new 1P service. An ISV with a storage or data platform product running across all three major clouds as a 3P offering, which subsequently achieves 1P status on some or all of those clouds, now has its own field competing directly against the hyperscaler-delivered version of its own technology. The ISV’s sales team is compensated on the 3P product; the hyperscaler’s field team sells the 1P service. The ISV’s alliance function watches the ISV’s direct sales motion and the hyperscaler’s field motion pull in opposite directions on the same customer accounts. This dynamic is not unique to any one company; it is structural to the 1P motion for any ISV that retains a competing 3P product alongside the licensed 1P service.

For ISVs in the 3P motion, the 1P path sits at the intersection of product strategy, corporate development and long-term commercial relationships. Understanding it accurately is worth more than aspiring to it prematurely.

How to Start If You Have Nothing Today

A practical staging for an ISV starting the discipline from a near-zero baseline.

Most of what follows applies to both tenancy archetypes, but several decisions fork by archetype. The forks are flagged inline as (SaaS path) and (customer-deployed path) notes. If your product runs in customer cloud accounts, read ISV-Hosted vs Customer-Deployed alongside this section before scoping the first hire – the role profile and engagement-layer prioritisation differ significantly from the SaaS-archetype default.

First 90 Days

Assign a named owner of the cloud alliance discipline at the executive level. Not a steering committee. One person, accountable for the outcome. Hiring is fine; assigning an existing leader is fine; spreading responsibility across three half-time people is not.
Pick one hyperscaler as the initial focus. Almost always whichever cloud the largest existing customers are on. Don’t try to spin up three motions simultaneously with one person.
Open formal program enrolment with the chosen hyperscaler. Begin the relevant technical validation (FTR for AWS, Well-Architected Review for Microsoft, Architecture Review for Google).
Stand up a basic marketplace listing in the chosen cloud’s marketplace. It does not need to be perfect; it needs to be transactable. (SaaS path): a SaaS listing with metering integration if pricing is usage-based. (Customer-deployed path): an AMI / VM or container listing depending on the product’s deployment artefact – container-first where the customer base has shifted that way.
Make the first deliberate hyperscaler-side contact: a named PDM (SaaS path) or a named AE or specialist seller in a target account (customer-deployed path). Documented in a CRM record, not just remembered.

First 180 Days

Hire or assign a dedicated CAM for the chosen hyperscaler if not already done. Senior enough to be credible across direct sales and product; experienced enough to recognise the failure modes in the previous section before falling into them. (SaaS path): the CAM should be strong on partner-program mechanics, marketplace operations and PDM-relationship rhythm. (Customer-deployed path): the CAM profile shifts toward field-credible sales / BD with proven ability to do cold outbound to hyperscaler AEs – closer to a senior enterprise AE than to a partner-ops manager. See ISV-Hosted vs Customer-Deployed for the role profile.
Operationalise ACE / PSC / partner-portal opportunity sharing for the first five to ten active customer pursuits. Establish what “submission-ready” looks like internally – the bar should be higher than what feels comfortable. (Customer-deployed path): opportunity-sharing volume matters less than AE-relationship depth in target accounts; prioritise quality and named-customer evidence over throughput.
Close the first marketplace private offer transaction. The mechanics are more demanding in practice than direct invoicing for the first deal and substantially easier on subsequent deals – push through the first one even if it costs more friction than it saves cycle time.
Establish a regular working rhythm (weekly or fortnightly) with the named PDM. Bring named-account discussion, not just program-status updates. (Customer-deployed path): mirror this rhythm with the priority customer-facing AEs as well; for many customer-deployed ISVs the AE rhythm will be the more productive of the two.
Start the second hyperscaler in parallel if customer demand justifies it. Resist if it doesn’t.

First 12 Months

Have the chosen hyperscaler operating at the Building Adoption maturity stage: a named CAM in seat, at least one Specialisation earned or in flight, opportunity-sharing through ACE / PSC operational, marketplace transactions occurring regularly and basic joint account plans written for the top ten named accounts.
Begin the second hyperscaler at the Establishing Foundation stage if not already underway. Same staging: program enrolment, basic marketplace listing, first PDM or AE contact.
Resolve the comp question. Direct AEs should be receiving quota retirement or a credible incentive for working co-sold deals. If they aren’t, this needs fixing before anything else scales.
Audit the comp, tooling and reporting stack. Most ISVs entering year two of the discipline discover the systems wired up in year one don’t scale past roughly 50 active co-sold opportunities and need a deliberate uplift. See Co-Sell Operations.

The shape of the milestones varies by company stage, ARR and tenancy archetype. A Series A infrastructure ISV will reach the 12-month state differently from a Series D SaaS ISV. The order of operations is broadly the same.

What This Looks Like in Practice

A composite example, drawn from patterns across multiple real situations.

An infrastructure ISV with $45M ARR, predominantly customer-deployed software, decided in mid-2024 to build a cloud alliance function. The founder had been running ad-hoc hyperscaler relationships for four years; some deals had closed through that effort but the motion was opaque, undocumented and not scalable. The company’s three largest customers were AWS-anchored; the next dozen split roughly evenly between AWS and Azure.

The first hire was a senior CAM for AWS – ex-hyperscaler, with a credible track record of having worked customer-deployed infrastructure products through the AWS field. Comp was base-plus-MBO with three components: influenced pipeline (40%), marketplace transactions (40%) and joint-customer development (20%). She reported to the VP of Sales rather than to Marketing, which an earlier internal proposal had suggested.

The first 90 days produced no closed revenue. They produced a fresh AWS Software Path Differentiated enrolment; a stalled FTR (the first attempt failed on three security controls – typical); four named AE relationships in priority accounts; and one marketplace listing live in private-listing mode. None of that is visible in a revenue report, and the company’s CFO asked, more than once, what exactly the alliance hire was producing. The CRO held the line.

The six-month mark produced the first marketplace transaction – a $400k private offer, closed by a direct AE who had initially resisted involvement and was won over once the commission on the marketplace-routed deal landed on his number at the same rate as a direct transaction. Two more transactions followed within 60 days. The FTR cleared at the second attempt. The team had named contacts at the AE, SA, ISV-PDM and regional-specialist levels in three of AWS’s four geographic theatres.

The 12-month mark: ACE pipeline-sharing was producing six to ten new shared opportunities per month, with an acceptance rate at roughly 60%. Marketplace transactions were running at five to six per quarter. The company began Azure enrolment in parallel and made the first Microsoft PDM contact. Direct AEs were no longer resisting alliance involvement on AWS deals – they had seen that marketplace-routed deals paid out at the same rate as direct transactions.

The 18-month mark saw a leadership hire: a VP of Alliances above the AWS CAM, with hiring authority for an Azure CAM and a marketplace operations manager. Joint account plans were written for the top 25 AWS accounts. The discipline was, at this point, working.

None of that timeline is unusual. The pattern is consistent across infrastructure ISVs in particular: six months for the first meaningful transaction, 12 months for the motion to feel routine on the chosen cloud, 18 months for the second cloud to start contributing, 24 to 36 months for full multi-cloud operating depth.

Common Pitfalls

Beyond the structural failure modes in the earlier section, a handful of practical pitfalls worth flagging:

Underestimating technical readiness effort. FTR, Well-Architected Review and Architecture Review can each represent multiple weeks of engineering and SE time, and they need re-passing as the product evolves. Budget the engineering time directly; don’t expect the alliance team to absorb it.
Hiring too senior too early. A first-stage company hiring a VP of Alliances before there is a working motion to scale produces an expensive senior hire who spends a year building the operational infrastructure a Director should have built and making strategic decisions a CRO should have made. The right first hire is usually a Director or senior IC CAM who can do the operating work, not a VP. The exception is when the company brings in senior alliance expertise in an advisory or fractional capacity – an experienced cloud alliance leader who has built the motion before can compress the learning curve significantly without the cost or commitment of a full-time VP hire. This is particularly valuable at the stage where the company knows enough to know what it doesn’t know, but not yet enough to hire for it permanently.
Treating MDF as a marketing slush fund. MDF is tied (directly or indirectly) to consumption growth on the funding hyperscaler. Spending it without tracking attributable pipeline is leaving the next funding cycle on the table. See Cloud Provider Funding.
Letting Specialisations lapse. AWS Specialisation renewals now require continuing execution rather than one-time activity (a 2026 change applying to the Software Path Differentiated designation; Microsoft and Google have not made directly analogous moves but both programs are increasingly outcome-weighted). A lapsed Specialisation is harder to re-earn than to maintain. Build the renewal cadence into the alliance team’s operating rhythm.
Ignoring the second cloud for too long. Customer commit lives on multiple clouds; a single-cloud strategy ages badly as the customer base diversifies. Even token presence on the secondary clouds (basic listing, program enrolment, named PDM) preserves option value.
Mis-applying SaaS models to customer-deployed products, or vice versa. This is the most significant and most under-discussed pitfall in the discipline. The definitive reference is ISV-Hosted vs Customer-Deployed.
Allowing the direct sales team to systematically bypass the cloud marketplace. Enterprise AEs on large deals have a structural financial incentive to route transactions direct rather than through marketplace: the 3% marketplace fee reduces the revenue base against which their commission is calculated, and on a $10M deal with an 8% commission rate, that is a $24,000 difference to the individual AE. Strong AEs with established executive relationships at key accounts can and do act on this incentive – quietly framing marketplace routing as unnecessary overhead to customers who may not fully understand committed-spend drawdown mechanics. Individually each bypass looks like a commercial judgement call. Cumulatively, over four to eight quarters, the pattern shows up in hyperscaler reporting as low marketplace transaction volume relative to co-sell pipeline, which in turn affects Specialisation tier progression and PDM engagement quality. The fix requires comp design (gross-revenue-quota rather than net-revenue-quota on marketplace-routed deals), explicit routing policy with approval gates for exceptions, and AE education on committed-spend mechanics. Full treatment in Cloud Marketplace Operations.
Enterprise sellers withholding pipeline intelligence from the hyperscaler field. A recurring pattern, and one that is significantly more damaging when it reflects leadership sentiment rather than individual seller behaviour. Classic enterprise AEs who have not previously operated in a co-sell environment often resist sharing active opportunity details with hyperscaler sales teams – and there is a narrow rational basis for this: many hyperscalers sell products that compete directly with ISV solutions within their broader portfolios, making the hyperscaler simultaneously the ISV’s most important partner and a credible competitor. The resistance calcifies when a sales manager, VP of Sales, CRO or President of GTM shares the same distrust, either from prior experience or from competitive concern. When leadership doesn’t trust the hyperscaler as a sales partner, that attitude propagates through the field and the co-sell motion quietly dies – ACE submissions become perfunctory, joint account plans go unshared and the hyperscaler field stops investing in the relationship because they’re getting nothing back. The fix is not a policy; it’s a leadership decision. If the CRO doesn’t visibly and repeatedly back the co-sell motion, the field won’t. If they do, the field follows. See Hyperscaler Co-Sell for how to structure the trust architecture operationally.
Failing to protect alliance-sourced pipeline from inbound attribution conflicts. One of the most consistently underestimated operational problems in cloud alliances: the alliance team does the upstream work of introducing the ISV to the hyperscaler field, the hyperscaler field introduces the ISV to a prospect, the prospect visits the ISV’s website independently and submits a contact form – and immediately, the inbound lead is claimed by marketing or the SDR team. The alliance manager is left trying to prove, retroactively and often without a clean audit trail, that the deal originated from their outbound motion. The conflict is structurally similar to the one that plagues channel teams but is consistently harder to resolve in a hyperscaler context. With a channel partner, the ISV typically operates a partner portal through which the channel partner registers deals, creating a logged record on the ISV’s side. With a hyperscaler, the upstream engagement happens entirely within the hyperscaler’s own systems – the field conversation, the AE’s account notes, the opportunity record – none of which the ISV can access or verify after the fact. The operational fix is internal deal registration: the alliance manager registers the target account in the ISV’s own CRM at the point of first hyperscaler engagement, ring-fencing it from other top-of-funnel sourcing teams before any inbound activity occurs. This requires a universally agreed definition of what constitutes a stage-one opportunity and how alliance attribution is determined – definitions that must be established and documented before disputes arise, not after. Dual attribution models – where multiple teams share credit for a deal each contributed to – are an appealing partial fix but break down at scale for reasons covered in Co-Sell Operations, which also contains the full treatment of the mechanics.
Zombie pipeline: stage-one bloat and the AE gatekeeping problem. The attribution conflict above is one driver of a broader and more damaging failure mode: a cloud alliance function that generates large numbers of stage-one opportunities that will not progress. The zombie pipeline problem is almost always the result of multiple compounding failures operating simultaneously, and it is one of the most reliable ways for an alliance function to lose credibility with leadership. Full treatment in Co-Sell Operations; the root causes and organisational dynamics are important enough to name here.
Treating hyperscaler account team meetings as low-stakes coordination calls. For customer-deployed ISVs, meetings with hyperscaler AEs, specialist sellers and solutions architects covering a named prospect are high-stakes external engagements with parties whose cooperation is discretionary. A hyperscaler team that concludes an ISV is worth bringing into customer pursuits will do so repeatedly and without being asked; a team that concludes the ISV is unprepared or unprofessional will not take another meeting. The failure mode – arriving late, underprepared, with no clear ask and no knowledge of the prospect – recurs in practice, almost always driven by direct AEs who apply full preparation discipline to prospect meetings but treat hyperscaler meetings as internal calls. A variant occurs when the alliance team generates more meetings than the direct AE can attend with adequate preparation. Both produce the same outcome: reputational damage with the hyperscaler team that is hard to reverse. Full treatment in ISV-Hosted vs Customer-Deployed.

Where to Go Next

The cluster posts under this pillar:

Cloud Partner Programs and Specialisations – the formal program structures of AWS, Microsoft and Google Cloud, and how to decide where to invest first.
Cloud Alliance Team – roles, structure, comp design and scaling milestones for the team itself.
Cloud Provider Funding – MDF, migration funding, POC credits and the unwritten rules of getting funded.
ISV-Hosted vs Customer-Deployed – the definitive reference for the tenancy-archetype dynamic that reshapes everything else in this pillar.

Adjacent pillars:

Hyperscaler Co-Sell – the operating manual for the day-to-day co-sell motion this function exists to run.
Cloud Marketplace – the procurement and transaction channel that increasingly dominates enterprise B2B software sales.

The full series glossary is at Glossary.

External References

Vendor Primary Sources

AWS Partner Network – APN, ACE and ISV Accelerate program detail.
Microsoft Partner Center documentation – MAICPP, PSC and Microsoft co-sell mechanics.
Google Cloud Partner Network – the Q1 2026 program structure that replaced Partner Advantage.

Independent Analyst Research

Omdia – partner-channel and analyst research on co-sell uplift, marketplace growth and partner-managed cloud spend. Note: Omdia acquired Canalys in 2023; research previously attributed to Canalys is now published under the Omdia brand. The $7.13 services-revenue-per-dollar-of-AWS-technology figure is from the Omdia AWS Partner Ecosystem Multiplier 2025 Study, cited by AWS.

Sources

AWS ISV Accelerate – Co-sell programme benefits and partner revenue growth statistics (Verified June 2026)
AWS Partner Network Blog – AWS Partner Ecosystem Multiplier 2025 Study – Omdia $7.13 services revenue per US$1 of AWS technology sold (Verified June 2026)

Practitioner Models and Industry Commentary

These sources are influential within the cloud-GTM practitioner community and have shaped the working vocabulary of the discipline, but they are published from a commercial or advisory vantage point rather than as independently validated research. Cited for the models and taxonomies they have originated, with attribution.

AchieveUnite – The Hyperscaler Fit practitioner taxonomy of hyperscaler partner segmentation; particularly the dual-PDM framing and the CFO-as-influencer thread.
CONNACT – Cloud Partnership Pillars model, published as a blog on the firm’s own site by a partner-advisory practice. The four-pillar discussion above is adapted from this model with attribution.
Tackle – State of Cloud GTM annual report. Tackle is a Cloud GTM tooling vendor; the report aggregates customer and survey data from a commercially interested vantage.

Last reviewed: 2026-07-01. Pillars in this series are reviewed twice yearly after the major hyperscaler conferences (late November / early December following AWS re:Invent and Microsoft Ignite; late April / early May following Google Cloud Next). Major program changes between reviews are flagged in the Updates section below.

Updates

(No updates yet. This section will record dated corrections, program changes between reviews and community-contributed clarifications as they arrive.)

© Chris Buckel / flashdba. Part of the Hyperscaler GTM Playbook. If you quote or reproduce this content – in writing or as material for AI systems – please attribute it to Chris Buckel / flashdba.com and link to the source. Full disclosure and terms: flashdba.com/about/legal/.