The situation
When I joined Amazon's Perimeter Protection organization, Product and Engineering were two weeks into all-day alignment sessions and still had no shared vision. In my first days I noticed the teams seemed to agree in the room, but they used different terms for the same things and left with different understandings.
Making the conversation visible
I asked our director if I could try something different. As Product described customer needs and Engineering described constraints, I sketched interface concepts live. The sketches were rough on purpose. They gave everyone the same thing to react to, and stalled discussions started moving. That became the team's working model for the rest of the project.
Research at a fast cadence
Over the next six weeks I partnered with Product and Engineering to redefine the experience, running customer sessions three times a week to test workflows, priorities and usability before anything was built. The PM and I turned those findings into the analysis we used when engineering had to cut scope to make the launch date.
Writing what engineering built from
Engineering had six weeks to build a substantial new product for AWS re:Invent 2024, and the product team was stretched across other major launches. I wrote the requirements document myself: epics, user stories and acceptance criteria. It captured the customer intent behind each feature as well as the long-term vision, and it became the shared planning tool for prioritizing and estimating work.
One language across AWS Security
Each security organization described risks, findings and recommended actions differently, so customers saw inconsistent language from product to product. I started a weekly cross-organization working group with documentation teams and designers, and worked with Principal Engineers on industry standards and expert expectations. The result was a shared set of risk definitions and terms that we recommended to senior leadership. It started a broader effort to standardize security language across AWS documentation and the console.
Designing the Amazon Q experience
With Applied Scientists, I designed the conversational experience so customers could move between the console and the AI assistant and trust that both showed the same data. Research showed people hesitated to use the assistant because they didn't know what to ask or whether to trust the answers. I designed guided conversation starters to get them going, and customers moved on to more complex questions as their confidence grew.
I also reviewed and restructured more than 100 prompt-and-response pairs, simplifying technical language and setting patterns that matched how customers actually talk to an assistant.
Holding the line in executive reviews
In the final month we had weekly reviews with several Security SVPs. Decisions were challenged and requirements shifted. Because our recommendations were grounded in customer research, we could defend the critical design decisions and push back on changes we knew would hurt customers.
Outcome
Network Security Director launched as a private preview at AWS re:Invent 2024 with its first cohort of customers. It laid the foundation for an AI-powered cloud security management experience.
Watch the re:Invent session on YouTube
