ISV-Hosted vs Customer-Deployed: Why Your Software’s Tenancy Model Decides Your Cloud GTM Strategy

The most significant question in cloud GTM is also the one most public material ignores: whose cloud account does your software actually run in? The answer to that question decides your field motion, your team design and your marketplace strategy – more than which hyperscaler you choose, which programme tier you earn or which specialisation you pursue.

TL;DR

  • The question almost no other cloud-GTM material asks: whose cloud account does your software actually run in? Three archetypes – ISV-hosted SaaS (your account), customer-deployed (their account) and hybrid (control plane in yours, data plane in theirs). The answer reshapes every other decision in your alliance motion.
  • Hyperscaler AEs and customer-facing field are paid on customer consumption growth. Hyperscaler PDMs and the broader partner-side organisation are paid on partner consumption and marketplace transactions. The incentives diverge sharply, and the divergence determines who at the hyperscaler is by design motivated to support you.
  • Marketplace transactions partially bridge the two worlds – a marketplace deal counts toward the customer’s commit drawdown and shows up in the partner’s metrics – but the bridge only carries deals that route through marketplace. For non-marketplace business, the alignment splits and customer-deployed ISVs feel it most.
  • The standard alliance playbook implicitly assumes ISV-hosted SaaS. For the substantial population of customer-deployed ISVs (infrastructure, data platforms, security, observability, networking) the playbook actively misleads. You need a different team shape, different field motion and different marketplace strategy.
  • A true hybrid product – where both the ISV-hosted and customer-deployed sides are large enough to move partner AND customer-side hyperscaler metrics independently – runs two motions in parallel and needs explicit internal rules of engagement. Most products with a small ISV-hosted control plane alongside a predominantly customer-deployed workload are customer-deployed in practice for GTM purposes. The test: would removing the ISV-hosted component change which side of the hyperscaler is structurally motivated to support you? If not, it is customer-deployed.

Whose Cloud Account Does Your Software Run In?

Three archetypes account for almost all ISV products.

ISV-hosted SaaS. Multi-tenant software running in the ISV’s hyperscaler account. The customer signs up, gets credentials and consumes the service over a network endpoint. The customer pays the ISV; the ISV pays the hyperscaler for the underlying cloud consumption. Examples: most modern database SaaS, observability and monitoring SaaS, application SaaS. When industry observers say “cloud-native software,” they typically mean this archetype.

Customer-deployed software. Software packaged as an AMI / VM, container image or infrastructure-as-code template, deployed into and run inside the customer’s hyperscaler account. The customer pays the ISV (directly or via marketplace); the customer’s own cloud bill grows as the workload runs. Examples: high-performance database engines, in-VPC data platforms, in-VPC security tools, observability agents inside customer VPCs, networking infrastructure. Common across the infrastructure, data, security and networking layers – the layers where customer data sovereignty, network locality or performance characteristics make hosting outside the customer’s tenant impractical. For storage, database and data-movement platforms specifically, hyperscaler data-egress costs impose a further commercial constraint: routing significant data volumes out of the customer’s environment and into an ISV-hosted tenant generates egress charges that make the ISV-hosted SaaS model commercially unviable at most deal sizes. Customer-deployed is not a preference for these products but a commercial necessity. The exception is at sufficient ISV scale, where a direct commercial arrangement with the hyperscaler to reduce or waive egress charges becomes negotiable – but that threshold is well above the scale of most ISVs.

Hybrid. Control plane (management, orchestration, billing, metering) in the ISV’s tenant; data plane (the actual workload processing customer data and consuming the heavy resources) in the customer’s tenant. What distinguishes a true hybrid from a customer-deployed product with a small ISV-hosted component is whether both sides are large enough to move their respective hyperscaler metrics independently. The GTM test: does the ISV-hosted portion generate sufficient partner-side consumption to engage the PDM in its own right, independently of the customer-deployed workload? If not – if removing the ISV-hosted component would not change which side of the hyperscaler is structurally motivated to support you – the product is customer-deployed in practice for GTM purposes, regardless of the architectural split. Increasingly common as customer-deployed products add managed-control-plane offerings and as ISV-hosted SaaS products add data-residency variants that push processing back into customer accounts.

Some ISVs offer more than one deployment model to serve different customer segments. A common pattern in mature enterprise software categories: a multi-tenant SaaS offering for customers adopting fresh, alongside a customer-deployed offering for existing customers with heavily customised on-premises installations that cannot easily migrate to the shared SaaS model. In verticals such as healthcare IT and financial services, years of accumulated bespoke customisation create a segment for whom the SaaS migration path is impractical regardless of the SaaS product’s quality. The customer-deployed route preserves the relationship while the customer works toward, or decides against, a future migration. A parallel driver in regulated industries: an ISV that built a SaaS offering for unregulated markets may find that expanding into healthcare, financial services or government requires a customer-deployed variant, since regulated customers face compliance, liability, data-residency and security obligations that a shared multi-tenant ISV environment cannot easily satisfy. For ISVs in this position, the dual-deployment reality is not a GTM design choice but a response to customer demand. The GTM implications are covered in Hybrid Patterns and the Handoff Problem below.

The choice between archetypes is mostly a product-architecture decision driven by customer demand and technical constraint – data sovereignty, latency, integration depth, regulatory locality. Few ISVs choose freely. Almost none recognise that the choice they make about product architecture also chooses their cloud GTM motion for them.

A note on terminology. Each hyperscaler uses its own term for the cloud environment in which customer-deployed software runs. AWS documentation consistently refers to “the customer’s account” – the AWS account owned and billed to the customer, into which the ISV’s AMI or container is deployed. Microsoft uses “the customer tenant” – rooted in Azure Active Directory / Entra ID’s tenant model, where each organisation has a distinct identity boundary – and also “the customer subscription,” which is the billing and resource-management scope within that tenant where Azure resources actually run. A tenant can contain multiple subscriptions; both terms appear in Microsoft practitioner documentation and are often used interchangeably, though they are technically distinct levels of the same hierarchy. Google Cloud most often uses “the customer’s project” (the fundamental resource container in GCP’s hierarchy, analogous to an AWS account at the resource-grouping level) and sometimes “customer organisation” (the node above projects in GCP’s resource hierarchy). This series uses the neutral term “customer’s cloud environment” throughout to avoid privileging one hyperscaler’s terminology. Where you see “the customer’s account”, “the customer tenant”, “the customer subscription” or “the customer’s project” in hyperscaler documentation or in field conversations, all describe the same underlying concept: the cloud environment owned and billed to the end customer, not the ISV.

Why This Determines Who at the Hyperscaler Cares About You

