DISCOVER PROJECT
Panago Pizza
Product Management
You can't redesign what's never been designed.
Feb 2026
— The system customers never see - and can't order without.
Scope
Requirements Discovery · UX Research · UI Design · Design System
Project Overview
Every edge case had a real consequence. A miscalculated nutrient, a misrouted price, a missing allergen - this wasn't a system that could afford to get things wrong.
Every pizza Panago has ever sold started life as a data problem. What's in it? How much of each ingredient? What does it cost in BC versus Ontario? What happens to the calorie count when a customer swaps to light cheese on a large? Before this project, nobody had a clean answer - because nobody had a system.
Product Management is Panago's first-ever internal platform for managing the complete lifecycle of every menu item - from raw ingredient to published price. It's the connective tissue between sourcing, recipes, nutrition, allergens, pricing, and menus. And unlike every other product in the suite, it had no predecessor. No legacy tool to audit, no old workflow to improve. This was zero to one, in the most literal sense.
Approach
Information Architecture
Most design projects start with "what's broken?" This one started with "what does this even need to be?"
When there's no existing system, you can't run a usability study on something that doesn't exist yet. Instead, discovery happened through workshops where business and technical requirements were mapped out from scratch. My job was to show up, ask the right questions, and turn the answers into something designable. Two topics kept everyone in the room the longest: nutrition and pricing. Not because they were complicated to talk about - but because both had so many moving parts that a single wrong assumption could create problems nobody would catch until it was too late. The challenge wasn't understanding the complexity. It was deciding how much of it the user should ever have to think about.
Process
The domains looked separate on paper. They weren't.
I worked through the system one layer at a time - starting with ingredients, moving through recipes and variants, then into pricing and menus. Each layer built on the one before it. Get ingredients wrong, and recipes break. Get recipes wrong, and nutrition breaks. Get nutrition wrong, and what the customer sees on the website is wrong. The order mattered as much as the design. The trickiest part was holding the whole map in my head while designing each individual piece. A small decision - like how a recipe handles half-pizza toppings - had ripple effects across nutritional calculations, pricing rules, and menu display. None of that complexity was visible in any one screen. It lived in the connections between them. The goal was simple, even when the work wasn't: make something this intricate feel completely obvious to the person using it.
Simplicity is earned, not assumed. The harder the system, the more the design has to work to make it disappear.
Final Design
If the user never notices your design, you did it right.
What shipped was a platform where the people who know the menu can finally own it. Ingredients, recipes, nutrition, allergens, pricing, menus - all connected, all in one place, all manageable without a technical background or an IT request. The hardest part to design wasn't any single screen. It was making sure that when someone updated an ingredient, the recipe knew. When a recipe changed, the nutrition updated. When a new pricing version was scheduled, the right stores and provinces got the right prices at the right time. All of that happens quietly, underneath. The win wasn't the interface. It was that nobody has to think about the system anymore - they just use it.
Product Images
"The best systems are the ones that feel like they don't exist." — Trisha
Impact & Learnings
The hardest thing to design is something that feels like it was never designed at all.
This was the most complex project of my career - not because of the number of screens, but because of what had to be true before any screen could exist. Designing from zero means every assumption you skip becomes a problem someone else inherits. That accountability changes how you think.
The biggest shift was learning to treat ambiguity as the actual design problem. In most projects, ambiguity is something you resolve early and move past. Here, it was the work. Every workshop, every edge case, every "what happens if" was a design decision in disguise. What I carry forward is this: the more complex the system, the simpler the experience has to feel. Not because users can't handle complexity, but because they shouldn't have to.
Reduced manual data entry
Eliminated IT dependency
