Why Aren’t We Talking About Co-Build? The Reality of Building an AWS Co-Sell Motion
The conversation around AWS partnerships has become almost exclusively about how to run the co-sell process. There is a sprawling industry dedicated to the mechanics: training on Marketplace, guides to navigating ACE, and robust platforms designed to sync your CRM with AWS and automate private offers.
These platforms are critical. You cannot scale a modern cloud go-to-market motion without them. But because the operational side of co-sell is so visible, it dominates the focus of most Alliance teams.
Meanwhile, co-build is barely discussed. I see it as an underserved, core building block of the partnership. In fact, if you want your co-sell motion to grow and succeed, co-build is the key to giving it a fighting chance.
When I joined Cloudsoft nearly two years ago, I had sold software before and watched deals go through the AWS Marketplace. But the underlying machinery of “co-sell”, and the intricate ecosystem of partnerships driving it, was entirely new territory. As I immersed myself in this world, that imbalance was the first thing I noticed.
Co-sell starts with the ISV
There is a persistent assumption in the ecosystem that if you simply get your Marketplace listing right and maintain clean ACE data, AWS sellers will naturally start bringing you into their accounts.
In reality, the motion almost always starts the other way around. The ISV has to do the early heavy lifting. You have to originate the opportunities, bring AWS into your deals, and build a track record of shared success.
Why take on that burden? Because with any channel, you have to prove your value proposition and build a compelling story of why it makes sense to go to market together. A successful, bi-directional AWS partnership can be unbelievably powerful, giving you access to one of the largest enterprise selling channels in the world. But it is a motion that takes time to get the gears turning. You have to build that ecosystem recognition before AWS reciprocates.
Operational platforms give you the infrastructure to scale. But you earn the right to AWS’s active support on those deals through the product.
Co-build means solving a shared customer problem in your product
For me, co-build starts with one question: what problem do we and AWS solve together for the customers we share? Co-build is building the answer into your product, so it works with AWS services to do something for the customer that neither of you could do as well alone.
For a security vendor, that might mean sending findings into Security Hub alongside AWS’s own, and acting on them from your product. For an observability vendor, it might mean picking up CloudWatch metrics and Config changes automatically, with no pipeline for the customer to build. Increasingly, it means building AI features on Bedrock or AgentCore so they work with the AWS services the customer already uses.
It doesn’t always need an AWS service team behind it. A lot of this you can build yourself. Done well, the customer buys through Marketplace and it works the same day, without their engineers writing glue code. That’s the difference between a product that simply runs on AWS and one that feels like it belongs there.
Why co-build earns an AWS seller’s attention
When a customer gets that frictionless experience, they deploy wider and inevitably consume more underlying AWS compute, storage and, crucially for AWS right now, native AI services. When you bring an AWS seller into an account and can point to the specific infrastructure consumption your product is driving, you are actively helping them retire their quota.
But the value of that engineering work goes far beyond the individual seller. Building a compelling “better together” story backed by undeniable product truth is what unlocks the rest of the AWS machinery. It gives you the narrative you need to lean into co-marketing. It builds visibility with AWS partner teams and leadership, giving them a tangible reason to put their institutional weight behind you and help drive the motion forward.
A “better together” story shouldn’t just describe the engineering work; it must describe how those products work seamlessly together to drive real customer value.
If nothing has been built behind the story to deliver that value, it is just positioning.
AWS keeps shipping, so co-build is never finished
Even when you achieve this, the work doesn’t stay done. AWS ships new capabilities relentlessly. An integration that was a strong story two years ago might now sit awkwardly next to a new AWS native service doing part of the same job.
Plenty of partners have navigated this. Elastic competes directly with Amazon OpenSearch Service, yet they signed a strategic collaboration agreement with AWS in 2023, followed by a deeper five-year agreement in 2025.
In fact, if you look at the partners who have been the most phenomenally successful in the AWS ecosystem (the ones who have scaled to hundreds of millions in Marketplace throughput), they all share one trait. They didn’t just invest in sales operations; they invested heavily, and continuously, in co-build. The partners who survive and thrive are ruthlessly clear about where their product genuinely outperforms, and they keep building alongside AWS everywhere else.
Shipping a single integration is not going to magically turn the co-sell wheel overnight. It is a long-term investment. It requires you to treat each new phase of your partnership like day one, continuously looking at your shared users and asking: What should we build first to give customers a seamless, out-of-the-box experience on AWS?
Why co-build loses the roadmap debate
I speak to many partners who agree with this completely. They want to co-build, but they struggle to get it done.
Often, I observe a classic chicken-and-egg tension: there is a natural temptation for partners to wait for co-sell traction and pipeline value before they commit to further engineering investment.
But even when a partner is ready to invest, the barrier isn’t a lack of vision; it is internal misalignment. Alliance teams are responsible for making the AWS channel work, but they rarely own the engineering roadmap. Engineering is booked on core product launches. And Product, quite reasonably, wants to know why building specifically for AWS deserves prioritisation over features their users are actively requesting.
Winning it takes Product metrics and an executive sponsor
To break this stalemate, Alliance teams have to change how they pitch co-build internally. If you pitch it as something the partnership needs, it will keep losing to things customers are asking for.
You have to translate that engineering work into the metrics Product cares about. When you can demonstrate that making your product native to AWS measurably reduces customer onboarding time (accelerating time-to-value, protecting net retention and unlocking committed AWS budgets), the conversation shifts.
But even with the right metrics, an Alliance Manager rarely wins a roadmap debate alone. It also requires executive sponsorship. If your CEO or CRO hasn’t explicitly declared the AWS channel a top corporate priority, Product will always, and rightly, prioritise immediate customer requests over ecosystem plays.
For partners just starting to navigate a co-build motion, the engineering scope can feel paralysing. But you don’t have to boil the ocean at the start. Co-build is iterative.
Finding your starting point takes rigorous honesty across your teams. Start by asking: what is the biggest point of friction for our shared customers on AWS today? Every answer to that is a co-build candidate, and it’s one Product will recognise.
How the Better Together Assessment helps you decide what to build first
Figuring out exactly which friction points to solve first and how to build a compelling “better together” story is where most partners stall. We watched partners get stuck in this internal cycle enough times that we built a way out of it.
The Cloudsoft Better Together Assessment is a short engagement, typically two to four weeks, run by our engineers. We learn your product, analyse exactly how your customers are deploying it on AWS, and work out where your architecture fits today versus where the untapped opportunities lie. We do the legwork, requiring only a handful of strategic sessions with the people who know your product, your customers, and your AWS relationship best.
At the end, you receive a prioritised set of co-build options, objectively scored on customer value, AWS alignment, and engineering effort. You walk away with a definitive recommendation for what to build first, the business case required to get your Product team on board, and an execution plan, whether you choose to build it yourselves or have us build it for you.
Cloudsoft started out deploying software into complex enterprise environments. For years, we have worked as embedded contractors to AWS service teams (something we still do today), making AWS’s own services work better out of the box. We do that exact same job from the other side of the table, working with leading ISVs to successfully build their native AWS capabilities.
Wherever you are with co-build, I recommend starting with our guide: Five Questions to Ask Before You Co-Build with AWS. It covers exactly what you need to figure out, from understanding what problem we and AWS solve together for our shared customers, to defining what we need to deliver it: people, time, funding and leadership backing.
And if you want an outside, expert-led view on how to build a credible “better together” story and a prioritised co-build plan, get in touch with us.