The hyperscaler-side incentive structure is the dynamic almost nobody publishes. Two distinct sides of the hyperscaler’s field organisation are paid on two different sets of metrics:

Hyperscaler AEs and customer-facing field are paid – in large part – on the consumption growth of named customer accounts. Their quota retires against customer cloud spend, customer commitment growth and (increasingly) on customer-side marketplace transactions that draw down committed spend. They are by design motivated to support ISVs whose products drive consumption in customer accounts.

Hyperscaler PDMs and the broader partner-side organisation are paid on partner success metrics: partner-side cloud consumption, marketplace transaction volume, ACE / PSC / partner-portal pipeline, partner-program tier, specialisation growth and partner referenceability. They are by design motivated to support ISVs whose products drive consumption in their own (partner) accounts or transact significantly through marketplace.

For an ISV-hosted SaaS product, both sides of the hyperscaler line up reasonably well. The ISV’s own cloud consumption grows with usage (which the PDM cares about), and customers buying the SaaS through marketplace draw down committed spend (which both PDM and AE care about). The PDM is the natural primary champion; the AE engages around marketplace transactions on existing customer accounts.

For a customer-deployed product, the lines diverge sharply. The ISV’s own cloud consumption is roughly static (typically R&D environments, demo and POV/POC infrastructure, and perhaps a small control-plane footprint – with R&D usually the largest component); the customer’s cloud consumption grows significantly with use. The PDM has limited structural reason to engage – the partner-side metrics don’t move much. The AE has every structural reason to engage – the customer-side consumption moves significantly with successful adoption.

Marketplace transactions partially bridge the two worlds. A marketplace private offer is recorded on the partner’s metrics and draws down the customer’s commit and gives the customer-side AE quota retirement. AWS’s SaaS Co-Sell Benefit – also known as SaaS Revenue Recognition – is the cleanest documented example of this bridging mechanic: AWS sellers receive quota retirement when they co-sell SaaS or PaaS solutions with ISV Accelerate partners through private offers that transact on AWS Marketplace. For deals that route through marketplace, both sides of the hyperscaler get paid. But the bridge only carries deals that actually transact through marketplace. For non-marketplace business – traditional direct invoicing, multi-year enterprise contracts negotiated outside marketplace, channel-partner-led deals that route through other paths – the bridge is absent and the alignment splits.

Customer-deployed ISVs feel this split most acutely. The partner-side path is by design weaker; the customer-side path is by design stronger but harder to access without partner-side help.

The Consumption Multiplier

For customer-deployed products specifically – infrastructure, data platforms, security and beyond – there is a dynamic the standard consumption metrics undercount. The product doesn’t just consume cloud capacity directly; it enables additional cloud consumption that wouldn’t otherwise exist. The scale of that enablement can be significantly larger than the product’s own direct consumption footprint, and it is one of the most powerful arguments available in hyperscaler field conversations.

The consumption influence breaks into three distinct tiers, each with different measurability and different levels of credibility with hyperscaler account teams.

Direct consumption. The ISV product’s own components – VMs, storage and networking resources deployed and managed by the product itself within the customer’s environment. Measurable precisely and directly attributable; maps exactly to the AWS PRM, Azure CUA and Google Marketplace attribution mechanisms covered in the Making Your Consumption Impact Visible section below. High credibility because it is one-to-one with verifiable billing data.

Indirect consumption. Consumption from environments that connect directly to the ISV product – database hosts, application servers and workloads that attach to and depend on it. For a storage or data platform, estimable from connection metadata (iSCSI attachment counts and VM sizing, for example) or, where customers consent to agent installation, from agents running inside attached VMs that report precise resource data. Medium credibility: one inference step beyond direct billing data, but defensible with technical evidence.

Enabled consumption. Consumption from workloads whose migration or deployment was made viable by the ISV product and that would not otherwise have been running in the cloud at all. For a business-critical RDBMS platform sitting at the centre of an enterprise data architecture, the claim is substantial: not just the database tier but the upstream and downstream applications, the analytics and AI workloads, the dev/test/UAT environments and the disaster recovery deployments that the production workload anchors. The dollar multiplier at this tier can be enormous. Credibility with hyperscaler account teams is lowest here because the causal chain is long and the claim is inherently self-serving – this is the tier where the ISV must do the most evidential work to be taken seriously. The tier’s significance is also category-dependent: a security endpoint product may generate significant Direct and Indirect consumption but modest Enabled consumption; a business-critical RDBMS platform may anchor an entire application ecosystem.

The measurability challenge at the Enabled tier is real but not permanent. The aspirational evidence asset for any ISV alliances manager is an anonymised customer cloud spend graph showing a significant, sustained inflection in consumption from the point of ISV product adoption. This is powerful because it converts a self-serving claim into a visual, verifiable story: the customer’s own cloud bill demonstrates the migration wave the ISV enabled. Two or three such graphs, across different industries, are expensive in relationship capital and customer-engagement time to produce – and require the customer to share billing data the ISV cannot see on its own, since the consumption sits on the customer’s bill, not the ISV’s. Plan for a small number of willing reference customers rather than a portfolio, and lead with those. Once built, they are highly credible to hyperscaler field audiences who have seen hundreds of generic vendor value-proposition claims.

ISVs that position their product partly on cost efficiency to customers need a coherent way to reconcile that message with the consumption-growth narrative required in hyperscaler field conversations. How to frame the efficiency argument so it lands as an asset rather than a liability with the field is covered in the How to Position With Hyperscaler Field Teams section below.

Building named-customer evidence across all three tiers – verifiable Direct attribution, defensible Indirect estimates and credible Enabled narratives – is the single most productive investment a customer-deployed alliance function can make. The work is expensive in time, customer-relationship capital and sometimes engineering effort; the return is a field-conversation capability that compounds with each new reference added.

Making Your Consumption Impact Visible

A downstream consequence of the tenancy archetype that is consistently underestimated until the first co-sell renewal cycle arrives: how the hyperscaler knows that your product is driving consumption in customer environments. Without a functioning attribution mechanism, the consumption your product generates is effectively invisible to the hyperscaler’s internal systems – and consumption that isn’t attributed doesn’t support Specialisation renewal, doesn’t strengthen the PDM’s case for investing in the relationship and doesn’t flow into the AE’s metrics.

Each hyperscaler approaches this differently, and the two tenancy archetypes are served by different mechanisms.

For customer-deployed ISVs, the relevant mechanisms are:

