Produktledarskap · Designledarskap · Baemingo
Jag ledde produktutvecklingen så att restaurangerna kunde växa, och Baemingo kunde växa med dem
Som Product Manager på Baemingo ägde jag en roadmap för hela restaurangplattformen, från kassan till back office, precis när företaget skulle skala. Jag balanserade stabilitet, en bättre upplevelse och nyutveckling för tillväxt, ledde fyra utvecklingsteam med effektmål och designade viktiga flöden själv.
- Min roll
- Product Manager | Product Discovery & Development Leadership
- År
- 2021–2022
- Team
- Utvecklare i fyra utvecklingsteam, och två konsulterande produktdesigners vars arbete jag ledde
- Bransch
- Restaurangteknik, B2B SaaS och fintech
- Produkter
- Kassan (POS) för kassa, bord, appbeställningar och självservice, och kassans back office
- Företag
- Baemingo
- Affärsmodell
- Prenumerationer och betaltransaktioner
Kort version
Problemet
Baemingo stod inför att skala, men produkterna som restaurangerna använde varje dag hade buggar och UX-skuld, och varje ny restaurang behövde hjälp från Baemingo för att komma igång.
Vad jag gjorde
Som Product Manager ägde jag en roadmap för alla produkter, ledde fyra utvecklingsteam med effektmål i stället för uppgifter och ledde arbetet för två konsulterande produktdesigners. Jag drev product discovery och designade själv självservice-onboardingen och menybyggaren.
Vad det ledde till
Restauranger kunde registrera sig, komma igång, bygga sina menyer och aktivera utbetalningar på egen hand, utan säljmöte. Ett nytt designsystem och omgjorda flöden betalade av UX-skulden, och team som ägde effektmål hittade bättre lösningar än en uppgiftslista hade gett. Siffrorna i caset är målen vi styrde efter.
Där jag började
Baemingo hade redan mycket på plats, och var på väg in i sin scale-up-fas. Kassan (POS) var plattformens kärna, och varje beställning gick genom den, var gästen än beställde. I kassans back office skötte restaurangerna verksamheten bakom. Utöver det hade Baemingo en rad andra produkter byggda på kassan: onlinebeställning, självservice, bordsservering och köksskärmar.
- OnlinebeställningGäster beställer och betalar online och i appen
- SjälvserviceGäster beställer i en självservicekiosk
- BordsserveringServitörer tar beställningar vid bordet
- KöksskärmarBeställningar visas i köket, och markeras som klara
- Restauranger
- Menyer
- Betalningar
- Uppföljning av försäljning
Utmaningen
Hur kunde Baemingo skala till många fler restauranger, när det restaurangerna använde varje dag fortfarande hade tekniska buggar och UX-skuld, och varje ny restaurang behövde hjälp från Baemingo för att komma igång?
Som Product Manager för alla produkter behövde jag göra plattformen stabil, förbättra upplevelsen i produkterna restaurangerna redan använde och fortsätta möta nya behov för tillväxt, allt i en roadmap och med samma team.
Möjligheten
För att kunna skala behövde plattformen göra tre saker samtidigt: vara stabil, ge restaurangerna en bättre upplevelse i det de redan använde, och fortsätta möta nya behov. Behov och önskemål kom från nyckelkunder, sälj, customer success, support och styrgruppen.
Roadmap och prioritering
Jag ägde en roadmap för alla produkter och användargrupper, förankrad i styrgruppen. Den hade tre spår, så att stabilitet, upplevelse och ny utveckling vägdes öppet mot varandra.
Tre spår i en roadmap
Gör det vi har stabilt
Inga tekniska buggar som påverkar restaurangerna, personalen eller gästerna. Buggar var en del av roadmapen, inte något som lämnades till senare.
Betala av UX-skulden
Ett nytt designsystem, med de anpassningar varje produkt behövde, och omdesignade gränssnitt och flöden i produkterna restaurangerna redan använde.
Möt nya behov, för tillväxt
Ny utveckling prioriterad utifrån affärstillväxt: självservice där det spelar roll för restaurangerna och för Baemingo, och nya produkter som kunde öppna nya marknader, eller bli det som fick restauranger att välja kärnan, kassan.
Tillväxttemana
Ny utveckling prioriterades utifrån affärstillväxt. Temana skrevs med restaurangernas egna ord, och vart och ett fick ett effektmål för teamet som ägde det. Taggarna höll skälen till ordningen synliga, även när prioriteringarna ändrades.
Nu
1”Vi kan komma igång på egen hand”
EffektmålEn ny restaurang kommer från registrering till färdig uppsättning på egen hand, utan säljmöte.
2”Vi kan bygga och ändra våra menyer själva”
EffektmålRestaurangerna bygger och ändrar sina menyer själva, utan att kontakta support.
Nästa
3”Vi får betalt från vår första försäljning”
EffektmålRestaurangerna aktiverar utbetalningar på egen hand, så att de får betalt från första försäljningen.
Senare
4”Vi kan ta emot alla sorters betalningar i kassan”
EffektmålRestaurangerna tar emot kontanter i kassan i samma system som kort- och appbetalningar.
Roadmapen för alla produkter
Roadmapen omfattade alla produkter vi hade: kassan (POS) i kassan, vid bordet, för appbeställningar och för självservice, och kassans back office. Varje punkt hörde till ett av de tre spåren.
Scrolla i sidled för att se hela roadmapen.
Två sorters effektmål
Varje tema behövde göra två saker: hjälpa restaurangerna att nå sina mål, och hjälpa Baemingo att växa, genom fler prenumerationer och mer försäljning genom Baemingos betalningar.
- 1”Vi kan komma igång på egen hand”En ny restaurang tar sig från registrering till uppsättning på egen hand, utan säljmöte.PrenumerationerFler restauranger kommer igång på egen hand, utan säljmöte.
- 2”Vi kan bygga och ändra våra menyer själva”Restaurangerna bygger och ändrar sina menyer själva, utan att kontakta support.Prenumerationer och betaltransaktionerEn restaurang kan inte sälja förrän menyn är på plats.
- 3”Vi får betalt från vår första försäljning”Restaurangerna aktiverar utbetalningar på egen hand, så att de får betalt från sin första försäljning.BetaltransaktionerInga transaktionsintäkter förrän utbetalningarna är aktiva.
- 4”Vi kan ta emot alla sorters betalningar i kassan”Restaurangerna tar emot kontanter i kassan i samma system som kort- och appbetalningar.PrenumerationerAll försäljning i samma system, så att restaurangen inte behöver en kassa till.
Mål per KPI
Varje tema hade KPI:er med ett mål, så att teamen visste vad som var bra nog, och kunde se när ett tema hade gjort sitt jobb.
Stabilitet och upplevelse
Komma igång
Menyer
Betalningar
Tillväxt för Baemingo
Så prioriterade vi
Varje tema vägdes utifrån användarvärde, affärspotential och komplexitet, med smärtpunkterna från researchen framför oss. En effektmatris gjorde avvägningarna lätta att diskutera med styrgruppen och teamen: vad ger mest effekt för insatsen, och vad är värt en större satsning.
- 1”Vi kan komma igång på egen hand”
- 2”Vi kan bygga och ändra våra menyer själva”
- 3”Vi får betalt från vår första försäljning”
- 4”Vi kan ta emot alla sorters betalningar i kassan”
Ett prioriteringsbeslut: komma igång före att få betalt
- Beslut
- Onboarding i självservice och menyer först, aktivering av betalningar därefter.
- Varför
- En restaurang kan inte sälja förrän menyn är på plats, och fler restauranger som kom igång på egen hand innebar fler prenumerationer.
- Vad det innebar för teamen
- Aktiveringen av betalningar, den större satsningen med hög komplexitet, följde i nästa fas och byggde vidare på onboardingguiden.
En avvägning: nytt värde och teknisk skuld
- Användar- och affärsbehov
- Nya teman för tillväxt: fler restauranger på plattformen, och mer försäljning genom Baemingos betalningar.
- Tekniska förutsättningar
- Buggar från tidigare utveckling påverkade upplevelsen, och konkurrerade med de nya temana om samma team.
- Beslut
- Buggarna blev en del av roadmapen och vägdes öppet mot användar- och affärsvärde, så att ny utveckling aldrig skedde på bekostnad av upplevelsen.
Att förstå användarna
Som Product Manager ledde jag discoveryarbetet för att förstå vad restaurangerna och personalen behövde och var det skavde, så att vi bestämde vad vi skulle bygga utifrån verkliga behov, inte bara det mest högljudda önskemålet. Discoveryn kombinerade tre källor:
- Research med nyckelkunder och användareMed restaurangägare och deras personal, för att hitta behov, utmaningar och smärtpunkter.
- Sälj, customer success och supportTeamen som stod restaurangerna närmast, och deras bild av var restaurangerna fastnade.
- AnvändartesterNya lösningar validerades tidigt med användare och kunder, innan teamen byggde dem. I menybyggaren visade testet att användarna ville skapa sina produkter först och menyn sedan, och det formade version 2.
Ett exempel från självservice: tre insikter
Restaurangerna kunde inte komma igång på egen hand
För att prova plattformen behövde en restaurang boka ett säljmöte, och sedan vänta på att Baemingos interna team satte upp kontot.
Menyer och försäljningskanaler var svåra att få rätt
Det gick långsamt att få in ett stort sortiment i systemet, och ägarna förstod inte hur menyer och försäljningskanaler hängde ihop, så de frågade support.
Att få betalt var en svart låda
Ägarna förstod inte varför KYC behövdes, eller vad som återstod innan de kunde sälja och få betalt.
Där restaurangerna fastnade
Kundresekartan följer en ny restaurang från registrering till första försäljningen, så som onboardingen fungerade tidigare. Den gjorde smärtpunkterna synliga för styrgruppen och teamen, och visade var självservice kunde göra störst skillnad.
Scrolla i sidled för att se hela kundresan.
Från smärtpunkter till möjligheter
Varje smärtpunkt blev en möjlighet, och varje möjlighet kopplades till det vi byggde och till effekten vi ville nå: restauranger som växer med plattformen.
- MöjlighetKomma igång utan att vänta på ossDet vi byggdeOnboarding i självservice
- MöjlighetFå rätt meny i varje försäljningskanalDet vi byggdeMenybyggare
- MöjlighetFå betalt från första försäljningenDet vi byggdeAktivering av betalningar, med KYC förklarat
- MöjlighetSälja i fler kanalerDet vi byggdeAktivering av försäljningskanaler
- MöjlighetTa emot alla sorters betalningar i kassanDet vi byggdeBetala med kontanter
Att forma upplevelsen
Plattformen hade många produkter, var och en för sina egna användare: personalen i kassan, servitörerna vid borden, restaurangägarna i back office och gästerna i appen. Med tiden hade upplevelsen byggt upp en UX-skuld. Produktdesignerna designade produkterna och ägde designsystemet. Min del var att ge upplevelsen plats i roadmapen, och se till att vi följde vår designprocess från discovery till testade lösningar.
Att betala av UX-skulden
- Ett nytt designsystemEn gemensam grund för alla produkter, så att varje team designade och byggde från samma komponenter och mönster.
- Anpassningar per produktDesignsystemet anpassat till varje produkts användare och sammanhang: kassan, bordet, appen och back office.
- Omdesignade gränssnitt och flödenProduktdesignerna gjorde om gränssnitten och flödena där upplevelsen höll tillbaka restaurangerna.
- Testat med användareNya flöden testades med användare och kunder innan teamen byggde dem, så att vi lärde oss innan vi byggde och slapp bygga samma sak två gånger.
Produkterna och deras designprinciper
Varje produkt fick designprinciper utifrån användarnas behov, skrivna så att de kunde användas för att testa en design, inte bara beskriva den.
- 1UpptäckaFörstå användarnas och kundernas behov och smärtpunkter.
- 2DefinieraRama in rätt problem att lösa.
- 3IdégenereraUtforska flera lösningar tillsammans med teamet, innan vi väljer en.
- 4PrototypaGör idéerna konkreta som flöden och klickbara prototyper.
- 5TestaTesta tidigt med användare och kunder, och lär oss innan något byggs.
- 6Leverera och förbättraUtvecklingsklart UI som följs upp efter lansering.
Kassan (POS)för kassapersonalen som tar emot beställningar och betalningar
Designprinciper
- 1Sakta aldrig ner könVarje tryck under rusningen måste förtjäna sin plats.FrågaKan en ny kassör ta en beställning och en betalning utan hjälp?
- 2Överblick utan att läsaPersonalen ska förstå beställningen med en blick, utan att läsa.FrågaSer personalen vad som ingår i beställningen och vad som återstår att betala på en sekund?
- 3Förlåtande under pressMisstag händer när det är mycket att göra, så de måste vara lätta att rätta.FrågaKan en fel artikel eller betalning ångras utan att ringa en chef?
Bordsserveringför servitören som serverar gästerna vid bordet
Designprinciper
- 1Blicken på gästernaSkärmen stöttar servitören och tar aldrig uppmärksamheten från gästerna.FrågaKan servitören ta en beställning och samtidigt prata med bordet?
- 2Varje bord talar för sig självtVem som helst ska kunna ta över ett bord och veta var det står.FrågaKan en kollega ta över ett bord utan att fråga?
- 3Följ gästernas sättSystemet anpassar sig efter hur gästerna vill beställa och betala, inte tvärtom.FrågaKan gästerna dela och betala som de vill, utan att servitören behöver kringgå systemet?
Beställningsappen, white labelför gäster som beställer och betalar i mobilen
Designprinciper
- 1Varumärket förstAppen är restaurangens, inte vår.FrågaKänner en gäst igen sin favoritrestaurang vid första anblick?
- 2Hungriga människor har inget tålamodVarje steg ska ta gästen närmare maten.FrågaKan en förstagångsgäst beställa och betala inom en minut?
- 3Inga överraskningarGästen vet alltid vad den betalar och när maten är klar.FrågaBehöver gästen någon gång fråga personalen om priset eller beställningen?
Backofficeför restaurangägare som sätter upp menyer, produkter och betalningar
Designprinciper
- 1Självservice förstOm restaurangen behöver ringa support har designen inte gjort sitt jobb.FrågaKlarar en ny restaurang det här på egen hand?
- 2Visa alltid nästa stegÄgaren ska aldrig behöva undra vad som återstår.FrågaKan ägaren se vad som är klart och vad som återstår, utan hjälp?
- 3Trygghet innan det går liveÄgaren ska se resultatet som kunderna ser det, innan det publiceras.FrågaVet ägaren exakt vad kunderna kommer att se?
Exempel: så fungerar en designprincip
Produktdesignprincip
Visa alltid nästa steg
- 1AnvändarinsiktRestaurangägare har svårt att förstå vad som återstår innan restaurangen är redo att gå live.
- 2UpplevelseprincipAnvändarna ska alltid förstå hur långt de har kommit, vad som återstår och vad nästa steg är.
- 3Fråga för att utvärdera designenKan ägaren se vad som är klart och vad som återstår, utan hjälp?
- 4Vad det betyder för designenSynliga framstegsindikatorer, tydliga statusar för varje uppgift och nästa steg i sitt sammanhang.
Från insikt till produktens riktning
Designprinciperna var länken mellan det vi lärde oss och det vi byggde. Så här löpte tre av insikterna från back office hela vägen: från principen de gav oss, till designbeslutet, temat på roadmapen och dess effektmål.
- Insikt från discoveryRestaurangerna kunde inte prova plattformen, eller komma igång utan ett säljmöte och hjälp från interna team.
- DesignprincipSjälvservice först
- DesignbeslutRegistrering i självservice och en guidad onboarding på startsidan.
- Produktens riktning”Vi kan komma igång på egen hand”
- EffektmålEn ny restaurang tar sig från registrering till uppsättning på egen hand, utan säljmöte.
- Insikt från discoveryÄgarna förstod inte hur menyer och försäljningskanaler hängde ihop, och frågade support.
- DesignprincipTrygghet innan det går live
- DesignbeslutEn menybyggare med en live-förhandsvisning av beställningsappen.
- Produktens riktning”Vi kan bygga och ändra våra menyer själva”
- EffektmålRestaurangerna bygger och ändrar sina menyer själva, utan att kontakta support.
- Insikt från discoveryÄgarna förstod inte varför KYC behövdes, eller vad som återstod innan de kunde få betalt.
- DesignprincipVisa alltid nästa steg
- DesignbeslutGuiden förklarar KYC, och visar ansökans status.
- Produktens riktning”Vi får betalt från vår första försäljning”
- EffektmålRestaurangerna aktiverar utbetalningar på egen hand, så att de får betalt från sin första försäljning.
Att leda produktutvecklingen
Mina team bestod av utvecklare och produktdesigners, i fyra utvecklingsteam. Jag ägde backloggarna, och stöttade teamen med prioriteringar i roadmapen och planering av sprintmål, med ett extra fokus på användarupplevelsen i varje produkt. Jag hjälpte dem att nå sina sprintmål genom att göra saker tydliga, röja undan hinder och finnas där när de behövde stöd. Med regelbundna demos och kunskapsdelning blev vi bättre på att samarbeta, ta ansvar och vara öppna med hur det gick.
- 1RoadmapTeman i prioritetsordning, vart och ett med ett effektmål.
- 2SprintplaneringPlanerade arbetet mot målet, tillsammans med varje team.
- 3DemoTeamen fick feedback på sitt arbete från kollegor.
- 4RetrosSåg tillbaka på hur vi arbetade och förbättrade det.
Effektmål och designprinciper som gav teamen eget ansvar
- Lägg till ett formulär med ett fält för varje dokument
- Lägg till en uppladdningsknapp och en skicka-knapp
- Skicka filerna till betalleverantören
- Klart när formuläret är live
- ”Få betalt för det vi säljer, från första försäljningen”
- ”Förstå vad som krävs av oss, och varför”
- ”Veta hur det går med vår ansökan”
- ”Klara det själva, utan att ringa support”
Beroenden över plattformen
De flesta teman berörde flera produkter, och några var beroende av partner utanför Baemingo. Eftersom jag ägde roadmapen för alla produkter kunde jag ordna temana över de fyra teamen, så att varje team visste vad det var beroende av.
- 1”Vi kan komma igång på egen hand”Back office: registrering och onboardingguiden · Konto- och företagsuppgifter
- 2”Vi kan bygga och ändra våra menyer själva”Back office: produkter och menybyggaren · Produktkatalog · Menyer i kassan, kiosken, appen och onlinebeställning
- 3”Vi får betalt från vår första försäljning”Back office: betalningar · Betalleverantören och dess KYC-godkännande
- 4”Vi kan ta emot alla sorters betalningar i kassan”Kassan (POS) · Betalningar
Resultat och lärdomar
Så här blev det. Jag håller isär det vi levererade och de mål vi styrde mot.
Vad som levererades
- Ett nytt designsystem, anpassat för varje produkt, och omdesignade gränssnitt och flöden.
- Buggar hanterade som en del av roadmapen, för en stabilare plattform.
- Registrering i självservice och en guidad onboarding på startsidan.
- En menybyggare med en live-förhandsvisning av beställningsappen.
- Aktivering av betalningar, med KYC förklarat och ansökans status.
- Aktivering av försäljningskanaler, och kontantbetalning i kassan.
- Testbara designprinciper för varje produkt, som användes för att designa och testa lösningarna.
- En roadmap för alla produkter, med ett effektmål för varje tema och en gemensam planeringsrytm för fyra team.
Vad vi ville påverka
- En stabil plattform, utan kritiska buggar
- Fler restauranger som kommer igång på egen hand
- Mer av restaurangernas försäljning genom Baemingos betalningar
- Restauranger som använder mer av plattformen, och stannar
Mätt med KPI:erna i kapitel 3. Det här var målen vi styrde mot.
Lärdomar
När jag ser tillbaka är det fyra saker som stannar kvar från att leda produktutvecklingen på Baemingo.
Effektmål skapar ägarskap
När teamen fick effektmål i stället för detaljerade uppgifter förändrades samtalen. De frågade varför något spelade roll för restaurangerna, hittade bättre lösningar än uppgiften hade beskrivit och ägde resultatet. Nästa gång skulle jag skriva varje tema på roadmapen som ett effektmål från dag ett.
Skydda tiden för designprocessen
Under leveranspress är discovery, tester och förbättringar av designsystemet det första som stryks. Att ge dem plats i sprintarna höll uppe kvaliteten och gjorde att vi slapp bygga samma sak två gånger.
Nytt värde och teknisk skuld delar en roadmap
Buggar från tidigare utveckling konkurrerade med de nya temana om samma team. Att se dem som en del av roadmapen, och väga dem öppet mot användar- och affärsvärde, gjorde avvägningarna ärliga och lättare att förklara för styrgruppen.
Självservice förändrar hela tjänsten
Att flytta onboardingen till självservice var inte bara en funktion. Det förändrade arbetet för sälj, customer success och support. Att involvera dem tidigt gav oss de bästa insikterna om flaskhalsarna, och gjorde förändringen till något de också ville.
Min egen produktdesign på Baemingo
Vid sidan av det jobbade jag själv som produktdesigner med en del av förbättringarna i back office. I de här casen gjorde jag discoveryn, designade användarflödena och gränssnittet, testade med användare och levererade utvecklingsklar design.
