Produkt-roadmap efter lancering: sådan prioriterer du videreudviklingen
Sådan prioriterer du din produkt-roadmap efter lancering: en enkel model med værdi mod indsats, og hvordan du planlægger næste kvartal med din udvikler.
Freelance full-stack udvikler
- Udgivet
- Læsetid
- 11 min.
Indhold i indlægget8
Den enkleste måde at prioritere din produkt-roadmap efter lancering er at give hvert ønske en score for værdi og en for indsats, starte med de punkter der giver meget for en lille indsats og planlægge ét kvartal ad gangen. Resten havner på en liste over det der kommer senere, ikke i kalenderen.
Jeg laver selv videreudvikling af eksisterende webapps, så det her er også en beskrivelse af hvordan jeg helst arbejder. Modellen virker dog uanset hvem der skriver koden.
Den korte version: værdi mod indsats
| Lav indsats | Høj indsats | |
|---|---|---|
| Høj værdi | Gør det nu. Det er dine hurtige gevinster. | Planlæg det, og del det op i mindre trin. |
| Lav værdi | Kun hvis der er luft, fx mellem større opgaver. | Sig nej, eller lad det blive på listen over senere. |
Beslutningsreglen er enkel: læg punkterne med høj værdi ind i kvartalet, og vær skeptisk over for alt med høj indsats og lav værdi. Prioriteringen foregår inden for det budget der er tilbage, når driften er dækket.
Videreudvikling er kun én del af arbejdet med en app efter lancering. I min guide til drift og vedligehold af webapps kan du se hvordan den hænger sammen med opdateringer, overvågning og backup.
Hvorfor prioritering bliver sværere efter lancering
Før lanceringen er der én opgave: få første version ud. Bagefter kommer ønskerne fra alle sider på én gang. Kunderne skriver til supporten. Sælgerne har en stor kunde der mangler én bestemt funktion. Ledelsen har set noget hos en konkurrent. Udvikleren peger på opdateringer der skal laves, og kode der burde skrives om. Og så er der fejlene.
Uden en fælles model ender videreudviklingen med at følge den der råber højest, eller den der skrev senest. Resultatet er en app med mange halve løsninger og en udvikling der skifter retning hver anden uge.
Til gengæld har du nu noget du ikke havde før lanceringen: rigtige brugere. Du kan se hvad de bruger, hvor de går i stå, og hvad de spørger om. Det gør prioriteringen langt mere præcis, men kun hvis du faktisk kigger på dataene. En roadmap efter lancering bør bygge mere på hvad brugerne gør, og mindre på hvad du troede de ville gøre.
Sådan prioriterer du din roadmap i 6 trin
Modellen kræver ikke et særligt værktøj. Et regneark med en kolonne til værdi, en til indsats og en til noter er nok til de fleste apps i drift.
1. Saml alle ønsker på én liste
Ønsker der ligger spredt i mails, chatbeskeder og mødenoter, bliver ikke prioriteret. De bliver glemt eller lavet i tilfældig rækkefølge. Saml dem på én liste, ofte kaldet en backlog, og notér for hvert punkt hvem der har bedt om det, og hvor tit det dukker op.
Skriv punktet som et problem, ikke som en løsning. "Kunderne kan ikke se status på deres ordre, så de ringer" er bedre end "byg en statusside". Problemet kan måske løses med en automatisk e-mail, og så har du sparet en hel funktion.
2. Giv hvert punkt en værdiscore
Værdi betyder noget forskelligt fra forretning til forretning, så aftal på forhånd hvad der tæller. Typisk er det en af fire ting: mere omsætning, sparet tid internt, færre kunder der opsiger, eller mindre risiko. Giv hvert punkt en score fra 1 til 5.
Brug data hvor du kan. Hvor mange henvendelser til supporten handler om problemet? Hvor mange brugere når overhovedet frem til den side hvor funktionen skal ligge? Har du ikke brugsdata endnu, er det et godt sted at starte, og jeg har sammenlignet GA4, Plausible og PostHog til måling i webapps. Et ønske fra én højlydt kunde er ikke det samme som et problem for halvdelen af brugerne.
3. Få et groft estimat på indsatsen
Her kommer udvikleren på banen. Indsats scores også fra 1 til 5, eller i størrelser som S, M, L og XL. Formålet er at sammenligne punkterne med hinanden, ikke at lave et tilbud, så et groft skøn er nok.
Et godt estimat dækker mere end selve koden: test, ændringer i databasen, integrationer til andre systemer og den vedligeholdelse funktionen kræver bagefter. En lille ændring i betalingsforløbet kan være større end en stor funktion der står helt for sig selv. Spørg udvikleren hvad der gør et punkt dyrt. Svaret fører ofte til en billigere version af samme idé.
4. Sæt kapacitet af til vedligehold først
Før du fordeler kvartalets timer på nye funktioner, så tag en fast del fra til opdateringer, fejlrettelser og oprydning i koden. Min tommelfingerregel er omkring en femtedel af timerne, og mere hvis appen er bagud med opdateringer. Gør du det ikke, taber vedligeholdet hver gang, fordi en ny funktion altid virker mere presserende end en opdatering.
Regningen kommer senere som teknisk gæld, hvor hver ændring tager lidt længere tid end den forrige. Jeg har også skrevet om hvorfor du skal opdatere framework og pakker, og hvad det koster at lade være.
5. Sortér listen og vælg kvartalets vigtigste punkter
Sortér efter værdi delt med indsats, og placér punkterne i tabellen fra den korte version. Vælg derefter 2-4 større punkter til kvartalet plus et par hurtige gevinster. Tager du flere med, ender det hele som halvfærdigt arbejde.
Scoren er et udgangspunkt, ikke en facitliste. Scorer to punkter næsten ens, så vælg det der lærer dig mest om brugerne, eller det der er en forudsætning for noget andet på listen.
6. Del planen op i nu, næste og senere
Skriv resultatet ned i tre kolonner: det der bygges nu, det der kommer bagefter, og alt det andet. Formen kaldes en Now-Next-Later-roadmap og er gjort kendt af Janna Bastow fra ProdPad som et alternativ til tidslinjer med faste datoer (ProdPads beskrivelse af modellen). "Nu" er beskrevet i detaljer. "Næste" er beskrevet groft. "Senere" er en liste over ideer og problemer som ingen har lovet noget om.
Fordelen er at du kan vise planen til ledelsen og til kunderne uden at love en dato du ikke kan holde.
Sådan planlægger jeg næste kvartal sammen med en kunde
Prioriteringen bliver bedst når kunden og udvikleren laver den sammen. Du kender forretningen og brugerne. Udvikleren kender koden, risikoen og hvad tingene reelt koster. Sådan foretrækker jeg at gøre det:
- Inden mødet opdaterer du ønskelisten og giver punkterne en værdiscore. Samtidig gennemgår jeg appens tekniske tilstand: versioner der snart mister support, fejl fra fejlrapporteringen og steder i koden der gør nye ændringer langsomme.
- Mødet starter med et tilbageblik på det seneste kvartal. Hvad blev lavet, virkede det, og var der nedbrud eller fejl der tog tid fra planen?
- Derefter giver jeg et groft estimat på de punkter der har høj værdi, og foreslår billigere versioner hvor det kan lade sig gøre.
- Du vælger kvartalets punkter inden for budgettet, efter at timerne til vedligehold er trukket fra. Det sidste ord er dit.
- Til sidst skriver jeg planen ned på én side: målet for kvartalet, de valgte punkter, hvad der er sat af til vedligehold, og hvad der bevidst er valgt fra.
Mellem møderne holder en kort månedlig status planen ajour. Dukker der noget akut op, bytter det plads med et punkt af samme størrelse i stedet for at blive lagt oveni. Budgettet kan fx være en timebank eller et fast månedligt beløb, og vilkårene hører hjemme i din serviceaftale med udvikleren.
Når værdi mod indsats ikke er nok
Værdi mod indsats dækker de fleste apps i drift. Der er dog tre situationer hvor du skal supplere modellen.
Når listen er lang
Har du mange punkter og mange der byder ind, kan RICE give en mere nuanceret score. Modellen fra Intercom ganger rækkevidde (hvor mange brugere det rammer), effekt og sikkerhed (hvor sikker du er på dit skøn) og dividerer med indsats (Intercoms beskrivelse af RICE). Sikkerheden er den mest nyttige del. Den trækker scoren ned på de ideer som alle er begejstrede for, men som ingen har data på.
Når noget ikke kan vente
Nogle ting skal slet ikke scores. Sikkerhedshuller, fejl der stopper login eller betalinger, lovkrav, fx om persondata eller tilgængelighed, og aftaler du har skrevet under på med kunder, går forrest. Det er netop derfor timerne til vedligehold skal sættes af først. Så kan det akutte klares uden at hele planen vælter.
Når én stor kunde vil have en særlig funktion
Det er den sværeste prioritering, fordi værdien er konkret og ofte stor. Spørg om funktionen også løser et problem for andre kunder, og om den kan bygges så den passer ind i produktet. Hvis ikke, så husk at du skal vedligeholde den så længe appen lever. Nogle gange er det bedste svar en integration eller en eksport af data i stedet for en ny funktion.
Typiske fejl i en roadmap efter lancering
- Alt får høj værdi. Scorer mere end en tredjedel af listen 4 eller 5, er skalaen ikke brugt ærligt. Spred scorerne, så kun de vigtigste punkter får topkarakter.
- Roadmappen bliver et løfte med datoer. Kunder og sælgere husker datoen og glemmer forbeholdet, så del hvad der er "nu" og "næste", ikke ugenumre.
- Ingen måler bagefter. Beslut før du bygger hvordan du vil se om funktionen virkede, fx færre henvendelser om et bestemt emne eller flere der gennemfører en bestilling. Tjek det ved næste kvartalsmøde.
- For mange ting på én gang. Fem halvfærdige funktioner hjælper ikke en eneste bruger.
- Vedligeholdet bliver skubbet. Et kvartal uden opdateringer er sjældent et problem, men fire i træk gør næste opgradering til et projekt.
Næste skridt
Start med de to første trin: saml ønskerne på én liste, og giv dem en værdiscore. Det kan du gøre uden en udvikler, og det alene gør næste samtale om budget og prioritering meget mere konkret.
Klar til at planlægge næste kvartal?
- Én liste: alle ønsker og fejl ligger samme sted, formuleret som problemer.
- Værdi: hvert punkt har en score fra 1 til 5, og det er aftalt hvad værdi betyder hos dig.
- Data: du kan se hvad brugerne gør, og hvad supporten får spørgsmål om.
- Indsats: de vigtigste punkter har et groft estimat fra en udvikler.
- Vedligehold: en fast del af kvartalets timer er sat af, før nye funktioner får resten.
- Plan: "nu", "næste" og "senere" står på én side, og én person har det sidste ord.
- Måling: hvert punkt under "nu" har et aftalt tegn på at det virker.
Har du en produktansvarlig og et internt udviklingsteam, har du ikke brug for en ekstern udvikler til selve prioriteringen. Så er modellen her et tjek af din egen proces. Mangler du derimod en der kender koden og kan give ærlige estimater, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende webapps.
Ofte stillede spørgsmål
Skal jeg vise min roadmap til kunderne?
Ja, gerne, men uden datoer. Vis hvad du arbejder på nu, og hvad der kommer bagefter, så kunderne kan se at deres ønsker bliver hørt. Hold "senere" for dig selv, eller beskriv det meget løst. En dato på en offentlig roadmap bliver hurtigt opfattet som et løfte, og et brudt løfte koster mere tillid end en plan uden datoer.
Skal fejl prioriteres på samme liste som nye funktioner?
Ja, med én undtagelse. Kritiske fejl der stopper login, betalinger eller vigtige arbejdsgange, rettes med det samme og skal ikke vente på næste prioritering. Mindre fejl hører hjemme på samme liste som nye funktioner og scores på samme måde. Så bliver det tydeligt når en irriterende fejl faktisk er vigtigere end den næste funktion.
Hvilket værktøj skal jeg bruge til min roadmap?
Brug det enkleste værktøj som alle allerede har adgang til. Et regneark, Notion, Trello eller GitHub Projects er nok til de fleste apps i drift. Værktøjet betyder meget mindre end rytmen: at listen bliver opdateret, at punkterne får en score, og at planen bliver gennemgået hvert kvartal. Egentlige roadmap-værktøjer bliver først relevante når flere teams deler den samme plan.
Hvor lang tid tager kvartalsplanlægningen?
Typisk nogle få timer pr. kvartal for både dig og udvikleren. Det dækker forberedelse, et møde på et par timer og en kort skriftlig plan bagefter. Første gang tager det længere tid, fordi listen skal samles og scores fra bunden. Tiden er godt givet ud, hvis den forhindrer bare én stor funktion som ingen ender med at bruge.