AWS – Partner Revenue Measurement (PRM). Launched in January 2026, PRM gives AWS partners visibility into the AWS service consumption their solutions drive in customer accounts. Three implementation paths: AWS Marketplace Metering (zero-touch for AMI and ML products listed on AWS Marketplace – if your product is listed and customers buy it through Marketplace, attribution is automatic); Resource Tagging (tag AWS resources in the customer account with the ISV’s Marketplace product code using the tag key aws-apn-id); and User Agent String (include a tracking string in AWS API/CLI calls the product makes). For customer-deployed products listed on AWS Marketplace, the Marketplace Metering path is the most practical – the attribution is automatic and requires no additional customer-side implementation. Resource Tagging is the relevant path for customer-deployed products that make direct AWS API calls without going through Marketplace.

Microsoft – Customer Usage Attribution (CUA). Tracks ISV IP driving Azure consumption in the customer’s subscription, implemented via ARM template GUIDs (for Azure Application offers), Resource Manager APIs or Terraform. A GUID is registered in Partner Center and embedded in the deployment template; Microsoft’s systems associate the resulting Azure resource consumption with the ISV. Notably, CUA is not applicable to Azure VM offers – VM consumption in the customer tenant is tracked automatically and requires no additional implementation from the ISV. For Azure Application offers (ARM template-based deployments), the GUID implementation is required. Known limitations: Azure Kubernetes Service, VM Scale Sets and Azure Batch have documented under-reporting issues.

Google Cloud. Google does not have a formal equivalent to AWS PRM or Microsoft CUA for customer-deployed workloads. Consumption driven by ISV products in customer projects is tracked through the customer’s project-level billing but is not automatically surfaced as partner-attributed consumption to the ISV. Google’s consumption attribution for ISVs is primarily marketplace-mediated – Marketplace transactions are the visibility mechanism, not a deployment-level tagging system.

For ISV-hosted SaaS ISVs, the relevant mechanism is Microsoft-specific:

Microsoft – Partner Reported Azure Consumed Revenue (PRACR). PRACR solves a specific problem for ISV-hosted SaaS: the ISV’s workload runs in the ISV’s own Azure tenant, which means the Azure consumption is billed to the ISV, not the customer. Standard Azure Consumed Revenue (ACR) tracking only sees consumption in customer tenants, so without PRACR this consumption is invisible to Microsoft’s systems and cannot be credited against the customer’s MACC commitment. PRACR is the mechanism that makes this consumption visible: the ISV manually reports (via monthly CSV submission in Partner Center) the Azure consumption associated with each customer’s use of the SaaS product, using the customer’s Subscription GUID(s) to associate the consumption with the correct customer commitment. PRACR is exclusive to partners with Solutions Partner certified software designation and requires the ISV to maintain deal registrations in Partner Center for eligible deals. It is a manual process – the monthly submission overhead is real, and the process is sensitive to data quality (incorrect Subscription GUIDs, mismatched referral IDs and format errors all cause submissions to fail). AWS and Google do not have direct equivalents to PRACR: for ISV-hosted SaaS on AWS, the Marketplace transaction itself is the EDP drawdown mechanism, and there is no manual reporting equivalent; for Google Cloud, marketplace transactions against eligible Minimum Commitment obligations serve a similar bridging function.

The practical implication for alliance operations: consumption attribution should be implemented and tested before the first Specialisation renewal cycle, not after. Discovering that your product’s consumption impact is not visible to the hyperscaler at renewal time – when Specialisation re-qualification depends on demonstrated consumption outcomes – is an avoidable operational failure. The implementation effort for PRM and CUA is measured in engineering days, not weeks, for products already listed on marketplace; the effort for PRACR is an ongoing administrative commitment that should be budgeted into alliance team capacity from the outset.

What This Means for Your Alliance Investment Portfolio

Three different blueprints, one per archetype:

ISV-hosted SaaS. Invest heavily in the partner-side org. The PDM is your primary champion. The marketplace is the central co-sell channel. Field engagement happens largely through the PDM rather than around them. Focus the alliance team on partner-program excellence – eligibility, badges, marketplace operations, joint marketing with the hyperscaler’s partner team. The five-role structure in Cloud Alliance Team applies directly; the Co-Sell PDM role in particular is administrative and pipeline-hygiene-oriented in this archetype.

Customer-deployed. Invest heavily in the customer-facing field. The hyperscaler’s customer-facing roles – AEs, specialist sellers and CE / SA / CSA technical counterparts – are your primary champions. Marketplace is a procurement vehicle for closing committed-spend-drawdown deals, not a co-sell origination channel. Focus the team on direct AE engagement, account-by-account coverage and proving consumption uplift with named-customer evidence. The Co-Sell PDM role from Cloud Alliance Team transforms into a field-alliance-manager role – more sales-oriented, more outbound to AEs, less administrative. Specifically: the role hires more like a senior enterprise AE than a partner-program manager; the comp structure ties to hyperscaler-field-originated pipeline rather than ACE submission volume; the role remains in the alliance function – reporting into Sales risks marginalisation and misaligned expectations, since the role originates and introduces opportunities but does not run them to close (a direct seller is assigned once the opportunity is established); and the role’s primary KPI is hyperscaler field pull (how many hyperscaler field teams are actively bringing this ISV into deals) rather than partner-portal hygiene. Full mechanics in Cloud Alliance Team.

Hybrid. Both, with explicit internal handoff rules (see Hybrid patterns and the handoff problem below). The two motions can co-exist but they cannot operate without rules of engagement – without them they compete internally for the same accounts and both underperform.

The single biggest mistake customer-deployed ISVs make at the team-design stage is copying the SaaS playbook. The team gets stood up with a CAM, a Technical Alliance, a Marketplace Operations Manager and an Alliance Marketing Lead, all reporting through the partner-side PDM relationship. Twelve months later the function has produced administrative excellence – clean ACE submissions, current marketplace listings, well-attended joint webinars – and no field traction. The customer-side hyperscaler field teams the company actually needs to engage have never been spoken to.

The “Do the PDM’s Job Yourself” Problem

This is the central practical issue for customer-deployed ISVs.

When the hyperscaler’s partner-side PDM is by design removed from the customer-facing motion, the work that PDM would naturally do for an ISV-hosted SaaS partner – introduce you to hyperscaler field teams, broker meetings, advocate for joint pursuits, get you onto regional and industry call decks, sponsor your inclusion in QBR-rhythm reviews – simply doesn’t happen. The PDM may take your calls and cheerfully accept your ACE submissions. They will not generate pull on your behalf, because their comp doesn’t depend on it.

Where individual hyperscaler employees do help customer-deployed ISVs – and they do, in observed practice – it is almost always because they personally understand the value the ISV creates for their customers and choose to advocate for the relationship, rather than because the program structure tells them to. That kind of discretionary advocacy is worth cultivating and protecting, but it cannot be systematised or relied upon as a repeatable motion.

