Before they could operate effectively, they needed to read documentation, research best practices, configure services across accounts and Regions, and understand how the pieces connected. Powerful individual capabilities did not automatically add up to an understandable experience.
One piece of customer feedback captured the problem particularly well:
"AWS keeps shipping their organisational structure and we suffer."
That observation raised a question that became central to my work: who was responsible for the experience between the services?
Proposing a connected experience
I proposed what we called consumer-grade enterprise UX. The ambition was to make complex infrastructure easier to operate without requiring customers to become experts in every underlying service before they could begin.
Customers would start with what they wanted to accomplish. The product would bring recommended configurations and best practices into the setup experience. Once running, they would have a connected place to group resources, understand their state, and take action.
I wrote the strategy document and shared it with management. We secured funding for a small team to build a proof of concept.
To inform the direction, I commissioned external research and spoke directly with customers at re:Invent in Las Vegas and the AWS Summit in New York. Their feedback reinforced the burden of learning and connecting the services.
The proposal developed into the Systems Manager cockpit strategy: one place to group resources, view insights, and act. I presented the work to leadership, and Andy Jassy, then CEO of AWS, approved the direction.
Approval gave us support for the strategy. Delivering it required commitments across the organization.
A shared vision still competes with seven roadmaps
The strongest objections were about resources and prioritization.
Seven product teams had existing commitments. Our connected experience required them to dedicate capacity to capabilities whose value extended beyond their individual services. We also needed to assemble a team responsible for the experience across those boundaries.
From a service team's perspective, this was a real trade-off. Work supporting a cross-service journey competed with work already planned for its own customers and roadmap.
I had to make the case in terms of both customer effort and commercial opportunity. Easier setup could shorten the path to using the underlying services. The time customers spent learning, researching, and configuring was also time before they could get value from those services.
That was the commercial rationale. It was not, by itself, evidence of a measured revenue increase.
Customer research and the setup-time opportunity helped us resolve the resource disagreement. I worked with my GM and engineering leaders to influence the seven roadmaps and secure a dedicated team focused on the connected customer experience.
The work included underlying capabilities for discovering resources, surfacing information, and connecting workflows. A coherent interface depended on those service-level decisions.
Giving the journey a team
I owned the end-to-end experience and release. Product managers, designers, and design technologists reported to me, and I partnered directly with the engineering manager.
That structure gave us a team responsible for the connected experience while we continued to work with the service teams on the capabilities it required.
The distinction mattered. A cross-product vision can be broadly supported and still lose priority whenever an individual team faces a delivery conflict. Someone needs the responsibility and capacity to keep the whole journey moving.
My role included prioritizing the roadmap, bringing in external research and consultancy support, and working through dependencies with the teams involved.
We were asking the organization to consider a different unit of progress. Shipping another feature in one service did not necessarily make the customer's overall task easier. We needed to examine whether the work helped someone set up an environment, find the relevant context, investigate an issue, or act on it.
Those activities gave us a shared direction across products with different technical models.
Releasing a foundation before the full vision
We delivered incrementally over three years.
The first release included the shell, the platform, and initial use cases such as compliance and dashboarding. This gave us a foundation and usable capabilities without waiting for every part of the broader strategy to be complete.
Further releases expanded the connected experience. Quick Setup addressed a particularly demanding part of the journey: the work customers had to do before they could start.
Previously, customers needed to research configurations and best practices themselves. Quick Setup brought that guidance into the product through recommended setups. Customers could choose what they wanted to accomplish and where to apply it, with advanced configuration available for more specialized requirements.
That decision was about how much knowledge the product should require upfront. We wanted customers to benefit from recommended practices without first having to reconstruct them from documentation.
Throughout delivery, I conducted design reviews to assess UX quality as the experience expanded. Incremental releases made the strategy deliverable, but they also required sustained attention to how each addition fitted into the whole.
Making participation easier for other teams
A connected experience can become expensive to extend if each new integration requires a separate frontend implementation and dedicated design effort.
I proposed a compositional UI approach to make it easier and faster for other teams to integrate. Shared guidelines, platform capabilities, and reusable interface elements gave teams a way to contribute without starting again each time.
This addressed the internal adoption problem alongside the customer one.
We were asking teams to participate in a shared experience. Reducing the effort of participation made that request more practical. The platform could offer a route for their capabilities to reach customers, with less duplicated frontend and design work.
Six AWS teams ultimately integrated their services.
For me, that was an important outcome of the platform decision. The work had developed beyond a single team delivering a connected interface. Other teams could extend it.
What scale required from leadership
The scope covered seven product areas and involved more than 30 teams across nine organizational units. Those numbers describe the setting, but they do not explain the difficult part.
The difficult part was aligning decisions made at different levels.
Leadership had to support the investment. Service teams had to commit capacity. The dedicated team needed a deliverable roadmap. The platform needed to make integration practical. Customers needed a useful experience before the full vision was complete.
My responsibility was to keep those decisions connected.
That required different forms of evidence and communication: research to understand the customer burden, written strategy to establish direction, prototypes to make the proposal tangible, and ongoing prioritization to turn support into delivery.
No single presentation resolved all of it. Owning the release meant staying with the work as the strategy encountered dependencies, resource constraints, and quality decisions over three years.
Where I now look for the problem
This experience shaped how I assess a fragmented product portfolio.
I look at the steps customers perform between products: the context they reconstruct, the configuration they repeat, the documentation they consult, and the decisions they must make without guidance.
Then I look at how those steps are owned internally.
If the customer's task crosses five teams but every roadmap stops at a product boundary, the gaps are unlikely to disappear through local improvements alone. The work needs an owner, capacity, and a way for teams to contribute.
At AWS, that meant a connected product strategy, a dedicated team, phased delivery, and a platform other teams could extend.
The individual services remained powerful building blocks. Our responsibility was to make it easier for customers to put them to work.