At opbygge produktfunktionen hos Raffle AI

Da Raffle skiftede ledelse, tog jeg produktansvaret — en rolle, ingen havde — bragte en bevidst planlægningsproces til en hurtig, reaktiv virksomhed og byggede partnerplatformen, som en ny forhandlerkanal nu kører på.

Kontekst

Raffle AI bygger AI-drevet søgning og chat til virksomheder. Teamet er lille, og det er bevidst: to frontend-udviklere, to backend-udviklere, en data scientist, en designer, en CTO, teknisk support og mig.

I størstedelen af virksomhedens levetid blev produktretningen drevet af founderen — en stærk operatør med en salgsbaggrund, der bar virksomheden gennem de tidlige år i høj grad på sin egen energi. Den slags founder-drevet momentum er det, der holder tidlige virksomheder i live, men det skaber et særligt produktmiljø: hurtigt, dybt kundedrevet og svært at skalere. Prioriteterne skiftede kunde for kunde. Platformen havde akkumuleret teknisk gæld, flere store grundlæggende projekter var gået i stå, og mange features var engangsløsninger bygget til specifikke kunder snarere end til produktet som helhed.

Da bestyrelsen foretog et lederskifte, blev det hul til noget, jeg kunne handle på.

Hvordan det startede

Jeg foreslog det direkte til den nye CEO.

Der var ingen dedikeret til produktet, og hullet var synligt. To år inde i produktet havde givet mig dyb viden om, hvad det gjorde, og hvor det var skrøbeligt. Mellem en baggrund i produktdesign fra Politecnico di Milano, frontend-udvikling og en voksende involvering på tværs af salg og marketing var jeg tryg ved at arbejde direkte med både engineering og forretningen.

Han var enig. Produktet lå formelt under CTO'en, som var ærlig om, at det ville blive en svær rolle. Han var allerede strakt på tværs af security compliance, kundeprospekter og dybt teknisk arbejde og havde aldrig haft kapaciteten til at eje produktretningen. Han bakkede mig fuldt op fra starten, og vi har fungeret som ægte partnere hele vejen igennem.

Hvad jeg indførte

Først, fælles overblik. Jeg migrerede backloggen fra et rodet ClickUp til Linear og ryddede op og omstrukturerede den undervejs. Før nogen kunne blive enige om prioriteter, havde alle brug for at se det samme billede af, hvad der eksisterede, og hvad der var i gang.

Derefter, en planlægningsrytme: kvartalsvis afstemning omkring et klart forretningsmål, efterfulgt af en discovery-fase og derefter eksekvering med definerede krav, scope og deadlines — gennemgået af teamet, før arbejdet begyndte.

Discovery blev den del, jeg investerede mest i. Hver cyklus trækker på nogle få konkrete input: feedback fra customer success indsamlet regelmæssigt og ført ind i backloggen, CEO'ens strategiske prioriteter, vores egen analyse af, hvor produktet havde det svært, og et tjek på konkurrenterne, så vi ikke kom bagud på de helt grundlæggende funktioner. Intet enkelt input afgør retningen; den opstår ved at veje dem op mod hinanden.

Jeg gjorde POC'er til en fast del af scoping. Før jeg forpligtede teamet til et større projekt, byggede jeg en fungerende prototype for at teste gennemførligheden og forme kravene. Det tydeligste eksempel er den nuværende chat-refaktorering — at gå fra et system, der opsummerede søgeresultater, til en fuldt agentisk chat med tool calling og kontekstlag. Før jeg skrev et eneste krav, byggede jeg en grov fungerende version for at trykprøve tilgangen og gav den derefter videre til vores data scientist, som forvandlede den til produktionsdesigndokumentet. Det tog et par uger ved siden af andet arbejde — men teamet begyndte eksekveringen med et klart billede af, hvad de byggede, og hvorfor.

Jeg fortalte ikke engineering, hvordan de skulle arbejde. Mit job var at gøre målene klare og kravene solide. Resten var op til dem.

Det betød ikke, at alt blev langsommere. Struktureret arbejde udgjorde omkring 80% af roadmappen; de resterende 20% blev bevidst holdt fleksible til hurtige rettelser, lavthængende frugter og det opportunistiske arbejde, en startup stadig har brug for. Rettelser skete stadig — de blev bare scopet, prioriteret bevidst og planlagt omkring i stedet for at få lov til at dominere.