The structural reason is worth naming directly. A PDM’s priority list is roughly proportional to each partner’s contribution to the PDM’s metrics – which means partner-side consumption, marketplace transaction volume and partner-program participation. A customer-deployed ISV, whose consumption accrues to the customer’s bill rather than the ISV’s, contributes very little to those metrics regardless of how commercially significant the deals it closes are. This is the program working exactly as designed, not a failure of the individuals involved. The practical consequence is that customer-deployed ISVs are typically allocated to PDMs managing large numbers of accounts with limited bandwidth per partner. Relationship continuity suffers: as partners cycle through PDMs’ portfolios without ever generating the consumption metrics that would elevate them to a more senior PDM’s attention, turnover at the PDM level means the customer-deployed ISV is effectively starting the relationship from scratch on a regular basis. This is not a reason to abandon the PDM relationship – the PDM remains a necessary gate for partner-program benefits, MDF funding and formal co-sell status – but it is a reason not to build the co-sell motion around it.

The function that PDM would have performed has to be built inside your company instead. This is the role that Cloud Alliance Team defines as the field alliance manager – what practitioners variously call co-sell BD, cloud field manager or (revealingly) “the role we hired thinking it was a partner manager and only later realised was something else entirely.”

Mandate of the role. Approach customer-facing hyperscaler AEs and specialist sellers directly. Broker introductions. Build joint account plans around named target customers. Advocate internally inside the hyperscaler at AE / Solution Specialist / industry-lead level. Generate the kind of pull a properly motivated PDM would generate for a SaaS partner.

Skills profile. More sales / BD, less administrative. Comfortable with cold outbound to hyperscaler field reps – a non-trivial skill, and one traditional alliance managers often lack. Able to articulate consumption-uplift stories crisply, including the named-customer evidence covered above. Able to operate inside hyperscaler CRM systems and methodologies (ACE, PSC, MCEM) but as a means, not as the work itself.

Title and reporting line. This is not a “partner manager” role in the traditional sense. The closer analogue is a senior AE with cross-organisation responsibility. Despite the sales-oriented skills profile, the role belongs in the alliance function – reporting into Sales risks marginalisation and misaligned expectations, since the role originates and introduces opportunities but does not run them to close. A direct seller is assigned once the opportunity is established.

Build vs buy. The function can be built in-house, sourced from third-party services that specialise in cloud field engagement, or run as a hybrid of both (a category, not an endorsement of any specific provider; the services market exists at the intersection of recruiting, contract sales and partner advisory). Trade-offs: in-house gives continuity and product fluency; outsourced gives faster ramp and existing hyperscaler-field relationships, at the cost of lower product depth and divided loyalty. Third-party providers can also offer intelligence the ISV cannot easily build internally – data on customer committed spend balances, hyperscaler seller-to-account mappings and accumulated knowledge of individual hyperscaler field teams across their wider client base.

For many established ISVs, in-house dominates once the function reaches a certain scale. A hybrid model – retaining a third-party engagement firm for specific activities or geographies while building out an in-house team – is also workable and has the advantage of maintaining headcount flexibility: third-party capacity can be scaled up or down more readily than FTE headcount, which matters during periods of commercial uncertainty or growth-stage volatility. For early-stage companies that need fast hyperscaler-field traction without 12 months of building, outsourced or hybrid bridges the gap.

The honest economics. This is more expensive per hyperscaler-coverage unit than a standard alliance hire, because you are funding work the hyperscaler should be funding via their own PDM and isn’t. Budget accordingly – the right comparison is not “another alliance manager” but “another enterprise AE focused on hyperscaler-field engagement.” The ROI test is whether the customer-side AE engagement you generate produces enough deal velocity and win-rate uplift to cover the cost. For many infrastructure ISVs it does, easily; for some the numbers don’t work and the alliance motion has to find another path. Run the analysis before scaling the function.

How to Position With Hyperscaler Field Teams When You Are Customer-Deployed

A working playbook for hyperscaler field engagement, distilled from observed patterns:

Establish credentials in the first 90 seconds. Hyperscaler sellers run a mental checklist before deciding whether a partner conversation is worth their time. Getting through that checklist quickly – and correctly – is the prerequisite for anything else in this section to land. Every alliance team member, and ideally every ISV AE and SA who may be in a room with a hyperscaler field team, should be audible-ready with a 90-second credentials statement covering six points:

  1. Category: “We are an ISV.” Establishes the class of partner immediately.
  2. Marketplace status: “We are fully marketplace-deployable and transactable.” Confirms the seller can route a deal through marketplace without friction.
  3. Co-sell eligibility and commit drawdown: “We are co-sell eligible and can retire [MACC / EDP / CUD].” Use the correct term for the hyperscaler in the room. For Microsoft: “We can retire MACC” – the seller hears “my customer can draw down their commit and I get paid on it.”
  4. What you do: One sentence. For a database performance platform speaking to Microsoft: “We enable successful deployment of business-critical databases in Azure.”
  5. How you deploy: One sentence on the tenancy model. “Software licensed and deployed in the customer tenant, utilising Azure compute and storage resources.”
  6. One joint hero claim (optional): Frame it as a joint claim, not an ISV-only claim. “[ISV] + Azure provides the fastest performance for databases in any cloud” lands better than “[ISV] is the fastest database platform.”

The statement should be deliverable in 90 seconds or less. Longer and it becomes a pitch the seller hasn’t consented to yet.

Two things make or break this in practice. The first is per-hyperscaler customisation: the co-sell eligibility language, the deployment description, the hero claim and sometimes even the category framing differ by cloud. A single generic version used across all three hyperscalers is the wrong tool for every conversation. Every alliance team member should have three versions, one per hyperscaler, and should know which one they are using before the meeting opens. Using the wrong commit-drawdown acronym, or presenting Microsoft credentials to an AWS account team, signals immediately that the ISV doesn’t understand the programme – the conversation recovers slowly if at all. The second is team coverage. The statement needs to be known by everyone who will ever be in a room with a hyperscaler field team – not just the alliance manager, but ISV AEs and SAs. The alliance manager will usually get it right. The ISV AE who walks into a joint meeting without knowing the statement, or who reaches for the wrong hyperscaler’s credentials slide, damages relationships that took the alliance team months to build.

The credentials statement is also slide one in any deck used with a hyperscaler field team. Not slide three, not the appendix – slide one. The seller needs to know immediately that the ISV is a legitimate marketplace and co-sell partner before they engage with any subsequent content.

