The problem
Sysco grows partly by acquiring specialty foodservice businesses, such as premium protein distributors. Before acquisition, these were independent companies with their own inventory, warehouses, distribution, and customer relationships. Many ran sales on outdated systems, and some customer records were still on paper and had to be digitized.
Every acquisition creates the same need: bring the business into Sysco's digital ecosystem. The default path was a separate eCommerce build per business, which meant duplicated cost, inconsistent customer experiences, fragmented analytics, and privacy handled differently everywhere.
With four business units already ready to onboard and more expected, a per-business approach wouldn't scale.
My role
I was one of the product managers on the migration of Sysco's core eCommerce capabilities into a multi-tenant platform. I led five deliverables:
- Content managementContentstack
- Analytics and tag managementTealium
- Cookie tracking consentRegional rules
- Third-party integrationsIncluding customer support messaging
- LocalizationLokalise
For each, I defined how the capability would serve many business units instead of one. I partnered with engineering, architecture, data analytics, privacy, and the customer education and sales enablement team.
The core decision: build capabilities, not storefronts
Every capability I owned was designed to be tenant-aware from day one. A newly acquired business should inherit content, measurement, privacy, support, and language support rather than rebuild them.
The hardest tradeoff: an MVP, not a copy of Shop
Our core eCommerce product, Shop, kept gaining new features while we built the platform. The tempting goal was full parity: launch Commerce with everything Shop had. That would have meant chasing a moving target and pushing launch indefinitely.
We scoped a deliberate MVP instead: the minimum set of capabilities a business unit needs to sell online, built to be reusable. That meant cutting a lot. Global navigation and footer changes, modifications to existing components, and many features Shop customers enjoy were deferred. We prioritized the launch date and platform quality over feature completeness.
Holding the line
Stakeholders, many new to how software gets built, requested changes late in the timeline and wanted them at launch. Each request got an effort assessment showing its timeline cost. Most became "post-MVP": logged and prioritized for after launch, not rejected. This kept stakeholder trust while protecting the date.
Key decisions in my areas
-
1
Decide what's shared and what's tenant-specific.
Each business unit gets its own content stack and publishing environments. All of them draw from one library of reusable page types and components (hero, carousels, category, product catalog, and more).
-
2
One measurement layer, not many.
A standardized analytics profile and data layer covers analytics, UX research, advertising, and conversion tracking for every business unit. Data is consistent and comparable across the portfolio from day one.
-
3
Privacy that scales by region.
Cookie tracking consent follows each region's rules: opt-out by default in the US, opt-in in Canada. Customers can accept all, reject all, or set preferences by category. Mid-project, we moved from OneTrust to TrustArc, whose support model fit our business better. Because consent was built as one shared layer, the switch was simpler than reworking it per business unit.
-
4
Customer context travels with the customer.
Support conversations carry business-unit and application attributes, so an agent knows which storefront a customer came from without asking.
-
5
Localization as a platform service.
The localization foundation (Lokalise) covers interface text, backend services, and transactional emails. Business units expanding into new countries won't need one-off translation work.
Status
- Tenant content publishing
- Common analytics layer
- Regional cookie consent
- Tenant-aware support
- Localization foundation
- Tenant-scoped media access
- First business unit live in early 2027
- Four business units ready to onboard
How success will be measured
- Business units publish their own pages without engineering help.
- Time and cost to launch each new business unit drop.
- Analytics and consent are consistent across every storefront.
Results will be added after launch.
What I'd do differently
I'd build a settings control panel early: a configurator that lets the platform team turn features on or off for each business unit without developer involvement. Many late requests were really configuration needs. A self-service control layer would have let us say "yes, after launch, without a code change," and it would make onboarding each new business cheaper.