All work

Product Leadership · Design Leadership · Baemingo

Leading product development so restaurants could grow, and Baemingo could grow with them

As Product Manager at Baemingo, I was responsible for the product roadmap for the whole restaurant platform. The POS was the core: it took orders at the till, at the table, from the mobile app and from self-service, and the POS back office handled venues, menus, payments and sales follow-up. With a lot already in place and the company about to scale, I balanced three things on one roadmap: a stable platform without technical bugs, better user interfaces and flows, and new development for growth. I supported the developers and designers with roadmap priorities and sprint goals, with an extra focus on the user experience.

My role
Product Manager | Product Discovery & Development Leadership
Year
2021–2022
Teams
Developers and product designers in four development teams
Industry
Restaurant tech, B2B SaaS and fintech
Products
The POS for the till, the table, app orders and self-service, and the POS back office
Company
Baemingo
Business model
Subscriptions and payment transactions
Three tablets with Baemingo: the start screen, table service with the floor plan, and the POS at the till with an order
01

Where I started from

Baemingo already had a lot in place, and was about to enter its scale-up phase. The POS was the core of the platform, and every order went through it, wherever the guest ordered. The POS back office was where restaurants ran the business behind it. On top of that, Baemingo had a range of other products built on the POS: online ordering, self-service, table service and kitchen displays.

  • Online orderingGuests order and pay online and in the app
  • Self-serviceGuests order at a self-service kiosk
  • Table serviceWaiters take orders at the table
  • Kitchen displaysOrders shown in the kitchen, and marked ready
The coreThe POSEvery order goes through it, at the till and wherever the guest orders
For restaurant owners and managersThe POS back office
  • Venues
  • Menus
  • Payments
  • Sales follow-up
The products built on the POS platform at the time. Simplified for this case.

The challenge

The challenge in one question

How could Baemingo scale to many more restaurants, when what restaurants used every day still had technical bugs and UX debt, and every new restaurant needed help from Baemingo to get started?

As Product Manager for all products, I had to make the platform stable, improve the experience in the products restaurants already used, and keep meeting new needs for growth, all on one roadmap and with the same teams.

The opportunity

To scale, the platform had to do three things at the same time: be stable, give restaurants a better experience in what they already used, and keep meeting new needs. Needs and requests came from key customers, sales, customer success, support and the steering group.

02

Roadmap and prioritisation

I owned one roadmap for all products and user groups, aligned with the steering group. It had three tracks, so stability, the experience and new development were weighed against each other openly.

Three tracks on one roadmap

Track 1 · Stable

Make what we have stable

No technical bugs that affect the restaurants, their staff or their guests. Bugs were part of the roadmap, not something left for later.

Track 2 · Better

Pay off the UX debt

A new design system, with the adjustments each product needed, and redesigned user interfaces and flows in the products restaurants already used.

Track 3 · Growing

Meet new needs, for growth

New development prioritised on business growth: self-service where it matters to restaurants and to Baemingo, and new products that could open new markets, or tip the decision to choose the core POS.

The roadmap for all products

The roadmap covered every product we had: the POS at the till, at the table, for app orders and for self-service, and the POS back office. Each item belonged to one of the three tracks.

Scroll sideways to see the whole roadmap.

NowNextLater
All productsThe whole platform
StableBugs fixed as part of every sprintBetterA new design system
BetterDesign system adjustments per product
The POS at the tillCashiers taking orders and payments
BetterRedesigned interface and flows
GrowingTake every kind of payment at the till
The POS at the tableWaiters serving guests at their table
BetterRedesigned interface and flows
The POS for app ordersOrders from the mobile ordering app
BetterRedesigned interface and flows
The POS for self-serviceOrders from self-service
BetterRedesigned interface and flows
The POS back officeVenues, menus, payments and sales follow-up
GrowingSelf-service onboardingGrowingMenu builderBetterRedesigned interface and flows
GrowingPayment activation, with KYC explainedGrowingSales channel activation
New productsFor growth
GrowingNew products that could open new markets, or tip the decision to choose the core POS
The roadmap for every product on the platform, with each item marked by its track. Simplified for this case.

The growth themes

New development was prioritised on business growth. The themes were written in the restaurants’ own words, and each one got an impact goal for the team that owned it. The tags kept the reasons for the order visible, also when priorities changed.

Now

1“We can get started on our own”