Lead with consumption upside. Hyperscaler field teams have heard a thousand “we’ll help your customer” pitches and discounted most of them. What lands is specific, named-account stories about consumption uplift the field team can recognise and verify. Open with the evidence, not the value prop.

Bring evidence, not theory. Pre-built customer case studies showing measurable AWS / Azure / GCP consumption growth tied to your product are the highest-value asset in the conversation. Theoretical consumption-driver arguments are cheap; named-customer evidence is expensive and valuable. The version that lands sounds like this: “Customer X moved $Y of workload from on-premises to AWS in the last 18 months, driving $Z of incremental AWS consumption. The driver was the customer adopting our product in their VPC, which made the migration economically viable. Here are the named workloads, the consumption pattern and the customer reference.” Build three or four such narratives across different industries before the field conversations begin, not after.

Frame efficiency for the hyperscaler field, not against it. ISV teams often suppress their cost-efficiency message when speaking to hyperscaler field teams, fearing it will cool the relationship. The fear is understandable but the suppression is a mistake – what matters is how the efficiency argument is framed, not whether it is made.

The framing that lands badly: “We will slash your customer’s cloud bill.” Field teams hear this as a direct threat to their revenue and respond accordingly.

Two framings that land well. The first is competitive efficiency: “We make your cloud considerably more cost-effective against [rival hyperscaler].” This positions the efficiency argument in service of the hyperscaler’s competitive interests rather than against their revenue. Field teams are incentivised to win accounts and hold them; an ISV that strengthens the platform’s competitive case against a rival is an ally.

The second – and stronger – is commit reallocation: “We help your customer reduce spending on commodity infrastructure and free up commit for high-value, sticky services like Data and AI.” This framing doesn’t reduce the customer’s total committed spend; it shifts it upward in the value stack toward the services the hyperscaler most wants sold. Data and AI services carry higher margin and higher retention than generic compute and storage, and field teams are increasingly incentivised to drive spending toward them. An ISV that facilitates that shift is genuinely aligned with the field team’s interests.

The same outcome – the customer’s infrastructure costs decrease – reads as threatening in the first framing and valuable in the second and third. The ISV can legitimately use all three in different contexts: the cost-reduction message to the customer’s finance and procurement teams; the competitive-efficiency message to the hyperscaler field in competitive accounts; and the commit-reallocation message to the hyperscaler field in expansion accounts.

There is a deeper point that ISVs consistently underestimate. Hyperscaler field teams are not indifferent to whether their customers get good value from their cloud investment – they are actively invested in it. A customer on a committed spend arrangement is committed to that spend regardless of how efficiently they use it; what the field team cares about is whether the customer exits the commitment period feeling that the investment delivered genuine value. An ISV that improves the cost efficiency of a customer’s infrastructure workload does not reduce the total dollars the customer spends against their commit – it frees up capacity within the commit to redeploy toward higher-value services. The customer’s outcome improves, their confidence in the platform increases and their likelihood of renewing at the same or higher commit level goes up. That result is aligned with the field team’s interests, not in conflict with them. ISVs that suppress their efficiency message out of fear of putting off the seller have misread what the seller actually cares about.

Make the field team’s life easier, not harder. Hyperscaler field teams are over-asked. The partner that requires the least from them – pre-built customer-facing materials, tight technical proof points, light demands on their time, clean opportunity-handoff documentation – wins time in the calendar. The partner that arrives with “can you set up a meeting with the customer for me?” gets deprioritised.

This applies particularly to sponsored introductions. Asking a hyperscaler account team you have never met to introduce you to their customer’s CIO is asking for a significant extension of trust before you have demonstrated that you deserve it. The ask is more likely to land after the hyperscaler team has seen you add value in some form – a joint webinar the customer attended, a reference from a mutual account, a prior technical conversation where you proved you knew what you were talking about.

A useful intermediate step when the relationship is new: tell the hyperscaler seller that you plan to reach out to the customer’s CIO directly, and ask whether they would be comfortable being copied on the email. This is a much smaller ask – passive visibility rather than active endorsement – and most sellers will agree to it. The reason it works: the seller’s own interest in remaining informed about activity in their account means they will say yes, even if they frame their agreement as granting the ISV a privilege. The customer, seeing their recognised hyperscaler seller in the CC, is more likely to respond than they would be to a cold ISV outreach. The hyperscaler builds trust in the ISV incrementally; the ISV gets a warmer first contact than cold outbound would produce.

Respect the seller’s quota cycle. Q4 asks land differently from Q1 asks. New-customer prospecting asks land differently from expand-account asks. Ramping sellers (less than 12 months in role) respond to different incentives than tenured ones. Calibrate the ask to where the seller actually is in their cycle, not where you wish they were.

Ask About Internal Training Slots. This is one of the highest-leverage tactics available to a customer-deployed ISV and one of the least commonly used. Whenever the alliance team or a direct ISV AE builds a new relationship with a hyperscaler field contact – after establishing some rapport, not as a cold opener – ask whether the team runs any kind of internal training or lunch-and-learn programme. If the answer is yes, ask for an introduction to whoever owns that content calendar and request a slot. Frame it as a 30-minute session your team will make genuinely interesting, not a sales pitch. Most field teams run some form of internal enablement; most are receptive to external speakers who can teach something useful about a customer workload problem their team is trying to solve.

The value compounds significantly over time. A presentation delivered to a team of 15 specialist sellers creates 15 potential sources of hyperscaler-led inbound. A recorded version of that presentation – uploaded to an internal training system – continues generating introductions indefinitely. A composite illustration, drawn from patterns across multiple real situations: a specialist seller at a major hyperscaler encountered a customer with an acute workload performance problem. Under time pressure, he searched the internal content library for relevant material and found a recorded product presentation from an ISV, delivered over two years earlier. The video contained exactly the technical narrative he needed. Within days the ISV was in a conversation with the customer; the deal closed quickly and expanded on renewal. The ISV had no knowledge of the video’s role until after the relationship was established. This is field enablement operating as compound interest.

Cloud alliances is a subset of enterprise sales and all standard sales relationship-building tactics apply. The F2F equivalent of the internal training ask – offering to sponsor a team dinner, a happy hour at a conference, or a lunch at the team’s next offsite – will often be declined because hyperscaler compliance policies restrict gifts and travel for field employees. But not always, and the offer itself signals seriousness of intent. The standard enterprise sales playbook does not stop at the hyperscaler’s front door.

Running Hyperscaler Account Team Meetings

For customer-deployed ISVs, meetings with hyperscaler account teams – AEs, specialist sellers, solutions architects and customer engineers covering a named prospect – are among the highest-leverage activities in the co-sell motion. They are also, in observed practice, among the most frequently mishandled.

