AWS Code Catalyst is a fully integrated software development service, that helps customers build, manage, and deploy scalable applications from a single tool. Code Catalyst features project and task management, repository management and code conflict resolution, and customizable deploy workflows.
The service offers a complete first-party experience, while supporting its users through seamless integrations with third-party tools like Atlassian Jira and Bitbucket, GitHub, and GitLab. Built for enterprise scale workloads, Code Catalyst has tiered organizational and project management, allowing for tight security and cost controls, and offering increased efficiency through the use of custom project templates.
The need to balance the first- and third-party experiences while they're being built in parallel, not knowing what constraints and needs the third-party integrations will bring. Rapid prototyping and complex stakeholder management were necessary ingredients for success.
Designing for access management involves contextually addressing the needs of different user-types across a broad range of organizational structures, while also addressing complex technical needs for things like role-based permissions.
When building a 3rd-party integration system, the needs of every party need to be balanced. This challenge is as much business strategy as it is design or product strategy. To scale it, you need to define the strategies and guidelines to ensure it stays consistent and valuable for all parties involved..
Third-party integrations horizontally spanned the entire product. This made designing the system a more difficult process as it required collaborating with every feature-team across the product. In other words, beyond areas like project management, repository management, and CICD workflows, you also had role-based product areas and views, project templates, etc. This meant navigating a lot of technical complexity across a large number of cross-functional teams, each with their own needs and own unique challenges.
To manage this, I needed to quickly earn the trust of a large and diverse range of people. Working in this manner required me to be agile, and to rapidly iterate through versions of the design with each bit of information gained from every discussion or review. It also required me to connect stakeholders that weren't yet interfacing with each other, breaking down silo's to achieve mutually agreeable solutions and cohesive experiences.
My work on this project was as much product strategy and people/stakeholder management as it was design delivery. However, they worked symbiotically to continue driving us toward our goals.
The Access Management piece of the puzzle had different needs coming from all levels of an organization, and, organizations that might look drastically different. A smaller company might have less robust security needs so access management is less valuable, even possibly burdensome, where an enterprise might multiple levels of people involved from corporate resourcing and IT teams, to program managers, to projects managers, to the individuals doing the work. The challenge is figuring out where to put all the necessary pieces, and how they fit into the holistic experience, so that every organization is satisfied with their experience.
To solve this in a way that allowed everyone to access the marketplace, while keeping the org level of the product restricted, I opted to remove the feature from the product hierarchy entirely, putting it at the product level, above org and project levels in the architecture. Then, the experience and available actions would change based on a persons role and permissions. For smaller orgs, you could avoid the more restrictive management systems by being less restrictive in how they assigned roles.
To take this approach one step further, I guided product leadership to consider paying- vs. prospective-customer usage of the marketplace. This would be akin to a free trial model where prospective customers could explore the product prior to making their decision to purchase. Customers would have access to the marketplace to verify availability and tech specs of specific integrations prior to incurring charges, and could help them in planning for use, securing approvals for purchase, etc.
This project presented a couple of philosophical questions. The first was how deeply to integrate third-party experiences, and then, whether or not that judgement should be handled individually or consistently across the different areas of the product (project management, code management, and build/deploy).
To answer this question, we formed a working group with a team at Atlassian who was developing a set of brand guidelines for using Atlassian products as third-party integrations. Through the partnership we gained valuable insight into what the integrating products needs were, how deep they wanted the integrations to go, and what the business value of was for them. For Atlassian, they got the same from the first-party perspective.
The partnership resulted in an integration model that helped maintain third-parties unique experiences and relationship with their customers, while building trust with the platform and encouraging more cross-product integration for first- and third- parties.
Delivered a comprehensive integration management system and marketplace model in 4 months, winning approval from AWS leadership for the product to take the features to launch. After delivery of the design work, the full product was reskinned using AWS's new open source design system - Cloudscape., prior to its public launch in 2022.
Defined partnership strategies to guide cross-product integrations between competitors, informing the development of global integration-usage guidelines for Atlassian products.