Impact goalA new restaurant gets from sign-up to set-up on its own, without a sales meeting.

  • Business potential: High
  • Complexity: Medium
  • User value: High
2“We can build and change our menus ourselves”

Impact goalRestaurants build and change their menus themselves, without contacting support.

  • Business potential: High
  • Complexity: Medium
  • User value: High

Next

3“We get paid from our first sale”

Impact goalRestaurants activate payouts on their own, so they get paid from their first sale.

  • Business potential: High
  • Complexity: High
  • User value: High

Later

4“We can take every kind of payment at the till”

Impact goalRestaurants take cash at the counter in the same system as card and app payments.

  • Business potential: Medium
  • Complexity: Low
  • User value: Medium
The roadmap themes as the teams saw them: an impact goal for each, and tags for business potential, complexity and user value. Redrawn for this case.

Two kinds of impact goals

Every theme had to do two things: help the restaurants reach their goals, and help Baemingo grow, through more subscriptions and more sales through Baemingo’s payments.

  1. 1“We can get started on our own”A new restaurant gets from sign-up to set-up on its own, without a sales meeting.SubscriptionsMore restaurants get started on their own, without a sales meeting.
  2. 2“We can build and change our menus ourselves”Restaurants build and change their menus themselves, without contacting support.Subscriptions and payment transactionsA restaurant cannot sell until its menu is in place.
  3. 3“We get paid from our first sale”Restaurants activate payouts on their own, so they get paid from their first sale.Payment transactionsNo transaction revenue until payouts are active.
  4. 4“We can take every kind of payment at the till”Restaurants take cash at the counter in the same system as card and app payments.SubscriptionsEvery sale in the same system, so the restaurant has no reason to keep a second till.
Every theme had an impact goal for the restaurants, and a growth goal for Baemingo. Simplified for this case.

How we prioritised

Every theme was weighed on user value, business potential and complexity, with the pain points from the research in front of us. An impact matrix made the trade-offs easy to discuss with the steering group and the teams: what gives the most impact for the effort, and what is worth a bigger bet.

Impact: business potential and user value →
Quick winsHigh impact, low effort
Big betsHigh impact, high effort
Fill-insLower impact, low effort
Think twiceLower impact, high effort
1“We can get started on our own”2“We can build and change our menus ourselves”3“We get paid from our first sale”4“We can take every kind of payment at the till”
Complexity and effort →
  1. 1“We can get started on our own”
  2. 2“We can build and change our menus ourselves”
  3. 3“We get paid from our first sale”
  4. 4“We can take every kind of payment at the till”
The impact matrix we used to prioritise, with the roadmap themes placed on it. Redrawn for this case.

A prioritisation decision: getting started before getting paid

Decision
Self-service onboarding and menus first, payment activation next.
Why
A restaurant cannot sell until its menu is in place, and more restaurants getting started on their own meant more subscriptions.
What it meant for the teams
Payment activation, the bigger bet with high complexity, followed in the next phase, building on the onboarding guide.

A trade-off: new value and technical debt

User and business need
New themes for growth: more restaurants on the platform, and more sales through Baemingo’s payments.
Technical reality
Bugs left from earlier development affected the experience, and competed with the new themes for the same teams.
Decision
Bugs became part of the roadmap, weighed openly against user and business value, so new development never came at the cost of the experience.

Targets per KPI

Each theme had KPIs with a target, so the teams knew what good looked like, and could see when a theme had done its job.

Stability and experience

Open critical bugsBugs that affect restaurants, staff or guests, still open0
Support contacts per restaurantChange in support contacts per restaurant and month−30%
Task success in user testsShare of test users who complete the task without help≥ 90%

Getting started

Restaurants that set up on their ownShare of new restaurants that get from sign-up to set-up without a sales meeting≥ 70%
Time to first saleDays from sign-up to the first sale at the till< 7 days

Menus

Menu changes without supportShare of menu changes made by the restaurant itself≥ 90%
Support contacts about menusChange in support contacts about menus and sales channels−50%

Payments

Payouts active before the first saleShare of new restaurants with payouts active when they start selling≥ 90%
KYC approved the first timeShare of KYC applications approved without being sent back≥ 80%
Sales through Baemingo’s paymentsShare of a restaurant’s sales, cash included, taken in Baemingo≥ 90%

Growth for Baemingo

