Har din virksomhed bias mod beta-testing?
Om hvorfor virksomheder modarbejder beta-testing. Og hvordan du overkommer det.
TL;DR
Når virksomheder har bias mod beta-testing skyldes det typisk én af tre fejlslutninger:
Feature Factory-fejlslutningen, hvor logikken er, at man ikke kan vide om noget er en succes, før det lanceres.
Validerings-fejlslutningen, hvor logikken er, at man på forhånd kan være sikker på, at lanceringen bliver en succes
Rå data-fejlslutningen, hvor logikken er, at man alligevel kan validere om en lancering bliver en succes ved gradvist at udrulle den til brugere.
Uanset fejlslutning, er den bedste måde at modarbejde denne bias mod beta-testing:
Identificer de antagelser i virksomheden, der modarbejder beta-test.
Udføre små beta-test med det specifikke formål at modbevise disse antagelser - også selvom disse beta-test måske slet ikke påvirker den feature, der lanceres
For et par måneder siden skrev jeg om beta-tests og de usete værdier ved dem. Efterfølgende har jeg tænkt over, hvorfor jeg - på trods af, at jeg nærmest ophæver beta-testing til religion - så mange gange i min karriere har fravalgt dem.
På papiret er beta-tests oplagte. Virkeligheden (og især i virkeligheden uden for Silicon Valley) er dog ofte noget mere kompleks. Og desværre er det bare alt for ofte er virksomheders kultur og logikker, som spænder ben for beta-testing.
De tre typiske fejlslutninger, der fører til denne bias mod beta-testing er:
1 ‘Feature Factory’-fejlslutningen
Den nok mest udprægede fejlslutning er, når udviklings-teams bliver målt på, om de leverer de features, der står på roadmappet.
Da jeg startede som Product Manager i TV 2 tilbage i 2017, var dette en udpræget udfordring. TV 2-organisationens referenceramme for et roadmap var en TV-sendeplan. Derfor blev det værdsat at have meget detaljerede 12 måneders planer for, hvad man præcis ville levere og hvornår (og så skulle der altså noget nær en naturkatastrofe til, førend man kunne acceptere, at Vild Med Dans blev forsinket).
Samtidigt var TV 2 vant til at foretage store, milliondyre satsninger, hvor man accepterede, at mange ikke ville blive succeser (det er sådan det typisk foregår, når man producerer TV). Tilsammen skabte organisationen dermed en bias, hvor en forfejlet lancering uden nogen form for beta-test ofte var mere accepteret end en succesfuld beta-test, der identificerede behov for ændringer, og som derfor rykkede ved planerne.
2 Validerings-fejlslutningen
Den anden fejlslutning sker, når organisationer føler, de kan forudsige et tiltags succes alene via desk-research.
Det sker typisk, hvis organisationen har et overdrevent fokus på konkurrenter frem for på kunder. Her bliver man som organisation lettere lun på konkurrentens features, og udforskningen af hvad man selv skal bygge forfalder til en ‘so ein ding muss wir auch haben’-logik. For hvis en feature har stået på side 1 i konkurrentens salgsmateriale i 6 måneder, behøver man så overhovedet validere, at den er værd at kopiere?
3 Rå data-fejlslutningen
Den sidste fejlslutning er i den helt modsatte grøft og sker typisk i enormt datadrevne organisationer. Her er logikken, at ved gradvist at udrulle et tiltag brugerne, kan man få rå data til at gøre det beskidte arbejde med at afgøre om tiltaget var en succes.
Virksomheder forfalder til dette, fordi det er let. Faktisk kan det gøres næsten fuldt automatiseret. Men selvom det kan bruges til at sige om et tiltag blev en succes, hjælper det dig ikke med at forstå hvorfor (eller endnu vigtigere: hvordan det kan blive endnu mere succesfuldt?)
Sådan gør du op med de 3 bias
Når organisationer udvikler en af disse tre bias, er det let at forfalde til at se det som udtryk for cheferne som dumme teknologi-dinosaurer, der slet ikke forstår produktudvikling. Det er bare sjældent sandt. Faktisk tværtimod.
Organisatorisk bias er egentlig blot et udtryk for, at der hersker en bestemt logik i virksomheden. Og fælles for de tre fejlslutninger ovenfor er, at de alle har en iboende antagelse om, at betatest ikke kan bidrage med ny viden til organisationen.
I Feature Factory-fejlslutningen er antagelsen, man bare må leve med den kalkulerede risiko, at featuren ikke bliver en succes
I Validerings-fejlslutningen er antagelsen, at det allerede er et etableret faktum, at featuren bliver en succes.
I Rå data-fejlslutningen er antagelsen, at du automatisk finder ud af om featuren bliver en succes, som del af din lancering.
Første skridt for at overkomme organisatorisk bias mod beta-test er derfor at forstå, hvilken antagelse der spænder ben for beta-test. Derefter skal du bruge beta-test til specifikt at modbevise den antagelse gennem det, jeg kalder “pilot” beta-tests.
“Pilot” beta-testing hos TV 2
Nu nævnte jeg tidligere, at jeg har arbejdet hos TV 2, hvor vi var ramt af Feature Factory-fejlslutningen. Over tid lykkedes det dog for os (særligt pga. nogle meget dygtige Design-kollegaer) at få ændret denne antagelsen, og måden vi gjorde det på er egentlig en ret god skabelon for, hvordan man kan modarbejde bias.
På et tidspunkt begyndte vi at indføre beta-test på udvalgte features, uden at de dog fik en direkte indvirkning på de features vi testede. I stedet præsenterede vi indsigterne for kollegaer og chefer samtidig med at vi udrullede den givne feature til vores brugere. Og efter et par gentagelser, hvor vi viste organisationen, at vi kunne påvise, hvad der fungerede godt og mindre godt ved en feature allerede inden vi lancerede den, begyndte interessenter og chefer selv at efterspørge beta-testing på de næste tiltag.
Det kan virke banalt at sige, at modstand mod beta-test, blot skal løses ved at foretage dem alligevel. Det er nu heller ikke det der er pointen. Pointen er, at pilot beta-tests er designet til at bearbejde og påvirke organisationen snarere end selve produktet. Og først når organisationen ser værdien af beta-testing kan du reelt få værdi ud af at indgår beta-testing.
Så hvis du møder modstand imod beta-testing, bør du:
Identificere hvilken antagelse, der hersker i virksomheden som besværliggør beta-testen (i.e. hvilken af de tre fejlslutninger der hersker)
Udføre små beta-test med det specifikke formål at udfordre virksomheden bias.