Product & Design Leadership · Leeroy
At Leeroy I had two roles at once. As Product Manager, I led a white-label ordering and loyalty app used by 30 restaurant brands, from discovery to development. As UX Design Manager, I was line manager for the design team across the whole platform, and helped the designers grow into product designers who ran discovery and owned their backlog.
Restaurant brands wanted their own app, and diners wanted to get food quickly. But getting started took too long, waiting for the food was uncertain, and loyalty points went missing when diners paid at the till.
As Product Manager, I led discovery and development of the app with its cross-functional team. As UX Design Manager, I was line manager for three product designers, one in each product team, and set one design process, design critique and shared design principles, so the designers could decide well on their own and the products stayed consistent.
30 restaurant brands used the app, each with its own brand. Order value was 30% higher on average through the app and Express Check-out, and the loyalty programme increased sales by 39% on average. The designers framed the problems and owned the backlog in their teams.
Restaurant brands wanted their own app, and their guests wanted to get food quickly from a favourite place. As Product Manager, I led and did the product discovery myself, to understand what made ordering, paying, pickup and loyalty hard for diners, and what we needed to learn to make well-founded decisions about what to build.
The product discovery combined four kinds of research:
Together, they gave us the three insights that shaped the app.
Diners wanted to get food quickly from a favourite place, but had to sign up before they could see anything, and extras and allergens were hard to find.
Once the order was paid, diners didn’t know when to pick it up, or whether it was ready. So they stood and waited at the counter, or asked the staff.
Points went missing when diners paid at the till instead of in the app. Diners don’t think in channels, and missing points cost their trust.
I mapped the insights onto the mobile ordering journey, from opening the app to picking up the order and getting the points. It showed where diners got stuck, and where the biggest opportunities were.
Scroll sideways to see the whole journey.
Each pain point became an opportunity, and each opportunity was linked to what we built. The map kept the team’s backlog tied to real needs, and to the outcome we wanted: diners who order more often and come back.
From the product discovery insights, we also developed design principles for the app’s ordering and loyalty experience. The principles were based on users’ needs and gave designers and developers a shared foundation for making consistent design decisions across the whole user journey. They guided the design of the app’s flows and interactions, and became the basis of the design system, which helped keep the product experience consistent.
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
The principles were the link between what we learned and what we built. Here’s how three of the insights ran all the way through: from the principle they gave us, to the design decision, the roadmap theme, and how we would know it worked.
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.
Almost every step in the app depended on another product. Together with the designers, I mapped the user flow front stage and backstage: what the diner does, what the staff at the counter and in the kitchen do, and what the systems behind them must do. I agreed each step with the Product Manager for the POS and the kitchen display.
Scroll sideways to see the whole flow.
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.
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 hasn’t started on it.
What it includes
KPIs it should move
The app was downloaded the most when we introduced campaigns and offers in it. Ordering in the app was convenient, but what made diners download it and start using it was claiming an offer. Repeat purchases, in turn, were closely tied to the loyalty programme, which we could see when we measured loyalty through purchase card tokens.
Almost every theme depended on the POS and the kitchen display, owned by another product team with its own Product Manager. My team also built parts of the POS back office. I aligned our themes with their Product Manager, so the changes we needed were planned in their roadmap too.
And in the POS back office
Every theme pointed at the KPIs it should move, towards one outcome: diners who order more often and come back, and restaurant brands that stay.
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
Each KPI had a target, so the team knew what good looked like, and could see when a theme had done its job.
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.
The app was built on two revenue streams: subscriptions, where restaurant brands pay for their own app, and transactions on the orders paid in it. Every theme was weighed on user value, business potential and complexity, and an impact matrix made the trade-offs easy to discuss in the team and with the other product owners.
At Leeroy, I was the line manager for the design team: one designer in each cross-functional product team, working together as one design team.
While the core of the product platform was being built, the designers had typical UX/UI design responsibilities. Once the core was in place, and our products were out and used by several customers, the important work became improving them and adding new features, based on what we learned from customers and users in product discovery.
The UX/UI designers became Product Designers, taking over the Product Owner responsibilities. They ran UX discovery and framed the problem for new or improved user experiences, owned the backlog planning and prioritisation together with their product team, and delivered development-ready design for the developers to build. They worked closely with the Product Managers, who were responsible for product discovery and the roadmap themes.
I contributed to the shift. My core responsibility was to be the line manager for the designers, before and after it, and to make sure they could grow into the new role.
Each product designer was part of a cross-functional product team, and was responsible for customer and user needs, and the backlog planning and prioritisation together with the team. As their line manager, I made sure that alongside product development, they had time to keep improving the design system, and that we stuck to our design process. I also handled hiring and the other everyday responsibilities of a line manager.
Here I was also the Product Manager: discovery, roadmap and priorities
The work no single product team owned: the overall experience, and the parts shared between products.
Time for the designers to continuously improve the design system, alongside the product development.
Making sure we kept following one design process, from discovery to delivery.
Developing each designer’s craft, and supporting them in their new responsibilities for user needs and the backlog.
Regular retros, and design critique where designers showed their work early and learned from each other.
Recruiting designers, and aligning design capacity with the product managers when priorities shifted.
With more decisions made inside each product team, shared standards kept the experience connected. Instead of approving every design, I made sure the designers had what they needed to decide well on their own.
Every product team worked by the same design process, from discovery to delivery, so designers could understand each other’s work and step in for each other. In regular design critique, they saw each other’s work, kept the products consistent and learned from each other.
From the research, we developed design principles for every product together: the designers, the product teams and I. Each product had its own users and context, so each got its own principles. They gave the product designers the confidence to make decisions within their teams, without having to ask every time.
Designers brought sketches and prototypes, not finished screens, while there was still time to change direction.
Feedback began with who the design was for and what it should achieve, not with taste.
Concrete, respectful feedback that the designer could act on.
Designers from the other product teams spotted where a flow broke a pattern, or touched their product.
The products had very different users and contexts: a diner on a phone, an owner at a desk, staff at a busy till, a waiter at the table, a kitchen in the rush. Shared interaction patterns and a common UI component library gave them one consistent experience, and each product adapted them to its users. The apps were built on the native iOS and Android components, and our library added the shared patterns on top, with each restaurant brand bringing its own theme.
Here’s what the work led to. I keep what was delivered apart from the goals we steered by.
Measured by the KPIs in chapter 3. These were the goals we steered by.
restaurant brands used the white-label app, each with its own brand.
higher order value on average through the app and Express Check-out.
increased sales on average with the loyalty programme.
Product designers ran UX discovery, framed the problem for new or improved experiences, owned the backlog planning and prioritisation in their teams, and delivered development-ready design.
With the backlog owned by the product designers, the product managers could focus on product discovery and the roadmap themes.
Decisions about the experience were made inside each product team, guided by shared design principles instead of approvals.
One service blueprint, one design process and one UI component library kept the products consistent for diners, restaurant staff and owners.
Looking back, these are the things that stay with me from leading the ordering and loyalty app and the design team 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’d start with themes from day one, not move to them along the way.
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: working things out early with the other product owners and owning the whole experience, not just the screens.
Moving responsibility from product owners to product designers only worked when everyone knew who decided what. Making the split explicit, with product discovery and the roadmap themes for the product managers, and user needs and the backlog for the product designers, made it easier for the designers to step up.
As the products and the team grew, I couldn’t look at every design decision myself, and I shouldn’t have had to. Design principles for each user group, shared interaction patterns and a common UI component library let the designers decide well on their own. Leading the design team became more about setting direction and making the reasoning visible than about signing off.
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.
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. Balancing brand freedom with one product that could grow 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.
“I worked closely with Mikaela for several years. What impressed me most was her ability to lead product discovery, turn customer and user insights into product direction, and drive product development through her leadership of the design team — always with contagious passion and drive!”
