The point of co-sell was never to get AWS to sell for you. It wasn't really to grow the AWS seller's number either.

It's to get an AWS customer a better outcome than they would have got otherwise. Everything else follows from that.

Sometimes the better outcome isn't one product. It's two partners and AWS solving the problem together. When that's true, the joint route shouldn't be a nice-to-have you get round to eventually. It should be the first thing you explore.

Start With the Customer's Problem, Not Your Product

Customers' problems rarely map neatly onto one vendor's feature set. They have an outcome they need to reach, an architecture they already run, and a set of gaps that no single product closes on its own.

Security makes this obvious. No CISO wakes up wanting "an API security tool." They want confidence that nothing gets exploited in the space between what their endpoint and cloud tooling can see and what is actually happening in their environment. If closing that gap takes two vendors working together on AWS, then pitching one of those products alone is a worse answer for the customer. It doesn't matter how good the product is.

That's the test for any partnership: if the customer designed the solution themselves, would they pick this combination? If yes, you're building something real. If no, you're building a marketing campaign.

Why This Is Also How You Fix Week 31

In Week 31 I argued that most co-sell motions stall because nothing flows back to the AWS seller. A two-way pitch asks the AM to take a risk on you for very little movement on their number.

Once you start from the customer's outcome, that problem largely solves itself.

The deal gets bigger, because solving the whole problem usually means more workloads, more consumption, and a wider AWS footprint.

The risk gets smaller, because the AM isn't vouching for an unknown. They're backing an integration between a vendor the customer already trusts and one that makes that vendor more effective.

The conversation gets easier, because the AM can talk about a customer outcome rather than a partner's product.

There's a practical bonus too. The larger partner often already has an AWS alliance team, ISV Accelerate status, and AMs who know them by name, and you're filling a gap their customers keep raising. The credibility runs both ways.

I'm in the middle of building one of these motions right now. The most noticeable difference isn't the joint story. It's how quickly the AWS team engages when the conversation starts with a customer problem both partners can see, rather than a product one partner wants to push.

Where Three-Way Motions Go Wrong

Most attempts fail because the partnership comes first and the customer problem is retrofitted afterwards.

Two vendors agree to "go to market together." They produce a joint one-pager and run a co-branded webinar that forty people register for and eleven attend. Then everyone quietly goes back to their own pipeline.

Nothing was wrong with either product. The problem was that nobody could name the customer who was better off because the two of them worked together.

A third logo doesn't create a better outcome. It just adds a slide.

What Makes It Actually Work

A named customer outcome. Anchor everything on a single problem that both products solve better together on AWS. If you can't describe it in one sentence without mentioning either product, you're not ready.

Proof in a real deployment. Show at least one customer where the combination measurably improved the result compared with either product alone. Hypothetical better-together stories don't survive an AM's first question.

A clear lead partner, account by account. Decide who owns the relationship and who registers the opportunity in ACE for each target. Ambiguity here is how three-way motions turn into three-way arguments about attribution.

A simple way to buy. If the joint solution can be bought through Marketplace, as private offers or through CPPO where a channel partner is involved, the customer can draw it down against their existing AWS commit. A better outcome that is painful to procure isn't a better outcome.

Both alliance teams aligned before AWS is asked. AWS will engage once the two partners are clear on the customer story and the working model. It won't do the aligning for you.

Who to Partner With

Start from your customers' architecture, not from a list of vendors you'd like to be associated with.

What else do your best customers run alongside you? Where do they keep asking for an integration you haven't built? Which gaps do they tell you they're patching with manual work or a third tool?

The right partner is usually already sitting in your customers' environments. Your customers have effectively been doing the joint solution by hand.

Bottom Line

Co-sell exists to get AWS customers a better result. If the more complete answer to a customer's problem needs two partners and AWS working together, that's the route to pursue. The partnership isn't a growth tactic. It's the right solution. The seller incentives Week 31 described follow almost automatically from that: a bigger deal, a lower-risk introduction, and a story about the customer rather than about you.

Tip of the Week

Pick your three best customers and map every other product they run in the workflow your product touches. For each one, ask a simple question: would this customer be better off if we and that vendor worked together properly? Any vendor that comes up as a yes more than once is your first joint conversation.

One to Read: Go back to Week 31 (The Missing Co in Co-Sell) for the seller-side argument this edition builds on. Then reread Week 13 (What Strong Better Together Stories Look Like). The strongest stories there were always about the customer's outcome across a wider AWS architecture, not about a product on its own.

Thanks for reading. If you think the best answer for your customers involves another partner and you're working out how to build that properly, that's exactly the kind of conversation I enjoy. Feel free to reach out.