Partnerplatformen

Det tydeligste eksempel på, hvad denne proces gjorde mulig, er partnerplatformen bygget i Q1 2026.

Raffle havde identificeret partnere — forhandlere og integratorer — som en betydelig vækstkanal, men der var ingen infrastruktur til at understøtte dem. Jeg arbejdede tæt sammen med vores partnerships manager fra bunden: startede med dyb discovery i, hvad de faktisk havde brug for, og generaliserede derefter bevidst de behov til noget skalerbart i stedet for at bygge endnu en engangsløsning.

Det, vi byggede, var en komplet account-management-platform til partnere:

• Et self-serve-flow til at oprette og konfigurere kundekonti og køre scrapes
• Et plan- og rettighedssystem til at tildele features baseret på kommercielle aftaler — fuldt skalerbart og nu også brugt internt
• Et widget-skabelonsystem, så partnere hurtigt og ensartet kunne sætte nye kunder op
• Et overvågningsdashboard til at følge kontoperformance og tidligt få øje på problemer og muligheder

Resultatet: partner-administrerede konti gik fra nul til mere end 200, og Raffles samlede kundebase voksede fra omkring 100 til over 300. Den kundekategori eksisterede ikke før — produktet kunne ikke understøtte den. Vi havde håndbygget skræddersyede løsninger til en håndfuld kunder; dette forvandlede det til noget, partnere kunne sælge og skalere på egen hånd.

Jeg vil dog være ærlig om det tal, der springer i øjnene: den vækst er ikke oversat proportionalt til omsætning. De nye kontrakter er mindre, og churn har udlignet en del af volumen, og at lukke det gab er stadig et igangværende arbejde. Men intet af det var overhovedet muligt, før platformen fandtes.

Hvordan teamet reagerede

Jeg var en designer, der trådte ind i en PM-rolle på et team, der allerede havde en designer — en med al mulig grund til at sætte spørgsmålstegn ved det. Spændingen var reel, men kortvarig, og teamet kom med hurtigere, end jeg havde forventet.

Jeg forsøgte ikke at ankomme som PM. Jeg fokuserede på at være nyttig og lod arbejdet gøre mig fortjent til rollen. Leveringen og kvaliteten af det, vi sendte ud, kom fra teamet; mit job var at gøre det lettere.

Hvad der ændrede sig

Features begyndte at tage længere tid. Produktet blev væsentligt bedre.

Før kunne en rettelse sendes ud på en dag. En rigtig feature, der fjerner en central produktbegrænsning, tager to til tre måneder. Den afvejning er det værd — men kun hvis man er ærlig om det. Vi bevæger os stadig hurtigt på de ting, der fortjener fart. Det, der ændrede sig, er, at langsomhed blev et valg, ikke et symptom.

Skiftet er synligt i to tal. Uventede rettelser faldt fra omkring dagligt til cirka en gang om ugen eller hver anden uge — de resterende scopet og prioriteret bevidst i stedet for at blive fyret af på forespørgsel. Og roadmap leveret til tiden steg hvert kvartal, efterhånden som processen modnedes: fra omkring 50% i mit første kvartal til cirka 60%, så 70% og omkring 80% nu. De tidlige roadmaps var for ambitiøse, og vi missede deadlines; efterhånden som planlægningen blev mere realistisk, blev leveringen bedre hvert kvartal.

Teamet gik fra reaktivt til bevidst, og forskellen viser sig i det, vi sendte ud: en komplet refaktorering af vektorsøgningen, der skar omkostninger og indekseringstid, en fuld widget-fornyelse, partnerplatformen bag en ny kundekategori, og en agentisk chat — i gang lige nu — der sigter mod grundlæggende at ændre, hvad produktet kan.

Det omsætningsgab, jeg nævnte tidligere, er det næste problem, der skal løses, og det er reelt. Men det er et problem, virksomheden nu faktisk kan arbejde med. For atten måneder siden kunne produktet slet ikke skalere; i dag har det et fundament, der gør bæredygtig vækst mulig — og at bygge det fundament, sammen med teamet, er det, det seneste års arbejde i virkeligheden handlede om.