The meeting is not a courtesy call. It is a one-shot opportunity to build the ISV’s reputation with a team that is evaluating whether to bring the ISV into a customer pursuit, advocate for the ISV in internal conversations the ISV will never see, and be willing to stake their own credibility with the customer on the quality of the ISV’s people and product. A hyperscaler AE who leaves a meeting thinking “these people are worth bringing in” will do so repeatedly and without being asked. An AE who leaves thinking “this was a waste of my time” will not take another meeting, and will not refer the ISV to colleagues. The decision is usually made in the first ten minutes, and it is almost never reversed.

Prepare for the engagement question. Before every meeting, the ISV participants should agree on how to answer the question the hyperscaler team will almost certainly ask: “What engagement have you had with this account so far?” The ideal answer describes an existing interaction – a conversation with a named contact, attendance at an event, a mutual customer reference they’re aware of. If no prior engagement exists, the right approach is honesty paired with a credible rationale for why the account is on the ISV’s target list: a similar customer in the same vertical is a significant user of the product and research indicates an identical use case; the account’s publicly stated technology priorities match the ISV’s specific capability; a recent hire in the customer’s infrastructure leadership suggests an active evaluation is underway. In a quality enterprise GTM team, any AE can explain to their manager exactly why a prospect is on their target account list. The hyperscaler team is asking the equivalent question. An ISV that cannot answer it credibly is spray-and-praying – targeting accounts by volume rather than by qualification – and the hyperscaler team will recognise it immediately.

What a well-run meeting looks like. The ISV participants – whether that is the cloud alliance manager, a direct AE, a technical SE or some combination – arrive on time, on camera, in a professional setting. They have researched the prospect: the account’s current cloud footprint, publicly known strategic priorities, any joint customer history with the hyperscaler, and the specific AE’s coverage focus. They have a clear ask – not “please introduce us to someone senior” but “we believe there is a specific joint opportunity here, here is why, and here is what we would like to do together.” They leave the hyperscaler team with something useful: a case study from a similar account, a technical reference architecture, a consumption-uplift narrative they can repeat in their own words to the customer. The ISV participants are curious about the hyperscaler team’s perspective on the account rather than just presenting at them.

What a poorly-run meeting looks like. The ISV participants join late. One is in a car – camera either off (bad) or on (worse). Nobody has looked at the prospect’s publicly available information. The ask is either absent or absurdly ambitious: “can you get us a meeting with the CIO?” The hyperscaler team is expected to do the work of educating the ISV about the account they are supposedly there to discuss. The ISV participants have not thought about what value they are offering to the hyperscaler in return for their time.

A more extreme variant, drawn from patterns across multiple real situations: an ISV sales team attended a meeting with a hyperscaler account team to request a sponsored customer introduction, opened a slide deck and proceeded to present “Why [ISV] + [Hyperscaler A]?” collateral. The account team was from Hyperscaler B. The meeting did not produce a sponsored introduction.

A second cardinal sin of similar severity: presenting competitive comparison slides that disparage the hyperscaler’s own native or first-party solutions to the hyperscaler’s own account team, or presenting them to a prospect in the presence of the hyperscaler. Most ISVs compete in some way with a hyperscaler’s native offering – sometimes directly and significantly, sometimes in a minor or adjacent way. It is entirely reasonable to maintain a competitive comparison slide for internal use and for direct customer meetings where it is contextually appropriate. It is not reasonable to show it to the hyperscaler whose product is being compared unfavourably, or to present it to a customer while a hyperscaler representative is in the room.

A related variant that produces the same damage by a less obvious route: the ISV presents competitive comparison slides in a direct customer meeting where no hyperscaler representative is present. The session is recorded, or the deck is shared. The customer, seeking the hyperscaler’s perspective on the comparison, forwards both to their hyperscaler account team. The relationship damage arrives by exactly the same route as if the hyperscaler had been in the room – and the ISV typically has no visibility into when or why it happened.

The alternative framing that avoids the problem entirely: acknowledge the hyperscaler’s native offering directly and position the ISV as complementary rather than competing. Two framings that work in practice:

“The hyperscaler solution is a great product and the right answer for many general use cases. It was not designed for your specific requirement, however – and that is exactly why we built our solution.”

“The role of a hyperscaler partner is to augment the hyperscaler’s portfolio of native solutions, not to replace them. That is what we are doing here, and it is why the hyperscaler chooses to partner with us – because they recognise our excellence in this specific space.”

Both framings acknowledge the hyperscaler’s strength, position the ISV as purpose-built for a specific gap and use the partnership itself as a validation signal. Neither requires the ISV to claim general superiority over the hyperscaler’s product – which is rarely accurate, always risky and unnecessary to make the case.

This sounds like an extreme description. It is not. The behaviour recurs across organisations of all sizes and levels of sophistication, and it is almost always the ISV’s direct sales AE rather than the cloud alliance manager who produces it. The explanation is a category error that is easy to make and hard to correct: AEs understand instinctively that a new business meeting with a prospect requires full preparation, structured agenda, researched context and a clear next step. They apply none of that discipline to a meeting with a hyperscaler account team, because the hyperscaler team is not the customer. The category error is treating the hyperscaler meeting as an internal coordination call rather than as a high-stakes external engagement with a party whose ongoing cooperation is discretionary and whose time is finite.

The corrective framing for any AE about to enter a hyperscaler account team meeting: the hyperscaler AE is effectively a senior buyer of your time and credibility. Treat the meeting with the same preparation discipline you would apply to a new business meeting with the prospect themselves.

The zone-flooding problem. A distinct and harder-to-resolve failure mode: the cloud alliance manager is generating a high volume of hyperscaler account team meetings – which is exactly what the function is supposed to do and what the alliance manager’s comp depends on – while the direct AE is simultaneously managing a full pipeline of late-stage direct pursuits. The AE, for cultural reasons familiar to anyone who has worked in enterprise sales, will not decline the meetings. Instead they attend unprepared, doing the minimum required to avoid an argument with the alliance manager while their attention is genuinely elsewhere.

Both parties are behaving rationally within their own incentive systems. The alliance manager is doing their job. The AE is prioritising correctly given their quota exposure. The outcome is a series of meetings that damage the ISV’s reputation with the hyperscaler team rather than building it.

The least-bad resolution requires the alliance manager to be willing to have an uncomfortable conversation with the AE: better to reschedule or cancel a meeting than to run it unprepared. This is difficult to resolve because the alliance manager’s attribution system typically requires the meeting to occur, not to succeed, and because the alliance manager is rarely in a position to compel the AE to prepare. The conversation is easier when the VP of Alliances / VP of Sales relationship is functional and the pipeline governance around alliance-sourced meetings has been agreed in advance – which is one of the concrete operational reasons why that relationship matters beyond the pipeline-attribution issues covered in Cloud Alliance Team.

