What's Your Superpower? Product Marketing's Real Job in Sales Enablement

In 2019 we were preparing for an AWS sales kickoff at Rackspace, and the assignment sounded simple. Tell AWS sellers what we do.

It's the wrong assignment, and the AWS MSP Program team had already handed partners a better one. They asked what our superpowers were. The things we did so well that customers described them back to us without being prompted.

The purpose of that exercise is narrower than a positioning workshop, and more useful. You're trying to put your differentiation in front of AWS sellers in a form short enough to stick, so that when a customer describes a problem in their own words, the seller recognizes it as something your superpowers solve and connects the need to you.

That connection happens in a room you're not in. An AWS account executive is sitting with a customer, and the customer mentions a legacy database, a compliance audit, a stalled migration. One of two things follows. The seller thinks of your company, or they don't. Everything product marketing produces for a partner motion is in service of that half-second.

It's a different job than most sales enablement is built for, and the difference is worth naming.

A superpower has a bar to clear

AWS put a working definition in print. Writing on the APN Blog in 2020, Principal Partner Solutions Architect Adrian SanMiguel described a superpower as something you do exceptionally well, as reported by your customers, and that you keep improving on. He noted the term came out of the MSP Program team's re:Invent sessions, and that a partner's product marketing manager is the person who helps crystallize that message for the market.

Adrian was one of the AWS people I worked with during my time at Rackspace, which is part of why the framing stuck with me. It wasn't an abstract exercise handed down in a program guide. It came up in working sessions where we were trying to figure out how to make an enormous field organization aware of what we were actually good at.

Two tests live inside that definition, and both are unforgiving. The first is that customers define it, not you. A capability you believe is differentiated but that no customer has ever named back to you is a capability, not a superpower.

The second is iteration. SanMiguel's example is the one I still use: having twenty thousand customers running SAP isn't a superpower if running SAP is just a thing you do. It becomes one when you keep going, tuning SAP environments for measurable satisfaction, then translating that into money customers actually save, then extending into end-to-end management across Hybris, SAP, and HANA. Scale is a fact about your business. A superpower is a trajectory, and that description mapped closely to what we'd been building at Rackspace.

The math is why the framing has to be crisp

Getting this right isn't message hygiene. It's the difference between a handful of referrals and an order-of-magnitude change in the opportunities that find you.

Start with the size of the audience. AWS has never published a headcount for its field organization, but The Information reported in December 2023 that the sales, marketing and global services group numbered more than 60,000 people. That figure covers solutions architects, professional services, customer success, partner and channel teams, marketing, operations, and management, not just quota-carrying sellers. Narrow it to the account executives and account managers who directly own customer relationships and revenue and a reasonable estimate lands around a third of that.

You're not going to meet them. Neither is your alliances team, and neither is your Partner Development Manager, whose coverage is finite and whose priorities move with AWS's. Add normal turnover in a field organization that size and the sellers you did train are steadily replaced by sellers who've never heard of you. Any strategy that depends on human-to-human enablement reaching a meaningful share of that population is arithmetic that doesn't work.

What scales instead is the framing itself. A superpower stated crisply enough travels through channels you don't control. A colleague's offhand recommendation. A partner page someone skims before a customer call. A slide a rep kept from a kickoff two years ago. A capabilities overview doesn't travel, because nothing in it is compact enough to repeat. Sharpening four statements costs the same whether it reaches fifty sellers or five thousand, and the return scales with how easy you made it to repeat you.

One message at three altitudes

What we built for that SKO ended up as a system rather than a slide, with three layers, each one built for a different moment in an AWS seller's week.

The live session ran under the title "Driven by Customer Success." The organizing choice is the part I'd repeat anywhere. We wrote the four superpowers as customer challenges, not service lines. Run Windows workloads on AWS. Maintain a secure and compliant environment. Manage applications and data on AWS. Application modernization and datacenter transformation. Each one is phrased the way a customer would raise it, so an AWS seller hears the trigger in the customer's own language instead of having to translate our capabilities into their situation.

Each superpower carried a real win behind it in a consistent three-part shape: customer challenges, the solution delivered, and the payoff for AWS. A fast food company deploying an SAP Hybris ordering platform needed PCI compliance and the capacity to process millions of orders an hour, with an incumbent MSP that was struggling. We took over managed AWS services, Hybris operations monitoring, and managed security, and the account moved into negotiations on a multi-year Enterprise Discount Program agreement. The others followed the same shape and ended the same way, in an AWS outcome. A Sitecore quickstart that pulled a workload the market assumed belonged on another cloud. A VMware platform scheduled for replication into EMEA and ANZ.

The leave-behind was two pages, because nobody retains a forty-slide deck from a sales kickoff.

We weren't the only partner presenting that week either. Any given rep hears from a steady stream of consulting partners and ISVs, all convinced their differentiation is the memorable one. What wins that competition isn't volume, it's portability. Battlecard format, built to be carried rather than read. Two pages a rep can print and keep in a folder, or pull up between meetings and forward to a colleague without having to explain it first. An asset that can't move through a field organization on its own will never reach the people you never met.

It compressed the same four superpowers into scannable blocks, and it did three things most partner one-pagers skip.

It gave sellers a line to say out loud.

It named the next step, with regional Strategic Alliance Managers listed by territory and a plain statement that those people existed to help sellers close active pipeline. Awareness without a routing path decays.

And it carried the proof stack. Competencies across Migration, DevOps, Oracle, Storage, Microsoft Workloads, Marketing and Commerce. Premier Consulting Partner. MAP partner. Audited MSP. Gartner MQ leader. Credentials don't create referrals on their own, but they lower the risk a seller takes when putting a partner in front of their customer.

