Product Leadership · Leeroy
At Leeroy, I led the product development of the native white-label ordering and loyalty app for restaurant brands. I led product discovery with customers and users, defined how the product should work end to end and mapped out the user journey. I owned the roadmap and priorities, and built the roadmap from five themes written from the diner’s point of view, from “I can order and pay without waiting in line” to “I get offers that make me come back”. Each theme was linked to the KPIs it should move, across ordering, experience, loyalty and growth. Together with the cross-functional product development team, I turned the themes into sprint goals, and followed the KPIs to see what worked and what could be improved.
As product lead, I treated research as product discovery: deciding what we needed to learn, and using customer and user insight to choose what to build, and what not to build yet.
How the research insights were placed on the service blueprint is described in the UX design manager case.
From the research, we set design principles for the ordering and loyalty app. They gave the designers and the team a shared way to decide, in every flow of the app, without having to ask every time.
The app shared interaction patterns and a common UI component library with the other products on the platform, and each product had its own principles. How we came up with them is described in the UX design manager case.
The brand comes first: the app is the restaurant’s, not ours
Order in a few taps
Always know the status of the order
One membership in the app and at the till
Here are some of the screens from the app. It was one white-label app, released for each restaurant brand with its own logo, colours, images and menu.
1The menu
The restaurant’s categories as tabs, and each product with image, price and its price in points. The chosen restaurant is at the top, and the basket is always at hand.
2A brand’s start screen
The brand’s own image and order button, with shortcuts to ordering, offers, my orders and the nearest restaurant.
3The side menu
Everything else in one place: ordering, scanning the membership card, offers, orders and receipts, settings, restaurants and support.
4Another brand, the same app
A campaign at the top, ordering for delivery or the dine-in menu, and the member’s offers below.
5Loyalty points and levels
The member’s points and level, and how the loyalty programme works, in a sheet over the start screen.
In my own product team, I designed the user journey through one product, the ordering app: from opening the app to picking up the order and getting the points. It showed where diners got stuck, which opportunities would help them most, and became the base for the backlog and the flows the designers worked from.
Scroll sideways to see the whole journey.
The opportunities came from the customer and user insights, the service blueprint and the journey. Each pain point became an opportunity, and each opportunity was linked to what we built and to the outcome we wanted: diners who order more often and come back. The map kept the team’s backlog tied to real needs, and to the business.
Together with the designers, I defined how the ordering and loyalty app should work end to end: from the diner’s first tap, through the till and the kitchen, to the points on the membership. Almost every flow in the app depended on another product, so I agreed each step with the product owners of the POS and the kitchen display.
The user flow for online ordering in the app ran front stage and backstage: what the diner does in the app, what the staff at the counter and the kitchen do, and what the systems behind them must do, from deciding where to eat to coming back.
Scroll sideways to see the whole flow.
One order passes five parts of the system and three product teams. Because the app was integrated with the POS and the kitchen display, the order went straight to the kitchen, and the diner got a notification in the app as soon as it was ready.
The ordering app was built on two revenue streams: subscriptions, where restaurant brands pay for their own app, and transactions on the orders paid in it. That set the business side of every priority. A theme that brought in more brands, or more orders through the app, had a direct effect on revenue.
What each roadmap theme did for revenue
Every theme was then weighed on user value, business potential and complexity, with the pain points from the journey in front of us. An impact matrix made the trade-offs easy to discuss in the team and with the other product owners.
The roadmap was built from themes, not features. Each theme was written from the diner’s point of view, as an outcome they would notice. Then we broke it down into what it includes, and linked it to the KPIs it should move.
The order of the themes followed the business model and the impact matrix. Now came the core of the product: ordering and paying in the app, and knowing when the food is ready. Without orders in the app there are no transactions, and nothing to reward. Next came loyalty in the app and at the till, so that members come back and brands have a reason to stay. Later came offers that each brand sets up itself, and changes to orders, which touch the POS, the kitchen and the payment.
Themes kept the team focused on why something mattered, and left room to find the best way to get there. When priorities changed, it was easier to move a whole theme than to reshuffle single features.
Theme 1Diners
Order ahead or at the table, pay in the app, and the order goes straight to the kitchen.
What it includes
KPIs it should move
Theme 2Diners
No need to ask the staff, or to stand and wait at the counter.
What it includes
KPIs it should move
Theme 3Members
Points and rewards follow the diner, in the app and at the till.
What it includes
KPIs it should move
Theme 4Members and brands
Stamp cards and offers, set up by each restaurant brand itself.
What it includes
KPIs it should move
Theme 5Diners
Change or add to the order after it is placed, as long as the kitchen has not started on it.
What it includes
KPIs it should move
Each theme on the roadmap came with the KPIs it should move. Together with the cross-functional team, I turned the themes into sprint goals: what we wanted to be true at the end of the sprint, and why it mattered for the diners and the restaurants. The team then planned how to get there.
I measured the app by outcomes, not by what we shipped. The outcome we aimed for was diners who order more often and come back, and restaurant brands that stay. It was broken down into KPIs in four groups, and every theme on the roadmap pointed at the KPIs it should move.
Ordering, experience and loyalty show whether the app works for diners. Growth shows what that adds up to for the business: more orders paid in the app, more members, and brands that stay on the platform and keep their subscription.
That made every priority discussion concrete: which KPI will this move? And once a theme was live, the same KPIs showed whether it had worked, and what to improve next.
Moved by
Moved by
Moved by
SubscriptionsPayment transactions
Loyalty had to work wherever the diner paid. Members earned rewards for purchases in the app and at the till, and could use them in both. That is what turns a diner into a regular.
Looking back, five things stay with me from leading the ordering and loyalty app at Leeroy.
Writing the themes as something the diner would say, like “I know when my food is ready”, changed the conversations. Instead of debating features, we talked about what the diner should notice and why it mattered. When priorities shifted, we moved whole themes instead of reshuffling single features. Next time, I would start with themes from day one, not move to them along the way.
Linking each theme to the KPIs it should move made priorities concrete. The bigger learning is about timing. If we agree on the KPIs, and know where they stand today, before a theme starts, we can say afterwards whether it worked. Measuring only after launch shows what happened, but not why.
The best ordering flow in the app still fails if the order doesn’t reach the kitchen, or if nobody marks it ready. Almost every flow depended on the POS, the kitchen display or the loyalty engine. Leading the app meant leading across product teams: aligning early with the other product owners and owning the experience end to end, not just the screens.
Every decision had to work both for the restaurant brand paying for the app and for the diner using it. “The brand comes first” gave each brand its own look, while shared components and patterns kept one product we could build and maintain. That balance between brand freedom and one scalable product was a big part of the job.
Diners don’t think in channels. If points went missing when they paid at the till, they lost trust in the whole programme. Designing loyalty for wherever the diner pays, in the app and at the till, was harder and depended on more teams, but it was what turned diners into regulars.
At Leeroy, I had several responsibilities. Each one is its own case.