Running the meeting without the AE is a poor option but sometimes the least bad one. The alliance manager lacks the direct customer relationship and the prospect-specific context the AE holds. Any commitments made in the meeting will require AE follow-through. The hyperscaler team will notice the AE’s absence and draw conclusions. If the alliance manager does run the meeting solo, the scope should be narrowed to relationship-building and information-gathering rather than to joint-pursuit discussion, and the AE should be briefed thoroughly before the next hyperscaler touchpoint.

Hybrid Patterns and the Handoff Problem

The scenarios that produce genuine hybrid GTM complexity are rarer than they look. Three distinct situations are worth separating.

True architectural hybrid. A single product where both the ISV-hosted and customer-deployed sides are large enough to move partner AND customer-side hyperscaler metrics independently. The control plane in the ISV’s tenant generates meaningful partner-side consumption; the data plane in the customer’s tenant generates meaningful customer-side consumption. Both sides of the hyperscaler have structural reasons to engage, but they want different things. The PDM wants marketplace transaction volume, partner-program activity and joint marketing. The AE wants customer consumption uplift, customer references and named-account engagement. Without explicit internal rules of engagement, both channels compete for the same attention budget and neither gets enough. The rules divide the work by activity type:

  • Top-50 named accounts: customer-side AE-led, with the alliance function as field-alliance-manager support.
  • Marketplace-listed standard offer business: partner-side PDM-led, with the alliance function as marketplace-ops support.
  • Joint account plans: written for any account where both motions are active, naming the lead channel and the supporting channel.
  • Comp boundaries: defined in writing, agreed by sales and alliance leadership before deals start landing, with quarterly review.

Mostly customer-deployed with a small ISV-hosted component. Many products have a management, observability or control-plane component in the ISV’s tenant alongside a predominantly customer-deployed workload. This is not a true hybrid for GTM purposes. The ISV-hosted component does not generate sufficient partner-side metrics to make the PDM relationship the primary co-sell channel. The GTM motion is customer-deployed in character; the partner-side path operates in the background. The product architecture looks hybrid; the GTM classification is customer-deployed.

Dual-product portfolio. Some ISVs offer both a fully ISV-hosted SaaS product and a fully customer-deployed product as separate offerings. This is a portfolio question rather than a single-product architectural question, and internal channel conflict is a GTM structure choice, not an inevitable consequence. The structural fix is a unified account team that positions both offerings and lets the customer choose. With that structure in place, the account team is aligned around the customer relationship and the customer’s choice is not an internal conflict. Without it – if different sales teams own the SaaS and customer-deployed motions separately – the conflict is predictable and entirely avoidable.

A more subtle conflict can arise even with a unified account team. An ISV driving meaningful SaaS revenue through its own tenant will typically hold a committed spend arrangement with the hyperscaler – an EDP, MACC or equivalent – in order to secure the discounts that protect its own infrastructure margin and reduce the effective cost of the SaaS product to end customers. This creates a financial incentive that can distort the deployment-model recommendation: when advising a prospect who could deploy on either model, the ISV may have a commercial interest in steering them toward the SaaS platform to contribute to the ISV’s own commit drawdown, or to drive the volume that would justify a larger and more favourable commit in the next cycle. The incentive is not always visible to the customer, and it may not be visible to the ISV sales team either if it is embedded in pricing rather than named directly.

Good practice in this situation: document the rationale for deployment-model recommendations made to customers, particularly where the recommended model differs from the customer’s initial preference. Transparency about the ISV’s own hyperscaler commit, and its relevance or irrelevance to the recommendation, protects both parties if the recommendation is later questioned.

Marketplace Strategy Varies by Archetype

The marketplace plays a different role in each archetype. Three different operating models:

ISV-hosted SaaS. Marketplace is the co-sell channel. Listings, private offers and MPOs / CPPOs are origination as well as procurement – the marketplace surfaces the product to in-cloud buyers, the private-offer mechanic structures the deal and the customer’s committed spend draws down on transaction. Heavy investment in marketplace operations is justified. The marketplace strategy is the GTM strategy.

Customer-deployed. The marketplace plays two distinct roles for customer-deployed products. The first is transactional: marketplace is the procurement mechanism for committed-spend drawdown and the closing mechanic at the end of a field-led cycle. The second – frequently overlooked in SaaS-centric treatments of marketplace strategy – is the deployment mechanism: for many customer-deployed products the marketplace listing contains the deployment artefact (AMI, container image, infrastructure template) or a deployer that bootstraps the full product in the customer’s environment. For complex enterprise products that cannot be shipped as a single marketplace artefact, a lightweight deployer delivered via marketplace that then installs the full product is a common and effective pattern. Listings therefore matter significantly for both reasons – a missing or outdated listing breaks both the committed-spend drawdown mechanic and the deployment entry point. The operational investment in listing maintenance can be lighter than for SaaS ISVs overall, but marketplace is not simply a billing convenience: it is frequently the gateway through which the product enters the customer environment. The marketplace strategy supports the GTM strategy rather than constituting it, but that does not make it optional.

Hybrid. The two products (control plane and data plane, or the SaaS-mode and self-deployed-mode variants) may need different marketplace strategies and sometimes even separate listings. Resolving the marketplace strategy at the product-architecture level – rather than retroactively, after listings are live – avoids a class of expensive operational rework.

The mechanics of marketplace listings are covered in Cloud Marketplace Listings; private-offer structures in Private Offers.

What This Looks Like in Practice

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

An observability ISV with $80M ARR ran what looked like a textbook alliance function for two years: a CAM per major hyperscaler, a Technical Alliance SE, a Marketplace Operations Manager, an Alliance Marketing Lead, all reporting through the partner-side PDM relationship. Marketplace listings were current. ACE submissions were clean. Specialisation renewals happened on time. Joint webinars ran every quarter. The function produced almost no influenced pipeline.

The diagnostic moment came when the new VP of Alliances did a cohort analysis of the previous 24 months of marketplace transactions and discovered that 80% of them were renewals of pre-existing direct customer relationships routed through marketplace at the customer’s request. The function wasn’t sourcing new business; it was administratively processing existing business.

The cause was a tenancy-archetype mismatch. The product was customer-deployed – observability agents inside customer VPCs, processing customer telemetry, generating customer cloud consumption – but the alliance function was structured for ISV-hosted SaaS. The PDM relationships were warm and unproductive. The customer-side hyperscaler field teams the company actually needed to engage had never been a focus.

