All work

Product & UX Leadership · Baemingo

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

At Baemingo, I had three roles with one goal: to enable restaurants to grow with the platform. As Product Development Lead, I was responsible for the roadmap and backlogs for all products and user groups, and planned the sprints together with the developers and the UX designers. As UX Lead, I organised customer involvement and UX discovery, to understand needs and pain points and to validate new solutions early. I also did hands-on UX/UI design for the back office for the POS, used by restaurant staff and owners.

My role
Product Development Lead for all products, UX Lead for customer involvement and UX discovery, and UX/UI designer for the back office
Year
2021–2022
Industry
Restaurant tech, B2B SaaS and fintech
Company
Baemingo
Teams
Four development teams and the UX designers, with sales, customer success and support
Platform
Web app
Tools
Figma

Three roles, one goal

Product Development Lead

The roadmap and backlogs for all products

  • Roadmap for all products and user groupsOwned the product development roadmap across the platform, aligned it with the steering group, and gave each theme an impact goal.
  • Backlogs and sprint planningOwned the backlogs, and planned the sprints together with the developers and the UX designers in four development teams.
  • Steered by impact goalsGave the teams impact goals to own instead of detailed tasks, with sprint planning and retros as our rhythm.

UX Lead

Customer involvement and UX discovery

  • Customer involvementOrganised how we involved key customers and users, together with sales, customer success and support.
  • Needs and pain pointsLed the UX discovery that gave us a deeper understanding of needs and pain points, and turned them into opportunities for the roadmap.
  • Validate earlyMade sure new solutions were validated with customers early, before the teams built them.

UX/UI designer

Hands-on design of the back office

  • The back office for the POSDesigned parts of the back office where restaurant staff and owners set up and run the POS.
  • Self-service onboardingFrom creating an account to the first sale at the till. Presented as its own case.
  • Menu builderWhere restaurants build the menu their customers see. Presented as its own case.
  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 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 principlesSelf-service first · Always show what is next
Our planning rhythm, and an example of the shift from tasks to impact goals.
01

The challenge

As Baemingo entered its scale-up phase, the platform had to grow in two ways at once: more restaurants had to get started on their own, and the restaurants already on it had to use more of it. Growth meant both more subscriptions and more sales flowing through Baemingo’s payments.

The platform had many products for different users: the POS at the till, table service, the back office, the ordering app and self-service. Four development teams worked on them, and needs and requests came from key customers, sales, customer success, support and the steering group.

The challenge was to decide what to build first across all products, and to make sure the teams built what would make the biggest difference for the restaurants and for the business. That needed:

  1. One roadmap for all productsThemes for every product and user group, in one order of priority.
  2. Decisions based on customer insightNeeds and pain points from discovery, not only the loudest request.
  3. Validation before buildingNew solutions tested with customers early, before the teams built them.
  4. Teams that own the outcomeImpact goals instead of detailed tasks.

One platform, many products and user experiences

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. The UX designers designed the products and owned the design system. My part was to make sure we followed our design process, and had time to continuously improve and update our design system.

  1. 1DiscoverUnderstand the needs and pain points of users and customers, together with sales, customer success and support.
  2. 2DefineFrame the right problem to solve, in journeys, blueprints and opportunity maps.
  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, with the design system updated as we learn.
The design process the UX 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

The back office, where restaurants set everything up, is shown in the two hands-on cases below.

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 is 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?
02

The customer journey

As an example of the discovery, 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 is next1 · Self-service first3 · Confidence before going live2 · Always show what is next2 · Always show what is next
A simplified version of the customer journey map, redrawn for this case.
03

How the business model impacts product prioritisation

Baemingo is a SaaS and fintech company with two revenue streams: subscriptions to the platform, and transactions on the payments that go through it. When we prioritised the roadmap, every theme was assessed on its business impact: would it get more restaurants started and keep them on the platform, or get more of their sales flowing through Baemingo’s payments? Business impact was then weighed together with user value and complexity, so the themes that mattered most to both the restaurants and the business came first.

SaaSSubscriptionsRestaurants pay for the platform: the POS, the back office and the ordering app.Grows with more restaurants and venues that start using the platform, and stay.
FintechPayment transactionsPayments made through the platform: in the app, at the till and in self-service.Grows with more sales flowing through Baemingo’s payments, from the first sale.

What each roadmap theme did for revenue

The business model behind the priorities, simplified for this case.

Every theme on the roadmap was then 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.
04

The roadmap

The roadmap put the themes in order, and gave each one 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.
05

Learnings

Looking back, four things stay with me from leading product development and UX 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.