Hvorfor jeg byggede det
Det startede ud fra en frustration jeg selv havde haft. Jeg har tidligere undervist tromme-elever, og hver uge stod jeg med det samme spørgsmål: har de øvet sig siden sidst — eller bluffer de? Det var umuligt at vide. Eleven sagde ja, fordi det var det socialt rigtige svar. Jeg gættede ud fra hvor godt de spillede i timen, men det var en utilstrækkelig proxy. Frustrationen lå der, men værktøjet til at løse den eksisterede ikke.
Det blev til hit-rep.com og et tilhørende lærer-dashboard. En træningsapp til tromme-rudiments med adfærdsbaseret tracking i baggrunden — bygget for at besvare det spørgsmål jeg selv aldrig kunne få ærligt svar på.
Hvad det er
Eleven åbner siden, vælger et alias, indtaster en fire-cifret PIN-kode og en klassekode. Derfra er flowet enkelt: vælg en rytme, klik start, følg en count-in fra fire ned til én, og spil rytmen — enten på computer med to taster (Z for venstre hånd, M for højre) eller på et touch screen device. Realtidsfeedback markerer pads grønt, gult eller rødt afhængigt af timing. Efter to gennemspilninger får eleven mellem nul og fem stjerner samt en konkret timing-offset i millisekunder.
Indholdet er de tre grundrudimenter alle trommeslagere lærer som fundament: Single Stroke, Double Stroke og Paradiddle, plus deres inverser. Tretten niveauer går fra 60 til 180 BPM, med et master mode der låser op for frit tempo-valg mellem 180 og 220 BPM når niveau tretten er gennemført.
Lærer-dashboardet er den mest interessante del. Læreren logger ind, ser sine klasser, og kan klikke ind på den enkelte elev. Per elev vises et overblik bygget op om syv sektioner: tre stat-kort med ugentlige gennemsnit, en daglig graf over øvningsminutter, en kalender med klikbare lektionsmarkeringer, et heatmap over typiske øvningstidspunkter på døgnet, top fem mest øvede rytmer, seneste sessioner, og administrative funktioner som reset af PIN. På klasseniveau ser læreren aggregerede tal: aktive elever, kolde elever der bør have et nudge, og gennemsnitlig ugentlig øvning.
Hvad jeg har designet for at måle — og hvorfor
Det er her casen bliver interessant fra et PM-perspektiv. Det var let nok at bygge selve appen. Den sværere disciplin var at beslutte hvad der skulle måles, og hvorfor.
Det første princip jeg satte: adfærd slår selvrapportering. Jeg ville ikke spørge eleverne hvor meget de havde øvet sig, eller hvor godt det gik. Jeg ville måle hvad de faktisk gjorde, hvornår de gjorde det, og hvor længe.
Det andet princip: brug er ikke det samme som værdi. En elev der åbner appen ti gange om ugen fordi læreren bad om det, beviser ikke at appen tilfører noget reelt. Det jeg ledte efter var en måling der kunne adskille pligt fra reel adoption.
Det førte mig til fire metrics, hver med en specifik begrundelse:
Andelen af øvning der finder sted midt imellem lektionerne — typisk torsdag til søndag i en uge med tirsdag som lektionsdag. Logikken er at øvning lige efter en lektion ofte er en forlængelse af lærerens instruktion, mens øvning midt imellem lektioner kræver at eleven selv aktivt har valgt at åbne appen. Self-motivated practice er en proxy for selv-initieret øvning.
Andelen af påbegyndte sessioner der gennemføres. Et lavt completion rate signalerer friktion — for svært, for kedeligt, for langt. Et højt completion rate signalerer at flow-følelsen rammer rigtigt.
Hvor mange dage om ugen eleven aktivt øver. Det skelner mellem en elev der øver i én lang session søndag aften før mandagens lektion, og en der spreder øvningen over tre-fire dage. Spredning er den stærkere indikator for vanedannelse.
Det enkleste tal — hvor ofte eleven kommer tilbage. Volumen alene siger ikke meget, men i kombination med de tre andre metrics tegner det et fyldigere billede.
Tesen er enkel: hvis eleverne primært øver lige efter en lektion, har vi bygget et lydigt værktøj. Hvis de også øver på en lørdag uden at være blevet bedt om det, har vi bygget noget der har plads i deres egen rytme. Det første er udsving af en pligt. Det andet er adoption.
Tekniske valg der ikke var trivielle
Fire beslutninger var værd at tænke over.
I stedet for at definere en session som en enkelt øvningsrunde, grupperer systemet aktivitet inden for 30 minutter som én sammenhængende session. Det undgår at tælle naturlige pauser som separate engagementer, og giver et mere ærligt billede af reel øvningstid.
Brugerne er børn. Standard auth-flows er bygget til voksne med email-konti. Jeg byggede et minimalt identitetssystem hvor eleven kun behøver et alias og fire cifre — kombineret med en klassekode der binder dem til den rigtige lærer.
Stjerner, niveauer og master mode unlock synces på tværs af enheder, så en elev kan starte på iPad i bilen og fortsætte på laptop hjemme uden tab af progress.
Lærere er autentificerede via Firebase Auth. Elever er ikke. Det krævede et regelsæt hvor elever kun kan opdatere deres egen progress på deres eget alias, mens lærere har læseadgang til hele klassen. Det er det stykke arbejde der er mindst synligt og sværest at få rigtigt.
Hvor casen står lige nu
Piloten er afsluttet. Her er hvad der faktisk skete.
Fire uger. Én lærer. Otte elever. Her er hvad tallene viste — og hvad de ikke viste.
En completion rate på 94% ligger næsten det dobbelte af typisk ed-tech benchmark på 30–50%. Engagement window måler antallet af dage fra en elevs første til seneste session i piloten — jo højere tal, jo mere spredt øvede eleven sig over tid. Gennemsnittet på 5,8 dage er primært drevet af to power users der øvede over hele pilotperioden. Den gennemsnitlige øvefrekvens var 0,75 sessions per elev per uge — lavt, men med stor spredning: de to mest aktive elever stod for 275 af 381 rytmer. Lærerens dashboard-brug var aktiv i 3 af 4 uger, da en af ugernes fravær skyldtes hhv. helligdag, koncertdag og glemsomhed.
Én metric vi ikke kunne besvare: øvede eleverne af sig selv — eller kun fordi læreren mindede dem om det? Vi designede self-motivated practice rate som den vigtigste enkelt-metric. Men læreren loggede aldrig lektionsdatoer i systemet, så vi mangler referencepunktet der adskiller øvning dagen efter lektion fra øvning på eget initiativ. Det er ikke en teknisk fejl — det er en adoptions-indsigt. Det ændrer præcis hvad vi prioriterer i fase 2: systemet skal kræve mindre aktiv indsats fra læreren, ikke mere.
Fra det afsluttende interview med læreren:
Hvad piloten lærte mig som var vigtigere end tallene: teacher-activation er flaskehalsen, ikke produktet. En lærer der glemmer at nævne appen i én uge har elever der ikke øver. Det er ikke en undtagelse — det er virkeligheden for trommelærere. Det peger direkte mod fase 2: funktioner der reducerer afhængigheden af lærerens aktive reminder.
Det andet vigtige fund: produktet adresserer i sin nuværende form kun 8 af lærerens 40 elever (20%) — resten spiller primært på trommesæt. Læreren formulerede det selv:
Lærer-definerede øvelser og en note-funktion er det næste skridt mod en større andel af markedet — de testes som fase 2 efter sommer med 4 yderligere lærere. Pålidelig lyd-analyse af trommesæt-rytmer viste sig at kræve hardware, ikke bare software, og undersøges som et separat, længere spor.
Hvad casen viser om mig som projektleder
Tre ting:
Jeg bygger for at lære noget specifikt. Jeg bygger ikke for at bygge. Hver tekniske beslutning her er truffet med et målepunkt for øje.
Jeg starter med adfærd, ikke meninger. Det er den disciplin jeg tager med ind i transformation-arbejde. Selvrapportering, status-rapporter og NPS-tal er nyttige supplementer — men de er aldrig det første sted jeg leder.
Jeg er villig til at publicere før jeg har resultatet. Det er sjældent. De fleste case studies skrives bagudrettet, hvor forfatteren allerede ved hvad svaret blev. Denne her skrives på et tidspunkt hvor jeg ikke ved om mine antagelser holder. Det er den ærligste form jeg kender.
Underviser du i trommer og vil prøve app'en med dine elever? Jeg er i gang med at skalere piloten og leder efter lærere til en gratis pilotfase 2 efter sommerferien.