Year three rebuilt the function. The CAMs were re-cast as field alliance managers, with new comp structures tied to hyperscaler-field-originated pipeline rather than ACE submission volume. The VP of Alliances, who had previously reported to the CMO, now reported directly to the CRO. The team brought in a contract resource from a cloud-field-engagement services firm to seed hyperscaler field relationships in priority accounts during the rebuild. Two of the four existing CAMs left during the transition – they had been hired for partner-program work and the new role was not what they had signed up for.

By month 18 of the rebuild the function had produced $4.2M of hyperscaler-field-originated pipeline and $1.8M of marketplace transactions tied to net-new customer acquisition. The marketplace was still important, but as a closing mechanic rather than as the origination channel. The partner-program work continued in parallel at significantly lower headcount cost.

None of this trajectory is unusual for infrastructure or observability ISVs. The pattern – SaaS-style alliance function that doesn’t produce, followed by a customer-deployed-style rebuild that does – is the single most common cause of alliance-function failure in the customer-deployed population. The post you are reading exists primarily to help ISVs skip the first two years.

Common Pitfalls

  • Customer-deployed ISVs trying to copy a SaaS company’s alliance structure. Produces administrative excellence with no field traction. The composite example above is the definitive version of this pattern.
  • SaaS ISVs over-investing in field engagement when their PDM is the actual lever. The mirror image of the previous pitfall. ISV-hosted SaaS products should run the partner-side playbook; trying to build a customer-side field motion wastes the alliance function’s energy.
  • Hybrid ISVs without explicit internal handoff rules. True hybrid ISVs are rare, but when the archetype applies the absence of internal rules of engagement is a consistent failure mode. Both channels chase the same accounts and both lose. Resolve before the function scales – preferably before the first material hybrid customer signs.
  • Customer-deployed ISVs that never figure out how to articulate consumption uplift. The hyperscaler field conversations never get traction because the value-proposition story is generic. Building named-customer consumption evidence across the three tiers – Direct, Indirect and Enabled – is the gating activity. See The Consumption Multiplier.
  • Treating “build the PDM function in-house” as a junior hire. It isn’t. The role profile is closer to a senior enterprise AE than to a partner-ops manager. The wrong person will fail visibly and burn hyperscaler-field relationships in the process.
  • No coordination between GTM alliance and ISV engineering on hyperscaler relationships. For customer-deployed ISVs especially, the ISV engineering team typically has direct relationships with the hyperscaler’s product and service engineering teams that operate entirely outside the GTM alliance motion. Without a lightweight coordination agreement between the VP Alliances and the ISV’s engineering leader, the GTM team can find itself learning about hyperscaler engineering engagements from the hyperscaler rather than from their own colleagues. See Cloud Alliance Team for the coordination model.
  • Marketplace strategy treated as one-size-fits-all. ISV-hosted SaaS, customer-deployed and hybrid products each need different marketplace approaches. Designing the marketplace strategy without first resolving the tenancy archetype produces operational rework.
  • No per-hyperscaler credentials statement. The ISV has no prepared 90-second credentials statement, or has one generic version used across all three hyperscalers. Hyperscaler field teams identify the gap immediately and the conversation does not progress. Every alliance team member and ISV AE attending a hyperscaler meeting should be audible-ready with the correct version before the meeting opens. See How to Position With Hyperscaler Field Teams.
  • Presenting competitive comparison slides in hyperscaler-facing or joint-customer contexts. One of the most reliably relationship-damaging mistakes in hyperscaler GTM, and one that recurs across ISVs of all sizes. Includes the less obvious variant: presenting them to a customer who then forwards the deck or recording to the hyperscaler. See Running Hyperscaler Account Team Meetings.
  • Asking for sponsored introductions before earning trust. Requesting a CIO introduction from a hyperscaler account team you have never met, without any prior track record in the account, is asking for more than the relationship can carry. The ask backfires and costs future credibility. See How to Position With Hyperscaler Field Teams.
  • Zone-flooding. The alliance manager generates a high volume of hyperscaler account team meetings that the ISV AE attends unprepared. Each poorly-run meeting damages the ISV’s reputation with the hyperscaler field more than no meeting would have. See Running Hyperscaler Account Team Meetings.

Where to Go Next

Within this pillar:

  • Cloud Partner Programs and Specialisations – the program structures that gate co-sell access for both archetypes.
  • Cloud Alliance Team – role design, comp structures and the Co-Sell PDM-vs-field-alliance-manager split that this post drives.
  • Cloud Provider Funding – the POC credit transfer problem is a specific structural challenge for customer-deployed ISVs: partner-side credits cannot be applied to customer-environment POC costs, and the workarounds each carry their own limitations. MDF mechanics are broadly comparable across archetypes.
  • Cloud Alliances – the broader pillar this post sits under.

Per-cloud co-sell mechanics (where the AE-vs-PDM emphasis varies):

  • AWS Co-Sell – including the SaaS Co-Sell Benefit mechanism that directly bridges the two worlds for ISV-hosted SaaS partners.
  • Microsoft Co-Sell – Solution Specialist and CSA engagement patterns for customer-deployed products.
  • Google Co-Sell – the explicit customer-segment-focused vs partner-segment-focused org structure at Google.

Adjacent operating mechanics:

The full series glossary is at Glossary.

External References

Vendor Primary Sources

Independent Analyst Research

  • Omdia – partner-channel research, including data on marketplace transaction patterns and the SaaS-vs-deployable mix. Note: Omdia acquired Canalys in 2023; research previously attributed to Canalys is now published under the Omdia brand.

Practitioner Models and Industry Commentary

These sources are influential within the cloud-GTM practitioner community but published from a commercial or advisory vantage point. Cited with attribution.

  • AchieveUnite – The Hyperscaler Fit practitioner taxonomy of hyperscaler partner segmentation, including the dual-PDM framing that anchors the partner-side / customer-side hyperscaler distinction in this post.
  • CONNACT – The Difference Between Direct Sales and Cloud Sales. Practitioner framing of the distinction between direct and cloud-mediated sales motions, relevant to the tenancy-archetype argument in this post. Note: the author has a professional relationship with CONNACT; see the series disclosure on the hub page.
  • Tackle – State of Cloud GTM annual report, including data on marketplace transaction patterns and the SaaS-vs-deployable mix.
  • The Ultimate Partner podcast (Vince Menzione) – episode 215 with Chelsea Berlucchi on Google Cloud co-sell directly describes the customer-segment-focused vs partner-segment-focused field-org structure at Google, which makes the structural divide unusually visible at that hyperscaler.

Last reviewed: 2026-07-01. Vendor-neutral clusters in this series are reviewed annually. Major program-related 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/.