New restaurantsGrowth in restaurants that start using the platform, month on month+10% per month
Products used per restaurantHow many of the platform’s products each restaurant uses3
Restaurants that stayShare of restaurants that keep their subscription each year≥ 90%
The KPIs for the roadmap themes and for Baemingo’s growth, with the target for each. Simplified for this case.
03

Understanding the users

As Product Manager, I drove product discovery to understand the needs and pain points of the restaurants and their staff, so that we decided what to build from real needs, not only the loudest request. The discovery combined three sources:

  1. Research with key customers and usersWith restaurant owners and their staff, to uncover needs, challenges and pain points.
  2. Sales, customer success and supportThe teams closest to the restaurants, and their view of where restaurants got stuck.
  3. User testsNew solutions validated with users and customers early, before the teams built them.

An example from self-service: three insights

Insight 1

Restaurants couldn’t get started on their own

To try the platform, a restaurant had to book a sales meeting, and then wait for Baemingo’s internal teams to set up the account.

Insight 2

Menus and sales channels were hard to get right

Getting a large range into the system was slow, and owners didn’t understand how menus and sales channels connected, so they asked support.

Insight 3

Getting paid was a black box

Owners didn’t understand why KYC was needed, or what was left before they could sell and get paid.

Where restaurants got stuck

The journey map follows a new restaurant from sign-up to its first sale, as onboarding worked before. It made the pain points visible to the steering group and the teams, and showed where self-service could make the biggest difference.

Scroll sideways to see the whole journey.

Sign upSet up the accountAdd productsBuild menusActivate paymentsStart selling
Experience
GoalTry the platform and see if it fitsGet the business details in placeGet the whole range into the systemShow the right menu in each channelGet paid for what is soldTake the first orders
DoingBooks a sales meeting to get accessWaits for Baemingo to set up the accountAdds products one by one, or asks for helpAsks support how menus and channels connectSends documents, waits for approvalAsks support to activate a sales channel
Pain pointsCannot try before committingDepends on internal teamsSlow with a large rangeUnclear structureUnclear why KYC is neededDoes not know what is left
OpportunitiesSelf-service sign-upGuided onboarding on the dashboardImport productsBuild menus from existing productsExplain KYC and its statusShow every step and what is done
Design principle1 · Self-service first2 · Always show what’s next1 · Self-service first3 · Confidence before going live2 · Always show what’s next2 · Always show what’s next
A simplified version of the customer journey map, redrawn for this case.

From pain points to opportunities

Each pain point became an opportunity, and each opportunity was linked to what we built and to the outcome we wanted: restaurants that grow with the platform.

OutcomeRestaurants grow with the platformBusiness direction: growth through self-service, with less need for sales meetings and support
Customer and user needs from research with key customers, sales, customer success and support
  1. OpportunityGet started without waiting for usWhat we builtSelf-service onboarding
  2. OpportunityGet the menu right in every sales channelWhat we builtMenu builder
  3. OpportunityGet paid from the first saleWhat we builtPayment activation, with KYC explained
  4. OpportunitySell in more channelsWhat we builtSales channel activation
  5. OpportunityTake every kind of payment at the tillWhat we builtPay with cash
A simplified version of the opportunity map, redrawn for this case.
04

Shaping the experience

The platform had many products, each for its own users: staff at the till, waiters at the table, restaurant owners in the back office and diners in the app. Over time, the experience had built up UX debt. The product designers designed the products and owned the design system. My part was to give the experience room on the roadmap, and make sure we followed our design process from discovery to tested solutions.

Paying off the UX debt

  1. A new design systemA shared foundation for all products, so every team designed and built from the same components and patterns.
  2. Adjustments per productThe design system adapted to each product’s users and context: the till, the table, the app and the back office.
  3. Redesigned interfaces and flowsThe product designers redesigned the user interfaces and flows where the experience held restaurants back.
  4. Tested with usersNew flows were tested with users and customers before the teams built them.

The products and their design principles

Every product got design principles from its users’ needs, written so they could be used to test a design, not only to describe it.

  1. 1DiscoverUnderstand the needs and pain points of users and customers.
  2. 2DefineFrame the right problem to solve.
  3. 3IdeateExplore several solutions together with the team, before choosing one.
  4. 4PrototypeMake the ideas tangible as flows and clickable prototypes.
  5. 5TestTest with users and customers early, and learn before anything is built.
  6. 6Deliver and improveDevelopment-ready UI, followed up after release.
The design process the product designers followed.

