I en verden hvor en funktion kan designes, programmeres og deployeres hurtigere end nogensinde, bliver tempoet ikke længere det største problem. Problemet er i stedet beslutningen om, hvad der faktisk er værd at bygge.
Der er et øjeblik i livet for næsten hvert system under udvikling, hvor funktionslisten begynder at leve sit eget liv.
"Klienten bad om det."
"Konkurrenten har det."
"Det burde vel ikke være svært."
"Da vi alligevel har modulen, så lad os tilføje..."
"AI klarer det hurtigt."
Og pludselig ryger endnu en funktion i backloggen. Så en til. Og en tredje. Efter nogle år har virksomheden en app, der næsten kan alt. Men brugeren har sværere og sværere ved at finde det, han eller hun faktisk har brug for.
Det er ikke kun et UX-problem. Det er et forretningsproblem.
Når flere funktioner ikke længere betyder et bedre produkt
I årevis har softwareudvikling fulgt en ret enkel logik: hvis brugerne har brug for nye muligheder, tilføjer vi nye funktioner. Det virker fornuftigt.
Problemet opstår, når produktudvikling reduceres til antallet af leverede funktioner. Så begynder teamet at optimere ikke for brugerens værdi, men for antallet af ting, man har "fået leveret".
Der opstår en såkaldt Feature Factory — en organisation, der producerer funktioner, men ikke nødvendigvis måler, om de faktisk løser kundernes problemer.
Fænomenet er ikke nyt. Det nye er hastigheden, hvormed det i dag kan udvikle sig.
AI forkorter markant vejen fra idé til fungerende prototype. Atlassian beskriver ændringen direkte: med udviklingsagenter kan vejen fra "vi ved, hvad vi vil bygge" til en fungerende prototype krympes fra uger til timer.
Det er en enorm mulighed. Men også en faldgrube.
For hvis byggeomkostningerne og tiden falder, bliver det nemmere at begynde at bygge ting, som man tidligere ikke ville have turdet bestille.
"Hvis vi kan, så lad os gøre det"
Det er en af de dyreste sætninger i IT-projekter. Ikke fordi hver ekstra funktion koster en formue at bygge. Problemet er, at en funktion aldrig slutter sit liv ved deployment.
Hvert nyt modul skal senere vedligeholdes. Det skal testes. Det skal tages i betragtning ved kommende ændringer. Det skal dokumenteres. Bugs skal håndteres. Brugere skal trænes. Det skal indtænkes i UX. Sikkerheden skal overvåges. Man skal sikre, at ændringer andre steder ikke bryder det.
Derfor er omkostningen ved en funktion ikke kun prisen for at bygge den. Det er også omkostningen ved dens fremtidige eksistens.
Og netop denne omkostning ses ofte ikke, når nogen siger:
"Lad os måske lige tilføje..."
Den dyreste funktion kan være den, ingen bruger
Forestil dig en virksomhed, der udvikler et B2B-panel.
Kunderne kan afgive ordrer, tjekke købsoversigt, hente dokumenter og kontakte deres kundekonsulent.
Der opstår en idé om et avanceret rapporteringssystem. Teamet designer det. Udviklerne bygger det. Der kommer diagrammer, filtre, eksportfunktioner, dashboards og mange ekstra parametre. Funktionen går i produktion.
Og så viser det sig, at de fleste kunder blot vil vide: hvad jeg har købt, hvad er på vej, og hvad er prisen.
Alt det andet var en antagelse. De havde ikke brug for det. Det er en vigtig forskel.
En kunde kan bede om en funktion. Det betyder ikke nødvendigvis, at denne funktion løser kundens problem.
"Konkurrenten har det"
Det er en klassiker.
Virksomheden analyserer konkurrenten og ser et nyt modul.
Og så starter det: "Vi må også have det."
Men konkurrenten kan have et helt andet forretningsmodel, en anden kundebase, andre salgprocesser og en anden produktstrategi.
En funktion, der giver mening i ét system, kan være fuldstændig unødvendig i et andet.
Det er især vigtigt i skræddersyede projekter. Der findes ikke en universel funktionskatalog, der gør enhver app god.
Et system til en industriproducent bør ikke designes som en platform til en uddannelsesvirksomhed.
Et CRM til sælgere bør ikke fungere præcis som et B2B-panel til faste kunder.
En netbutik, der sælger premiumprodukter, kan have et helt andet købsflow end en shop, hvor pris er det primære argument.
Software bør udspringe af forretningsmodellen, ikke af konkurrentens funktionskatalog.
AI ændrer virkelig meget her
Og netop derfor er emnet særligt interessant i dag.
For få år siden skulle en idé til en ny funktion igennem mange trin, før brugeren kunne se den.
Analyse.
Design.
UX.
Udvikling.
Tests.
Deployment.
I dag kan mange af disse trin accelereres betydeligt af AI. Vi kan hurtigere lave prototyper. Hurtigere forberede interfaces. Hurtigere skrive kode. Hurtigere generere tests. Hurtigere analysere data.
Og derfor er selve udviklingshastigheden ikke længere en tilstrækkelig fordel.
Hvis alle kan bygge hurtigere, får den fordel, der vælger bedre hvad der skal bygges.
Atlassian fremhæver dette paradoks i sin undersøgelse af produktmanagementets fremtid: AI øger arbejdshastigheden, men højere tempo alene betyder ikke bedre produkter. Samtidig rapporterede 89% af de ledere, Atlassian spurgte, øget hastighed takket være AI, mens kun 6% følte sig sikre på at kvantificere AI's ROI i hele organisationen.
Det illustrerer forskellen mellem at gøre ting hurtigere og at opnå et bedre resultat.
Først problem. Først derefter funktion
En god produktproces bør starte med spørgsmålet: Hvilket problem prøver vi at løse?
Ikke: "Hvilken funktion skal vi tilføje?"
Det virker som en lille forskel. I praksis ændrer det alt.
Hvis en kunde siger: "Vi har brug for en mobilapp",
er det værd at spørge: Hvorfor?
Måske har de virkelig brug for en app. Men måske handler problemet om manglende adgang til panelet på telefonen. Måske er et veludført responsivt interface nok. Måske en PWA. Måske et mobilmodul til en enkelt proces. Og måske er appen nødvendig — men af helt andre årsager, end kunden først sagde.
Det samme gælder funktioner.
"Vi har brug for automatiske rapporter." — Hvorfor?
"Fordi sælgerne spilder tid." — På hvad?
"På at taste data manuelt ind fra systemet."
Og så viser det sig, at problemet ikke er mangel på rapporter, men mangel på integration.
Gode analyser kan spare måneder af udviklingstid.
Nogle gange er den bedste funktion ingen funktion
Det lyder paradoksalt, men det bør være rollen for en erfaren teknologipartner.
Ikke kun at levere. Også at stille spørgsmål ved antagelser, når der er grund til det.
Hvis en kunde kommer med en liste over tyve funktioner, bør et softwarehus ikke automatisk behandle den som en teknisk specifikation hugget i sten.
Det bør spørge: Hvilke af disse funktioner løser et reelt problem? Hvilke er kritiske? Hvilke øger salget? Hvilke reducerer arbejdstid? Hvilke forbedrer kundeservicen? Hvilke er juridisk eller operationelt nødvendige? Hvilke er kun "et fedt ekstratilbud"?
Og frem for alt: Hvordan vil vi måle, at en funktion er en succes?
Uden det spørgsmål er det let at skabe et produkt, der vokser konstant, men hvor man aldrig ved, om det faktisk bliver bedre.
Produktet skal kunne sige "nej"
I god product development er lige så vigtig som listen over ting, vi bygger, en liste over ting, vi ikke bygger. Det kræver mod.
For det er nemt at sige: "Ja, det gør vi."
Det er sværere at sige: "På baggrund af det, vi ved nu, ser vi endnu ikke grund til at betale for det."
Endnu sværere er det at sige det til en kunde, der netop kom med en færdig idé.
Men netop dér begynder det partnerskab, man bør have.
Et softwarehus skal ikke bare være et team, der omsætter ordrer til kode. Det skal hjælpe kunden med at træffe teknologiske beslutninger.
Nogle gange betyder det at designe funktionen.
Nogle gange at simplificere den.
Nogle gange at erstatte den med en anden løsning.
Og nogle gange at opgive idéen helt.
Hvordan genkender man en funktion, man sandsynligvis ikke behøver?
Der findes ingen magisk test, men nogle få spørgsmål kan hurtigt køle entusiasmen ned.
Hvem præcis vil bruge det?
Hvis svaret er "alle", er det værd at specificere nærmere.
Hvilket problem løser vi?
Hvis svaret er "det bliver bare mere bekvemt", kræver problemet sandsynligvis mere analyse.
Hvor ofte vil brugeren bruge det?
En gang om året? En gang om måneden? Dagligt?
Findes der en enklere måde at løse samme problem på?
Dette spørgsmål er særligt vigtigt.
Hvordan måler vi effekten?
Mere salg? Mindre arbejde? Kortere processer? Færre fejl? Højere retention?
Hvad sker der, hvis vi ikke bygger denne funktion?
Hvis svaret er "egentlig ingenting", har vi måske fundet en funktion, der ikke skal bygges.
Ikke hver brugeranmodning skal i backloggen
Det er også et vigtigt mindsetskift.
Brugerfeedback er uvurderligt. Men feedback er ikke automatisk en produkt-specifikation.
Brugeren beskriver sit problem ud fra sin egen oplevelse.
Han kan sige: "Jeg har brug for knap X."
Teamets rolle er ikke tankeløst at lave knap X.
Teamets rolle er at forstå: hvorfor brugeren har brug for den.
Først derefter kan man beslutte, om den bedste løsning virkelig er knap X.
Det kan være automatisering.
Det kan være integration.
Det kan være en procesændring.
Det kan være et bedre interface.
Det kan være brugeruddannelse.
Og nogle gange er det faktisk en ny funktion.
Det er forskellen mellem feature delivery og product development.
Data kan også sige: "fjern det"
Produktudvikling bør ikke stoppe ved at tilføje nye ting.
Man skal også kigge på, hvad der allerede findes.
Hvilke funktioner bruges?
Hvilke ignoreres?
Hvor falder brugerne fra?
Hvilke processer tager mest tid?
Hvilke elementer genererer flest supporthenvendelser?
Hvilke funktioner øger konvertering?
Og hvilke gør blot interfacet mere komplekst?
Nogle gange er det bedste udviklingsprojekt ikke at tilføje et nyt modul. Det er at fjerne tre unødvendige. Det kan forbedre UX mere end en ekstra måned med udvikling.
AI kan også hjælpe her
Interessant nok behøver AI ikke kun bruges til at skabe funktioner.
Den kan også hjælpe med at analysere, om funktionerne giver mening.
Den kan analysere brugerfeedback.
Gruppere henvendelser.
Identificere gentagne problemer.
Analysere supportdata.
Opsummere kundesamtaler.
Hjælpe teamet med at sammenligne hypoteser.
Forberede løsningsvarianter.
Understøtte analyse af brugeradfærd.
Paradoxalt nok kan den bedste brug af AI i product development nogle gange være ikke at bygge den næste funktion hurtigere.
Men derimod at hurtigere opdage, at vi ikke bør bygge den.
Web24: vi spørger først "hvorfor?"
Ethvert softwareprojekt starter med et behov.
Nogle gange ved kunden præcis, hvad han har brug for.
Nogle gange har kunden allerede en specifikation.
Nogle gange kommer kunden kun med et problem: "Denne proces tager os tre timer om dagen."
Og det er et rigtig godt udgangspunkt.
For så kan vi tænke ikke over, hvordan vi koder den foreslåede løsning, men hvordan vi bedst løser problemet.
Netop det adskiller skræddersyet softwareudvikling fra at samle et produkt af færdige komponenter.
I Web24 handler det ikke om, at hver app skal have så mange muligheder som muligt.
Det handler om, at den har de muligheder, der faktisk er nødvendige for den givne forretning.
Derfor kan to lignende systemer se helt forskellige ud og fungere forskelligt.
Fordi processerne er forskellige.
Fordi brugerne er forskellige.
Fordi målene er forskellige.
Fordi salgstilgangen er forskellig.
Fordi kundeservicen er forskellig.
Og fordi det problem, softwaren skal løse, er forskelligt.
Den dyreste backlog er den, ingen stiller spørgsmål ved
I AI-æraen kan vi komme ind i en meget interessant fase af softwareudvikling.
Teknologien vil blive bedre og bedre til at svare på: "Hvordan bygger vi det?"
Og mennesket skal blive bedre til at svare på: "Skal vi overhovedet bygge det?"
Det kan være en af de vigtigste ændringer i måden, vi skaber software på.
For hvis omkostningen og tiden til at bygge en funktion falder, vokser fristelsen til at tilføje dem.
Og samtidig vokser vigtigheden af Product Discovery, UX, dataanalyse, samtaler med brugerne og et strategisk syn på produktudvikling. Gartner advarer om, at hurtig produktudvikling drevet af AI kan føre til problemer med strategisk alignment og øget technical debt, hvis den teknologiske hastighed ikke matches af produktstyring.
Derfor vil fremtiden ikke kun tilhøre virksomheder, der kan bygge hurtigere. Den vil også tilhøre dem, der bedst kan vælge, hvad de skal bygge.
For nogle gange er den bedste teknologiske beslutning ikke: "Lad os lave endnu én funktion."
Men: "Lad os først undersøge, om vi virkelig har brug for den."