The deep collateral was the third altitude, a full customer-facing piece per superpower, built so a seller could forward something after the meeting that didn't need a translation layer. The Application and Data Management version opened with the trust signals, moved through the end-to-end approach, and named specific platforms like Oracle, SAP, Sitecore, and Redshift. Specific enough that a customer reading it recognizes their own stack on the page.

Same message, three altitudes, each engineered for a different moment.

The standard toolkit stops at your own front door

Pull up a senior product marketing role focused on sales enablement and the responsibilities are remarkably consistent. A representative posting I looked at recently asks for scalable enablement resources and collateral, including pitch decks, one-pagers, battlecards, case studies, solution briefs, FAQs, and objection-handling guides. Onboarding and ongoing training for revenue teams. Partnering with sales leadership to find gaps. Competitive research. Translating technical concepts into customer-friendly messaging.

That list is correct. It's also entirely inward-facing. Sales, customer success, account management. No mention of co-sell, alliance managers, hyperscaler field sellers, or partner ecosystems anywhere in the role, in a market where a large and growing share of cloud revenue is influenced by exactly those people.

The discipline's job specs haven't caught up to how the revenue actually moves.

The gap isn't only a missing audience. Partner enablement adds a translation hop that internal enablement never has to make.

Internally you translate a technical concept into customer language and hand it to a rep who already knows your product, sits in your pipeline reviews, and can ask you a follow-up question on Slack. For a partner motion you translate the technical concept into customer language, then translate that into a phrase an AWS seller can recognize when a customer says something adjacent to it, in a meeting you'll never attend, months after the one session they sat through about you.

Same discipline, different constraint

None of this makes internal enablement the lesser craft. It makes the constraints worth putting side by side.

Erin Stephan wrote a piece for Product Marketing Alliance this year on building enablement for her own field team, and it's a good model of the internal version done well. She started by meeting sales leaders to find where conversations were stalling before designing anything, which is the right instinct: start with the field, not the framework. Then she built a weekly cadence covering one topic at a time, with each update explaining what the thing was, why it mattered in a customer conversation, and the talking points to use.

Look at what an internal program gets to assume. A weekly touchpoint. Reps who will ask questions. The chance to notice a message landing badly and correct it seven days later. A partner motion has none of that. You may get thirty minutes at a sales kickoff and thirty seconds of a seller's attention per quarter after it. Whatever you handed them has to survive on its own, in their memory, against every other partner who presented that day.

Which is why specificity isn't a stylistic preference in partner enablement. It's the whole mechanism. "We do cloud migrations" competes with two hundred other firms and triggers nothing. "We're the team for legacy SQL 2008 apps" competes with almost nobody and fires the moment a customer mentions an end-of-life database.

Where this is heading

The 2019 version of this work was co-sell enablement in its classic form. AWS has since made enablement an explicit discipline rather than a good habit.

In a 2025 AWS Marketplace post on seller success, Sierra Brand lays out enablement as one of the pillars in the characteristics of successful sellers framework, and the scope runs wider than sales. Finance needs billing and disbursements, operations needs deal structuring and Private Offers, sales needs the co-sell motion. Each function needs its own materials, which multiplies the product marketing surface area considerably.

The part I keep returning to is repeatability. Because AWS Marketplace ships new features and program updates throughout the year, the guidance is that an enablement plan has to be refreshed on a cadence rather than built once. That's AWS saying plainly that this content has a shelf life.

Anyone who's owned a battlecard library knows how that decays in practice. The assets are accurate the week they ship. Six months later the competitive landscape has moved, the program has changed, and the deck a seller pulls up is quietly wrong. The work was never conceptually hard. It was expensive, repetitive, and always the thing that got deprioritized for whatever launch was in front of you.

That economics problem is what AI actually addresses. In a 2026 APN Blog post on scaling content enablement, Jonathan Bach describes partners compressing production timelines from weeks to days through localization, summarization, tagging content so it can be found, and automating the workflow around it, with the argument that handling routine production frees teams to spend their time on differentiation.

The tooling in that post is Bedrock-centric, but the point is tool-agnostic, and it isn't really about generation speed. The product marketers getting leverage here aren't the ones writing better prompts. They're the ones who get good at delegation: defining the source of truth, specifying the output format, setting the review gate, and running a refresh as a repeatable job instead of a heroic quarterly project. The skill is scoping work well enough to hand it off, which is the same skill that separates a good manager from a good individual contributor, applied to a system instead of a person.

Look at the arc across those three AWS sources. Superpowers as a framing device in 2020. Enablement as a codified pillar of seller success in 2025. AI as the mechanism for keeping it current in 2026. The discipline didn't change. The economics of maintaining it did.

Final thoughts

Product marketing's contribution to sales enablement gets measured in artifacts, and the artifacts are the easy part. Battlecards, playbooks, objection handling, and one-pagers are all well-understood formats, and every job spec asks for them.

The harder work is deciding what goes on the card when the person reading it owes you nothing, works for someone else, and will give you one sentence worth of attention this quarter. Get that sentence right and it travels through an organization of twenty thousand sellers you'll never meet. Get it wrong and you've produced a very professional-looking document that generates nothing.

What I'd build today is what we built in 2019, with one change. Same discipline of writing superpowers as customer challenges, same three altitudes, same insistence on ending case studies at the AWS outcome. The change is treating the whole thing as a system with a maintenance schedule rather than a project that ships and ages, because the half-life on this content is shorter than it's ever been and the cost of keeping it current has finally come down far enough to make that realistic.

I'll go deeper on that last piece in a follow-up post, specifically how the delegation skill works in practice and what it changes about how a small GTM team operates.