From Groundwork to Growth: Designing for Scalability and Flexibility

The concept was simple: enabling businesses to easily create and manage multiple stores in one environment—streamlining operations and reducing time and cost. A user could define any object at the parent [organization] level, and then distributing, and sharing it seamlessly across all child stores.

My technical director used the analogy of building a city to describe our initiative. As the platform team, we were responsible for the infrastructure—the foundations, the streets, and everything that ties the city together. Our role was to enable for other teams to build their services on top of ours—the hospitals, schools, and restaurants, making it liveable.

I prefer to think of it as constructing high-rise apartments. We lay down the essentials—electrical, plumbing, airshafts—while other teams come in to build out each room: kitchens, living areas, baths, bedrooms, and more. Each unit would come with the basics, leaving room for individual customization.

I refined this analogy to not only align with our new organizational model but also to ensure it resonated with both internal stakeholders and our customers, ensuring smoother migration and stronger buy-in. With the new model, businesses could manage multiple stores as a whole from the parent level. The apartment analogy addressed our challenge of migration: moving existing customer from a store-based structure to this unified organization—like moving from a house into an apartment.

Uncovering Cross Team Dependencies

To determine the foundations we needed to build, we first identified the "rooms" each unit required and the support they needed. Replicating the features and capabilities of the store level at the organization level was crucial for success.

I took ownership of mapping the services and identifying the key dependencies, and together with my product manager, made strategic decisions on which services to prioritize based on business value and impact. Initial conversations with service teams provided a high-level understanding of their domains and roadmaps. Given the complexity of platform projects, we strategized which services and teams to involve early to maximize value delivery.

Leadership encouraged team autonomy by keeping us decoupled to reduce dependencies. While this granted flexibility, it also led to inconsistencies and knowledge gaps. Without domain expertise, we quickly realized we couldn’t define the necessary foundations without input from other teams.

Collaboration wasn’t easy. Teams were swamped with their own initiatives, and customer requests stretched their bandwidth. Aligning roadmaps proved difficult, especially with UK-based teams where time zones made even a single overlap a daily challenge.

Recognizing the need for a shift, I led our team in revising our approach, ensuring we balanced deep domain expertise with strategic agility. Our team developed basic knowledge of each service to lead initial planning, then engaged expert teams for quick validation. This approach helped us move forward without overloading others.

Scalability and efficiency were critical to our initiative’s success. I identified PXM (Product Experience Manager), our core PIM service, as the ideal testing ground for scalability, understanding that its complexity would push the boundaries of what we could achieve and validate our core assumptions about the system’s capabilities. The challenge lay in enabling downstream sharing of objects across stores without replicating data or duplicating integrations.

Navigating Compliance Challenges

The PXM team initially proposed an automatic, downstream, bulk-sharing approach. When a user creates an object and opts to share it, all stores within the organization would automatically receive the organization-level object and build their catalogs accordingly.

While this worked well for businesses with a top-down model—where decisions and objects are inherited without question—I quickly realized it wouldn’t meet the needs of more flexible business models. For businesses that prioritize store-level autonomy, this approach fell short.

As a Canadian, I immediately thought of Quebec’s unique jurisdictional restrictions. If a product or campaign doesn’t meet compliance requirements, it can’t appear in Quebec stores. For instance, a business running a nationwide campaign might be legally required to exclude Quebec. Under the bulk-sharing model, this level of control wasn’t possible, rendering the feature unusable for such businesses.

To ensure the success of the initiative, I led the research into diverse business models, identifying key gaps and proposing strategic shifts that would unlock scalability and alignment with customer needs. I then crafted a narrative to present to the PXM team, illustrating why a selective-sharing model was necessary. By highlighting key issues and explaining how different business models would struggle with the current approach, I was able to get the team’s buy-in. The discussion quickly shifted from defending the status quo to brainstorming solutions.

With the team aligned on the need for change, we gained confidence to propose a potential solution—a tagging system—and continue discussions with our technical team to refine and validate the approach.

Designing for Scalability

As a platform team leading a complex initiative, our technical team initially considered introducing a middle Store Group tier to handle the diverse business models and administrative needs we encountered. Since our team already owned Roles and RBAC (role-based access control), adding another tier of admins seemed like a logical next step.

The rationale was straightforward: organization admins could create objects and make them available to the stores, while store group admins could assign them selectively within their groups.

However, I had concerns. Adding more complexity to the system felt like a temporary fix rather than a scalable solution. Store groups might shift selective sharing responsibilities to another admin level, but what if a store within a group needed unique products? We’d still face the same limitations, binding businesses to rigid rules that restricted how they could use our service.