The POS at the tillfor the cashier taking orders and payments

Three screens of the Baemingo POS for counter service: the article grid with categories and the order, the choice of payment method, and a completed cash payment
Counter service at the till: articles in colour-coded groups, the order on the right, and payment by card, Swish or cash.

Design principles

  1. 1Never slow down the queueEvery tap during the rush has to earn its place.AskCan a new cashier take an order and a payment without help?
  2. 2Glanceable, not readableStaff should understand the order in a glance, without reading.AskCan staff see what is in the order and what is left to pay in a second?
  3. 3Forgiving under pressureMistakes happen when it is busy, so they must be easy to fix.AskCan a wrong item or payment be undone without calling a manager?

Table servicefor the waiter serving guests at their table

Two screens of the POS for table service: the floor plan with tables and their status, and a table with its bill
Table service: the floor plan room by room, and the bill for each table, with notes, courses and splitting.

Design principles

  1. 1Eyes on the guestsThe screen supports the waiter, and never takes attention from the guests.AskCan the waiter take an order while still talking to the table?
  2. 2Every table tells its storyAnyone should be able to pick up a table and know where it stands.AskCan a colleague take over a table without asking?
  3. 3Follow the guests’ wayThe system adapts to how the guests want to order and pay, not the other way round.AskCan the guests split and pay the way they want, without the waiter working around the system?

The ordering app, white labelfor diners ordering and paying from their phone

Five screens of the white-label ordering app as a template: start page, menu, item details, cart and the order status Ready for pickup
A white-label template that each restaurant brand makes its own: start page, menu, item, cart and order status.

Design principles

  1. 1The brand comes firstThe app is the restaurant’s, not ours.AskWould a diner recognise their favourite restaurant at first sight?
  2. 2Hungry people have no patienceEvery step should bring the diner closer to the food.AskCan a first-time diner order and pay within a minute?
  3. 3No surprisesThe diner always knows what they pay, and when the food is ready.AskDoes the diner ever have to ask the staff about the price or the order?

The back officefor restaurant owners setting up menus, products and payments

Three screens of the Baemingo back office: the article list grouped by category, the same list filtered on two categories, and the menu for creating articles, categories, menus, ingredients, course types, messages, upsell groups and offers
The back office: articles grouped by category, a filtered list, and one menu for creating everything a restaurant sells.

Design principles

  1. 1Self-service firstIf the restaurant has to call support, the design has not done its job.AskCan a new restaurant get through this on its own?
  2. 2Always show what’s nextThe owner should never wonder what is left to do.AskCan the owner tell what is done and what is left, without help?
  3. 3Confidence before going liveOwners should see the result as their customers will, before it is published.AskDoes the owner know exactly what customers will see?

Example: how a design principle works

Product design principle

Always show what’s next

  1. 1User insightRestaurant owners struggle to understand what remains before their restaurant is ready to go live.
  2. 2Experience principleUsers should always understand their progress, what remains and what action to take next.
  3. 3Design evaluation questionCan the owner tell what’s done and what’s left, without help?
  4. 4Design implicationsVisible progress indicators, clear task statuses and contextual next steps.

From insight to product direction

The design principles were the link between what we learned and what we built. Here is how three of the insights from the back office ran all the way through: from the principle they gave us, to the design decision, the roadmap theme and its impact goal.

  1. Discovery insightRestaurants couldn’t try the platform, or get started without a sales meeting and help from internal teams.
  2. Design principleSelf-service first
  3. Design decisionSelf-service sign-up and a guided onboarding on the dashboard.
  4. Product direction“We can get started on our own”
  5. Impact goalA new restaurant gets from sign-up to set-up on its own, without a sales meeting.
  1. Discovery insightOwners didn’t understand how menus and sales channels connected, and asked support.
  2. Design principleConfidence before going live
  3. Design decisionA menu builder with a live preview of the ordering app.
  4. Product direction“We can build and change our menus ourselves”
  5. Impact goalRestaurants build and change their menus themselves, without contacting support.
  1. Discovery insightOwners didn’t understand why KYC was needed, or what was left before they could get paid.
  2. Design principleAlways show what’s next
  3. Design decisionThe guide explains KYC, and shows the status of the application.
  4. Product direction“We get paid from our first sale”
  5. Impact goalRestaurants activate payouts on their own, so they get paid from their first sale.
