Why your AWS co-sell strategy needs a co-build strategy
Co-sell is the goal. Co-build is how you earn it.
Everyone wants AWS sellers bringing them into deals. The vendors who get there tend to start with a less glamorous question: what have we built with AWS?
If you run alliances at an infrastructure software company, you've probably done most of what's asked of you. You're registered in Partner Central. You're on AWS Marketplace. Maybe you've been through the Foundational Technical Review, and you're logging opportunities in ACE.
And still, the field is hit and miss. Some AWS sellers bring you in. Most don't, and it's hard to pin down why.
More often than not, the problem sits upstream of sales. AWS's guidance is clear that your Better Together Story comes before co-selling. In our experience, the strongest stories start with what you've built.
What AWS means by co-build
It's worth starting with AWS's own words, because "co-build" gets used loosely.
AWS's APN Software Path Partner Handbook (July 2024) splits the partnership into three parts. Co-build is building a partner's skills and offerings in the scope of AWS. For a software vendor, in practice, that means a product that runs on AWS or integrates with its services. Co-marketing is getting the partnership in front of both companies' sales teams and customers. Co-selling is AWS working with you, strategically, on a customer opportunity. It starts when you share opportunities through ACE, and AWS Marketplace is usually how the customer buys.
Co-selling means working a deal together. It doesn't mean AWS sells your product for you.
AWS is clear about the order, too. Its step-by-step guide to joining the AWS Partner Network puts creating your Better Together Story at step three, before the Foundational Technical Review, the Marketplace listing and co-selling. The story comes first. Co-selling follows.
Why the field doesn't just turn up
Registration, a Marketplace listing and a steady flow of ACE submissions all matter. None of them gives an AWS seller a reason to bring you into one of their accounts.
That reason is your Better Together Story. AWS describes it as the joint message that explains what problem gets solved, or what becomes possible, when you and AWS work together. It calls the story critical to running sales plays with the field, and its handbook says a good one answers four things:
- What problem or use case does your solution solve?
- What AWS customer outcomes have you delivered and recorded?
- How do you stand out from competitors?
- Which customer segments is it most relevant to?
AWS also asks partners to spell out the AWS consumption an opportunity will create. The handbook makes the link directly: when customers use a solution built on or integrated with AWS, they use AWS services too.
AWS also says what makes a story weak. Its co-marketing and co-selling tips call the Better Together Story the cornerstone of the partnership, and warn against one story that tries to cover every use case.
Which brings us back to building. A story can only be as strong as what's behind it. If your product doesn't do much more than run on AWS, a seller has very little to say about you.
The hard part is choosing
In our experience, partners aren't short of co-build ideas. If anything, they have too many. The AWS relationship can open up a wide range of ways to build alongside AWS, and working out which ones make sense for your product is the difficult part.
When co-build stalls, it's usually for one of three reasons: nobody's sure which AWS services matter most to their customers, or how to turn what they build into a story; the Product team is already stretched, and AWS asks like technical validation and competencies compete for the same people; or leadership hasn't been convinced of why this piece of work, and why now?
Get the choice wrong and it costs you twice. Building the wrong thing wastes engineering time and does nothing for co-sell. It also makes the next request harder to win, whether that's Alliances going to Product or you going back to AWS.
Five questions worth answering first
The partners we see doing this well start with their shared customers rather than the AWS service catalogue. Before anyone writes code, they work through five questions:
- What problem do we and AWS solve together for the customers we share?
- Which AWS services do those customers use, and where could we go deeper?
- What should we build first so customers can set it up on AWS in minutes, without custom work?
- Once it's built, what would an AWS seller say about us?
- What will it take? People, time, funding, leadership backing.
The first four questions get you most of the way to the Better Together Story AWS asks for. The last one is for your own Product team: an ask with people, time and cost attached is far easier to approve than a good idea.
Most teams find the list of options shrinks quickly once they've answered these honestly. The answers also give you a first draft of the story you'll hand to AWS sellers.
Where to start
You can work through these questions on your own. A lot of teams find it quicker with someone who's seen both sides.
That's where we come in. Our team has built for AWS service teams including Security Hub, Config and Service Catalog, and we build alongside infrastructure software vendors in security and observability. So we know what AWS looks for, and what it takes to ship it.
If you'd like a second opinion on where to start, talk to us. We'll look at your product from both sides and help you work out what's worth building alongside AWS first, and what an AWS seller could say about it once it's done.
And if budget is the blocker, partners can apply for AWS Innovation Sandbox funding towards design-win builds.
Book a call with our co-build team