Recognizing the potential risks, I initiated a discussion with my lead staff engineer to explore innovative alternatives, ensuring we stayed aligned with our long-term vision for scalability. We started by laying out the requirements, constraints, and the ultimate goal: a flexible solution that worked across various business models. To spark ideas, we analyzed user behaviour in other services. One customer’s innovative use of our Custom Data service stood out—they were tagging shoppers for segmentation, a feature our PXM team had been considering but hadn’t yet built.

This insight was a game-changer. Inspired by their approach, I began mapping out how a tagging system could be used for selective sharing. After mocking up a few possibilities, we evaluated their feasibility. We concluded that this approach offered a simpler and more efficient solution: users could tag objects for sharing, and only stores with matching tags would receive them. Objects without tags would default to being shared with all stores.

This tagging system addressed the need for selective sharing without introducing unnecessary complexity or rigid features. It allowed us to maintain scalability and flexibility, empowering businesses to tailor the system to their unique needs.

Balancing Autonomy with Centralization

A critical feature we urgently needed was data overriding. Many business models rely on store-level autonomy, allowing stores to tailor shared objects—such as product descriptions or SEO data—to suit their unique markets and demands. However, this wasn’t part of our initial release.

Not because we underestimated its importance, but because we didn’t know how to implement it effectively. Data overriding introduces a significant challenge: stores must adjust organization-level objects, but catalog publishing can’t process these adjustments without encountering errors or conflicts for the same object with different records.

The only workaround was for stores to copy the organization-level object, create a new version, and make their changes there. But this approach was far from ideal. Creating a store-specific version meant assigning a new ID and SKU, effectively treating it as a completely different object in the system. Any changes made to the store version wouldn’t sync with the original organization-level object, defeating the purpose of centralized administration.

A Late-Night Spark

The problem of data overriding loomed over us like an elephant in the room—one we all knew existed but avoided discussing because it always led nowhere. That is, until one memorable night during our team offsite.

We had rented an Airbnb in a small town four hours outside Vancouver. I was lucky to be based in Vancouver with most of my team, but this was the first time our remote teammates were joining us in person. Late into the night—probably past midnight—we wrapped up sharing our “4Hs” (history, heroes, heartbreaks, and hopes) over wine and snacks.

The conversation drifted to Custom Data capabilities we might include in an upcoming update. As the engineers dived into a sea of technical jargon, I sat back, trying to piece it all together. From what I could gather, anything built through the Custom Data service would call Custom Data’s endpoints directly.

“Hmm… Does that mean we can bypass PXM and Catalog publishing?” I finally asked, blurting out the question that had been lingering in my mind for weeks. “If the data is routed through a different service, could that avoid conflicts with data overriding?”

The room went silent. For what felt like ten minutes (but was probably closer to ten seconds), my heart raced. Had I misunderstood the concept entirely? Was it a stupid question? Then, suddenly, the engineers started talking—excitedly. Their energy grew as they exchanged ideas, dissected possibilities, and debated integrations.

I glanced nervously at my product manager, who mirrored my anxious anticipation. Finally, someone spoke up: “Not sure yet. We’d need to check with Paragon (the PXM team), but that definitely sounds doable. Probably just a few integrations to figure out!”

Covering All Bases

While the technical challenges were crucial, we also recognized that our work had a far-reaching impact on customer experience. To ensure success, we had to prioritize the learning journey for both new and existing customers.

My concern wasn’t around onboarding new customers—we could start from the beginning. I was worried about our existing customers having to adopt this new feature which changed some fundamentals of how our system operated.

Up to this point, we didn’t provide much in-product onboarding. We relied heavily on our documentation and customer facing teams. For such an important platform change, I felt uncomfortable throwing our customers to their own measures and hope they’d figure it out themselves.

The changes we’ve made with how PXM functioned at the organization level, in particular was very concerning. We’ve created a lot of unexpected changes. The learning curve was high.

I led the discussions with our PLG (product led growth) and documentation team to design an intermediate onboarding solution that would address both new and existing customers—organization and store admins.

Leading the planning and crafting the messages, I aimed to minimized the friction and errors during the transition.

A Turning Point

Once we reached the conceptual solution, I transitioned into a more consultative role, trusting my team to drive the highly technical next steps, confident they can deliver.

But this moment marked a turning point for me. Typically, I would’ve kept quiet, not confident enough to speak up in a domain I didn’t fully understand. Yet I learned that with a team you trusted (and vice versa), we can fill the gaps for one another. I alone didn’t have all the answers—none of us did. But I brought in a perspective that was missing, and together, we unlocked new possibilities.

That night will always stay with me. Innovation doesn’t happen when I dive into designs solo, or when our teams work in silos (specific disciplines or broader service teams), but from collective strengths of the team.