The Setup
One design lead, five product pods, one coherent platform.
Lead UX across Labor, Reporting, Inventory, Sales, and Admin — five pods with their own PMs, engineers, and roadmaps. The job was to make them feel like one product, and the frameworks I built along the way became the primary deliverable.
Kept five pods shipping as one platform instead of five disconnected apps.
Each pod had its own roadmap and cadence, but customers see one product. Shared frameworks for communications, reporting, and navigation meant every new feature slotted into patterns users already understood — no matter which pod built it.
Turned cross-pod coordination from meetings into reusable infrastructure.
Instead of relitigating the same questions every sprint — where does this config live, how do we send this email, how does this report pull data — we codified the answers. Decision trees and architecture diagrams did the talking so designers could go back to designing.
The Landscape
Five pods, five vocabularies, one platform customers expected to feel unified.
Smart Manager spanned Labor, Reporting, Inventory, Sales, and Admin — each with its own product manager, engineering team, and quarterly priorities. On any given sprint, pods were introducing new settings, sending new communications, and building new reports without a shared model for how those pieces should fit together.
The result was drift. Configurations lived wherever the building pod thought made sense. Reports pulled multi-pod data using whatever shape the source team had on hand. What looked like independent feature work was quietly fragmenting the platform — and the cost was going to land on customers the moment they tried to move between pods.
Configuration hierarchy decision tree — the reference every pod used when introducing new settings.
The Mission
Give every pod a shared blueprint, then architect the features that stitched them together.
Lead design across five pods without bottlenecking any of them. Build the cross-product frameworks — communications, reporting, navigation, configuration — that let pods move fast and stay consistent. And take direct ownership of the Sales and Inventory features where pod boundaries had to dissolve entirely.
The Moves
Four bets that turned coordination into infrastructure.
Resource planning as the coordination surface
Coordinating five pods starts with knowing who's doing what. Built a quarterly resource-centric view that mapped designer allocation across every epic and pod, making capacity conflicts visible before they became blockers — and giving PMs a single place to argue about priority instead of five.
A communications architecture every pod could plug into
Defined how pod-to-pod data exchange would work across the platform. Mapped template structures, content types, and data flow patterns so any pod could send electronic communications without building a bespoke integration — and so customers would see a consistent voice across every automated message.
A reporting framework that worked across every data source
Reports pulled from Labor, Inventory, and Sales, but each pod structured data differently. Defined the anatomy of a report — view types (dashboard, hybrid, tabular), visualization elements, and layout grids — and paired it with persona-based navigation flows that preserved context as users moved between dashboard, drill-down, and saved reports.
Architecting the Sales + Inventory seam directly
Some integrations were too load-bearing to hand off. Took direct ownership of feature architecture for the Sales and Inventory pods, including the integration between Smart Manager's Recipes feature and Aloha Menu's sales items. Established modular patterns that let future pod additions slot in without architectural rework.
The Payoff
Five pods moving like one product.
The frameworks became the foundation for every subsequent cross-pod feature. Labor, Reporting, Inventory, Sales, and Admin kept their independent roadmaps while sharing a coherent configuration model, communications pattern, and reporting anatomy. Instead of negotiating integration from scratch on each release, pods shipped against a shared blueprint — and the Sales + Inventory architecture I owned directly made Recipes-to-sales-items integration a feature rather than a project.
Coordinated under one design lead
Comms, reporting, navigation
Cross-pod platform experience
Looking Back
When you can't be in every room, the frameworks have to be.
The lesson I keep coming back to: a design lead across five pods can't win by showing up harder. The wins came from building artifacts — decision trees, architecture diagrams, reporting anatomies — that did the coordinating while I was somewhere else. The frameworks became the deliverable, and that's what kept the platform coherent as every pod kept shipping.