Three insights from the back office, followed from discovery to the impact goal on the roadmap. Simplified for this case.
05

Leading product development

My teams were developers and product designers, in four development teams. I owned the backlogs, and supported the teams with roadmap priorities and sprint goal planning, with an extra focus on the user experience of each product. I helped them deliver on their sprint goals by creating clarity, removing obstacles and giving them the support they needed, and built collaboration, ownership and transparency through regular demos and knowledge sharing.

  1. 1RoadmapThemes in order of priority, each with an impact goal.
  2. 2Sprint planningPlanned the work towards the goal, together with each team.
  3. 3DemoThe teams got feedback on their work from colleagues.
  4. 4RetrosLooked back on how we worked, and improved it.

Using impact goals and design principles to empower teams

Instead of a detailed task“Build a form for the KYC documents”The team delivers what it is told.What the team is told to build
  1. Add a form with a field for each document
  2. Add an upload button and a submit button
  3. Send the files to the payment provider
  4. Done when the form is live
An impact goal the team ownsRestaurants activate payouts on their ownThe team decides how to get there, and knows why it matters.What the restaurant wants to accomplish
  • “Get paid for what we sell, from the first sale”
  • “Understand what is asked of us, and why”
  • “Know where our application stands”
  • “Do it on our own, without calling support”
Guided by the back office design principlesSelf-service first · Always show what’s next
Our planning rhythm, and an example of the shift from tasks to impact goals.

Dependencies across the platform

Most themes touched several products, and some depended on partners outside Baemingo. Owning the roadmap for all products let me sequence the themes across the four teams, so each team knew what it depended on.

  1. 1“We can get started on our own”Back office: sign-up and the onboarding guide · Account and company data
  2. 2“We can build and change our menus ourselves”Back office: products and the menu builder · Product catalogue · Menus in the POS, the kiosk, the app and online ordering
  3. 3“We get paid from our first sale”Back office: payments · The payment provider and its KYC approval
  4. 4“We can take every kind of payment at the till”The POS at the till · Payments
Most themes touched several products, and some depended on partners outside Baemingo. Simplified for this case.
06

Outcomes and learnings

Here is what the work led to. I keep what was delivered apart from the goals we steered by.

Achieved

What was delivered

  • A new design system, adjusted for each product, and redesigned user interfaces and flows.
  • Bugs handled as part of the roadmap, for a more stable platform.
  • Self-service sign-up and a guided onboarding on the dashboard.
  • A menu builder with a live preview of the ordering app.
  • Payment activation, with KYC explained and the status of the application.
  • Sales channel activation, and paying with cash at the till.
  • Testable design principles for every product, used to design and test the solutions.
  • One roadmap for all products, with an impact goal for every theme and a shared planning rhythm for four teams.
Intended

What we aimed to move

  • A stable platform, without critical bugs
  • More restaurants that get started on their own
  • More of the restaurants’ sales through Baemingo’s payments
  • Restaurants that use more of the platform, and stay

Measured by the KPIs in chapter 3. These were the goals we steered by.

Learnings

Looking back, four things stay with me from leading product development at Baemingo.

1

Impact goals build ownership

When the teams got impact goals instead of detailed tasks, the conversations changed. They asked why something mattered for the restaurants, found better solutions than the task would have described, and owned the result. Next time, I would write every roadmap theme as an impact goal from day one.

2

Protect time for the design process

Under delivery pressure, discovery, testing and improving the design system are the first things to be cut. Making room for them in the sprints kept the quality up, and saved us from building the same thing twice.

3

New value and technical debt share one roadmap

Bugs left from earlier development competed with the new themes for the same teams. Treating them as part of the roadmap, and weighing them openly against user and business value, made the trade-offs honest and easier to explain to the steering group.

4

Self-service changes the whole service

Moving onboarding to self-service was not only a feature. It changed the work of sales, customer success and support. Involving them early gave us the best insight into the bottlenecks, and made the change something they wanted too.

My hands-on product design at Baemingo

Separately, I took an active role as product designer for part of the improvements to the back office. In these cases, I conducted the product discovery, designed the user flows and the interface, tested with users and delivered development-ready design.

UX/UI Design · BaemingoLog in, get onboarded and start sellingThe self-service onboarding, from creating an account to the first sale at the till.See the case UX/UI Design · BaemingoLetting restaurants build the ordering menu their customers seeThe menu builder: version 1, the user test, and version 2.See the case