Vi lavede en WEMASY-regel: Intet sendes ud, før det har overlevet os
Meget tidligt på vores rejse lavede vi én regel, der styrer, hvordan alle WEMASY-produkter bliver bygget. Vi kalder den vores "Overlev os først"-regel. Den er enkel. Hvis en funktion ikke gnidningsfrit kan støtte vores eget daglige arbejde, er den ikke klar til andre.
Reglen holder os jordnære. Den forhindrer os i at bygge til præsentationer og skubber os til at bygge til brug i det virkelige liv. Den minder os om, at et produkt ikke er en succes, når det bliver lanceret. Det er en succes, når folk kan bruge det trygt hver eneste dag uden at føle sig fortabte, forvirrede eller trætte.
Hvorfor de fleste strategier for produktlancering fejler
Vi kiggede på lanceringer, der tog fart, og lanceringer, der stille gled ud i sandet, inklusive nogle af vores egne tidlige versioner. Forskellen var sjældent idéen. Det handlede om, hvordan produktet klarede sig i ægte, rodet hverdagsbrug. Funktioner, der så flotte ud i en demo, brød sammen på travle dage. De små gnidninger hobede sig op, og folk gled tilbage til gamle vaner.
Her er nogle af de ting, vi lagde mærke til:
Teams sender produkter ud til lanceringsdagen og ikke til arbejdsdagen. Funktionen skinner i en præsentation, men viser ikke vejen til næste skridt, når nogen har travlt.
Små gnidninger hober sig op, indtil brugerne giver op. Et ekstra klik her og en skjult indstilling der gør langsomt værktøjet trættende at bruge.
Produktet forventer, at brugerne tilpasser sig det. I stedet for at passe til den måde, folk allerede arbejder på, tvinger det en ny vej igennem med flere trin og mere tænkning.
Den ægte sammenhæng lever uden for værktøjet. Filer, feedback og beslutninger bliver i chats og mails, så produktet aldrig bliver det ene sted, hvor sandheden findes.
Ejerskab og resultater er uklare. Folk kan ikke se, hvem der skal handle næste gang, eller hvad "færdig" betyder, så opgaver hopper rundt, og tidsplaner skrider.
Der er ingen intern daglig brug før lanceringen. Uden at leve med produktet overser teamet de hverdagsproblemer, der først viser sig efter flere dages ægte arbejde.
Vi lærte også af vores egne fejl
De bedste lektioner lærer man af fejl. Vi indså, at vi ikke var immune over for de samme fejl. I de tidlige dage med WEMASY byggede vi også funktioner, der gav perfekt mening på planlægningsmøderne. Alle var enige om, at idéen var god. Men i det øjeblik vi prøvede at bruge funktionerne i vores daglige arbejde, mærkede vi den samme gnidning, som vi havde set i andre produkter.
Det, der så enkelt ud på skærmen, føltes langsomt, når vi rent faktisk prøvede at gøre en opgave færdig.
Et forløb, der lød klart under diskussionen, blev forvirrende, når vi prøvede det uden sammenhæng.
Trin, vi troede var "ingen big deal", blev trættende, når de blev gentaget flere gange om dagen.
Vi greb os selv i at bruge nødløsninger uden for værktøjet, og det var et klart tegn på, at funktionen ikke støttede det ægte arbejde.
Det blev vores vendepunkt. Vi forstod, at hvis vi ikke selv kunne bruge en funktion gnidningsfrit, selv om vi vidste, hvordan den var bygget, ville almindelige brugere have det endnu sværere. Ingen marketingplan for produktlancering kan redde et produkt, der ikke virker i daglig brug. Det var der, vi besluttede at ændre måden, vi bygger og lancerer vores produkter på, og lave en intern regel for det.
Vores trin til at lancere et produkt hos WEMASY
Med det, vi havde lært, blev vores guide til produktlancering enkel. Hvis vi vil have, at brugerne føler, at WEMASYs produkter virker for dem, så skal WEMASY først virke for os uden besvær. Det flyttede os fra at bygge ud fra antagelser til at bygge ud fra erfaring. I dag går hvert produkt gennem tre faser, før det når frem til dig.
De tre vigtige trin:
Trin 1. Vi bygger en fungerende version og bruger den selv først
I det øjeblik en funktion virker, flytter vi vores eget daglige arbejde ind i den. Det er her, sandheden kommer frem. Vi ser med det samme, hvad der afbryder flowet, hvad der føles tungt, og hvad der skal være mere naturligt. Hvis noget gør os langsommere, retter vi det. Hvis vi skal tænke for meget eller synes, det er svært at bruge, gør vi det enklere. Vi finpudser, indtil vi holder op med at lægge mærke til værktøjet og kun lægger mærke til, at arbejdet bliver gjort.
Trin 2. Vi deler den med en lille gruppe eksisterende WEMASY-brugere
Når vi kan bruge den uden besvær, åbner vi den for en lille gruppe nuværende brugere, der elsker at give ærlig feedback. De viser os, hvordan funktionen opfører sig med forskellige arbejdsstile, brancher og teamstørrelser. Deres feedback hjælper os med at slibe de kanter, vi måske har overset, for den måde, vi bruger et produkt på, er ikke den eneste måde, folk vil bruge det på.
Trin 3. Vi udgiver den først offentligt, når begge sider kan bruge den gnidningsfrit
Først når funktionen virker godt for os og for den første gruppe, gør vi den tilgængelig for alle. Når den når ud til alle brugere, er den stabil, tydelig og klar til brug uden oplæringsopkald eller indviklet onboarding.
Vi byggede WEMASY sådan, fordi vi selv har mærket smerten ved værktøjer, der ser godt ud, men ikke hjælper på en travl dag. At bruge vores egne produkter først holder os troværdige, pålidelige og ærlige. Hvis du tror, vores strategi for produktlancering kan hjælpe dig, så prøv den, og fortæl os, hvordan den virkede for dit brand. Vil du vide mere om at komme online, så læs vores blog om hvordan du kommer i gang med din hjemmeside. Du kan også se vores tjekliste til lancering af hjemmesiden. Få hele billedet i vores hovedguide om hvad en hjemmeside er, og hvorfor du har brug for en.
Ofte stillede spørgsmål
Hvad kendetegner en god strategi for produktlancering?
Hos WEMASY har vi lært, at den bedste strategi for produktlancering er en, hvor teamet bruger produktet hver dag, før nogen andre ser det. Når du selv mærker gnidningen, løser du de ægte problemer, ikke dem, du forestillede dig under planlægningen. Tidlig feedback fra 10 til 30 rigtige brugere giver det udefra-blik, dit team ikke selv kan have. Når du går offentligt ud, virker produktet allerede under rodede, virkelige forhold.
Hvor længe skal intern test vare før en produktlancering?
Mindst to til fire uger med ægte daglig brug. En hurtig test over en weekend overser den gnidning, der først viser sig efter gentagen brug. Målet er at finde de små problemer, der hober sig op over dage, som ekstra klik, forvirrende forløb eller manglende sammenhæng. Det er de ting, brugerne mærker med det samme, men som teams ofte overser.
Skal jeg lave en marketingplan for produktlancering, før produktet er klar?
Begynd at planlægge tidligt, men lås ikke budskaberne fast, før produktet er testet. Din marketingplan for produktlancering bør bygge på ægte feedback fra brugere, ikke på antagelser. Hvis testen viser, at brugerne sætter pris på en anden fordel, end du regnede med, skal din vinkel i markedsføringen ændres. Byg planen sideløbende, men vær fleksibel.
Hvad er den største fejl, teams begår ved en produktlancering?
De sender produktet ud til lanceringsdagen i stedet for til arbejdsdagen. Mange teams haster for at nå en deadline og springer den ægte test over. Produktet ser flot ud i en præsentation, men frustrerer brugerne på dag tre. En ekstra uge til ordentlig test sparer måneders rettelser og negativ feedback efter lanceringen.
Hvor mange tidlige brugere skal jeg teste med, før jeg lancerer offentligt?
Start med 10 til 30 brugere, der repræsenterer din faktiske målgruppe. Det skal være folk, der vil bruge produktet jævnligt, ikke kun venner, der klikker rundt én gang. Deres feedback er mere værd end hundredvis af svar på en spørgeundersøgelse, fordi de oplever den ægte gnidning, som tilfældige testere overser.
Hvordan tester WEMASY sine egne produkter før lancering?
Hver WEMASY-funktion går gennem tre faser: intern daglig brug i teamet, test med en lille gruppe eksisterende brugere og først derefter en offentlig udgivelse. Hvis en funktion ikke virker gnidningsfrit for teamet og de tidlige brugere, bliver den ikke sendt ud. Den proces sikrer, at hvert værktøj er stabilt, tydeligt og klar til ægte arbejde fra dag ét.
