I en värld där en funktion kan designas, programmeras och driftsättas snabbare än någonsin blir skapandets hastighet inte längre det största problemet. Problemet blir i stället beslutet om vad som faktiskt är värt att bygga.
Det finns ett sådant ögonblick i nästan varje system som utvecklas, när funktionslistan börjar leva sitt eget liv.
"Kunden frågade efter det."
"Konkurrenten har det."
"Det borde väl inte vara svårt."
"Eftersom vi redan har den modulen, lägg till..."
"AI fixar det snabbt."
Och plötsligt hamnar ännu en funktion i backloggen. Sen en till. Och ytterligare en. Efter några år har företaget en applikation som kan nästan allt. Men användaren har svårare att hitta det hen faktiskt behöver.
Det är inte bara ett UX-problem. Det är ett affärsproblem.
När fler funktioner slutar betyda en bättre produkt
Under årens lopp var logiken i mjukvaruutveckling ganska enkel: om användarna behöver nya möjligheter, lägger vi till nya funktioner. Det låter rimligt.
Problemet uppstår när produktutveckling reduceras till antalet levererade funktioner. Då börjar teamet optimera inte för användarvärde, utan för antalet saker de lyckats "leverera".
Då uppstår det så kallade Feature Factory – en organisation som producerar funktionalitet men inte nödvändigtvis mäter om den faktiskt löser kundernas problem.
Fenomenet är inte nytt. Det nya är hastigheten med vilken det idag kan ske.
AI förkortar avsevärt vägen från idé till fungerande prototyp. Atlassian beskriver förändringen direkt: med utvecklingsagenter kan vägen från "vi vet vad vi vill bygga" till en fungerande prototyp kortas från veckor till timmar.
Det är en enorm möjlighet. Men också en fälla.
För om byggandet blir billigare och snabbare blir det också lättare att börja bygga saker som tidigare ingen vågat beställa.
"Om vi kan, låt oss göra det"
Det är en av de dyraste fraserna i IT-projekt. Inte för att varje extra funktion kostar en förmögenhet. Problemet är att en funktion aldrig avslutar sitt liv vid driftsättning.
Varje nytt modul måste senare underhållas. Den måste testas. Den måste tas i beaktande vid framtida förändringar. Den måste dokumenteras. Den måste hantera fel. Användare måste utbildas. Den måste inplaneras i UX. Dess säkerhet måste övervakas. Man måste kontrollera att framtida ändringar inte bryter något.
Därför är kostnaden för en funktion inte bara kostnaden att skapa den. Det är också kostnaden för dess framtida existens.
Och just den kostnaden syns ofta inte när någon säger:
"Då kan vi väl lägga till det..."
Den dyraste funktionen kan vara den som ingen använder
Föreställ dig ett företag som utvecklar en B2B-panel.
Kunder kan lägga beställningar, se köphistorik, ladda ner dokument och kontakta sin kundansvarige.
Idén om ett avancerat rapporteringssystem dyker upp. Teamet designar det. Utvecklarna bygger det. Det blir diagram, filter, exportfunktioner, sammanställningar och flera extra parametrar. Funktionen går i produktion.
Och så visar det sig att de flesta kunder egentligen bara vill veta: hur mycket jag har köpt, vad som är på väg och vilket pris det är.
Allt annat var antaganden. De behövde det inte. Det är en viktig skillnad.
En kund kan be om en funktion. Det betyder inte automatiskt att den funktionen löser kundens problem.
"Konkurrenten har det"
Det är en klassiker.
Företaget analyserar konkurrenten och ser en ny modul.
Och så börjar det: "Vi måste också ha det."
Men konkurrenten kan ha en helt annan affärsmodell, annan kundgrupp, andra försäljningsprocesser och annan produktstrategi.
En funktion som är meningsfull i ett system kan vara helt onödig i ett annat.
Det är särskilt viktigt i skräddarsydda projekt. Det finns ingen universell uppsättning funktioner som gör varje applikation bra.
Ett system för en industriproducent bör inte designas på samma sätt som en plattform för ett utbildningsföretag.
CRM för säljare ska inte fungera på samma sätt som en B2B-panel för fasta kunder.
En e-butik som säljer premiumprodukter kan behöva en helt annan köpupplevelse än en butik där pris är huvudargumentet.
Mjukvara bör följa affärsmodellen, inte konkurrenternas funktionskatalog.
AI förändrar detta på riktigt
Och just därför är ämnet särskilt intressant idag.
För bara några år sedan behövde en idé till en ny funktion passera många steg innan en användare kunde se den.
Analys.
Design.
UX.
Utveckling.
Tester.
Driftsättning.
Idag kan många av dessa steg kraftigt accelereras av AI. Vi kan snabbare skapa prototyper. Snabbare förbereda gränssnitt. Snabbare skriva kod. Snabbare generera tester. Snabbare analysera data.
Och därför blir själva utvecklingshastigheten inte längre en tillräcklig fördel.
Om alla kan bygga saker snabbare, får den som är bättre på att välja vad som ska byggas fördel.
Atlassian påpekar i sin studie om produktledningens framtid detta paradox: AI ökar arbetstakten, men enbart ökad takt innebär inte bättre produkter. Samtidigt uppgav 89% av Atlassians tillfrågade ledare att hastigheten ökade tack vare AI, medan bara 6% kände sig säkra på att kunna bestämma AI:s konkreta ROI i hela organisationen.
Det visar tydligt skillnaden mellan att göra saker snabbare och att uppnå bättre resultat.
Först problemet. Funktionen kommer senare
En bra produktprocess borde börja med frågan: Vilket problem försöker vi lösa?
Inte: "Vilken funktion ska vi lägga till?"
Det verkar som en liten skillnad. I praktiken förändrar det allt.
Om en kund säger: "Vi behöver en mobilapp",
är det värt att fråga: Varför?
Kanske behövs verkligen en app. Men kanske handlar problemet om bristande åtkomst till panelen på telefonen. Kanske räcker en väl designad responsiv gränssnitt. Kanske en PWA. Kanske en mobil modul för en specifik process. Eller så behövs en app – men av helt andra skäl än kunden först uppgav.
Samma gäller funktioner.
"Vi behöver automatiska rapporter." – Varför?
"Säljarna förlorar tid." – På vad?
"På att skriva om data från systemet."
Plötsligt visar det sig att problemet inte är avsaknaden av en rapport. Problemet är brist på integration.
En bra analys kan spara månader av utvecklingstid.
Ibland är den bästa funktionen ingen funktion alls
Det låter paradoxalt, men det bör vara rollen för en erfaren teknologipartner.
Att inte bara leverera. Också att ifrågasätta antaganden när det finns skäl.
Om en kund kommer med en lista på tjugo funktioner bör ett software house inte automatiskt behandla den som en teknisk specifikation inhuggen i sten.
Det bör fråga: Vilka av dessa funktioner löser ett verkligt problem? Vilka är kritiska? Vilka ökar försäljningen? Vilka minskar arbetstid? Vilka förbättrar kundservicen? Vilka krävs av lag eller drift? Vilka är bara "trevliga att ha"?
Och framför allt: hur vet vi att en funktion har lyckats?
Utan den sista frågan är det lätt att skapa en produkt som ständigt växer, men man vet aldrig om den faktiskt blivit bättre.
Produkten måste kunna säga "nej"
I bra produktutveckling är listan över saker vi inte bygger lika viktig som listan över saker vi bygger. Det kräver mod.
För det är lätt att säga: "Ja, vi gör det."
Svårare är att säga: "Baserat på det vi vet ser vi ännu ingen anledning att betala för det."
Ännu svårare att säga det till en kund som just kommit med en färdig idé.
Men just då börjar ett partnerskap.
Ett software house bör inte bara vara ett team som förvandlar instruktioner till kod. Det bör hjälpa kunden att fatta teknologiska beslut.
Ibland innebär det att designa funktionen.
Ibland förenkla den.
Ibland ersätta den med en annan lösning.
Och ibland att helt överge idén.
Hur känner man igen en funktion man sannolikt inte behöver?
Det finns inget magiskt test, men några frågor kan snabbt dämpa entusiasm.
Vem exakt kommer använda detta?
Om svaret är "alla" är det värt att specificera.
Vilket problem löser vi?
Om svaret är "det blir bekvämare" behöver problemet ofta ytterligare analys.
Hur ofta kommer användaren använda det?
En gång om året? En gång i månaden? Dagligen?
Finns det ett enklare sätt att lösa samma problem?
Denna fråga är särskilt viktig.
Hur mäter vi effekten?
Mer försäljning? Mindre arbete? Kortare process? Färre fel? Högre retention?
Vad händer om vi inte bygger den här funktionen?
Om svaret är "i princip inget" kanske vi just hittat en funktion som inte behöver byggas.
Inte varje användarförfrågan bör hamna i backloggen
Det är också en viktig mental förändring.
Användarfeedback är ovärderlig. Men feedback är inte en automatisk produkt-specifikation.
Användaren berättar om sitt problem ur sitt eget perspektiv.
Hen kan säga: "Jag behöver knapp X."
Produktteamets roll är inte att okritiskt skapa knapp X.
Teamets roll är att förstå: varför användaren behöver den.
Först då kan man avgöra om den bästa lösningen verkligen är knapp X.
Det kan vara automation.
Det kan vara integration.
Det kan vara förändring av process.
Det kan vara ett bättre gränssnitt.
Det kan vara användarutbildning.
Och ibland en ny funktion.
Det är skillnaden mellan feature delivery och product development.
Data kan också säga: "ta bort det"
Produktutveckling bör inte bara handla om att lägga till.
Man måste även se över vad som redan finns.
Vilka funktioner används?
Vilka ignoreras?
Var faller användarna ifrån?
Vilka processer tar mest tid?
Vilka element genererar flest supportärenden?
Vilka funktioner ökar konvertering?
Och vilka bara komplicerar gränssnittet?
Ibland är det bästa utvecklingsprojektet inte att lägga till en modul. Det är att ta bort tre onödiga. Det kan förbättra UX mer än ännu en månads utveckling.
AI kan också hjälpa här
Intressant nog behöver AI inte bara användas för att skapa funktioner.
Det kan också hjälpa till att analysera om funktioner är meningsfulla.
Det kan analysera användarfeedback.
Gruppera rapporter.
Identifiera återkommande problem.
Analysera supportdata.
Sammanfatta kundsamtal.
Hjälpa teamet jämföra hypoteser.
Ta fram lösningsvarianter.
Stödja analys av användarbeteende.
Paradoxalt nog kan det bästa användandet av AI i produktutveckling ibland vara inte att snabbare bygga nästa funktion, utan att snabbare upptäcka att vi inte borde bygga den.
Web24: först frågar vi "varför?"
Varje mjukvaruprojekt börjar från ett behov.
Ibland vet kunden exakt vad hen behöver.
Ibland har hen redan en färdig specifikation.
Ibland kommer hen bara med ett problem: "Den här processen tar oss tre timmar om dagen."
Det är en mycket bra utgångspunkt.
Då kan vi fundera inte på hur vi kodar en given lösning, utan hur vi bäst löser problemet.
Det är just detta som skiljer skräddarsydd mjukvara från att bygga en produkt av färdiga komponenter.
På Web24 handlar det inte om att varje app ska ha så många möjligheter som möjligt.
Det handlar om att den ska ha de möjligheter som faktiskt behövs för den specifika verksamheten.
Därför kan två liknande system se och fungera helt olika.
För deras processer skiljer sig.
Deras användare skiljer sig.
Deras mål skiljer sig.
Deras försäljningssätt skiljer sig.
Deras kundservice skiljer sig.
Och det problem mjukvaran ska lösa skiljer sig.
Den dyraste backloggen är den som ingen ifrågasätter
I AI-världen kan vi gå in i ett mycket intressant skede av mjukvaruutveckling.
Tekniken kommer bli allt bättre på frågan: "Hur bygger vi det?"
Och människan måste bli bättre på att svara på frågan: "Bör vi överhuvudtaget bygga det?"
Det kan bli en av de viktigaste förändringarna i hur vi skapar mjukvara.
För om kostnaden och tiden för att skapa en funktion sjunker, ökar frestelsen att lägga till dem.
Och med den ökar betydelsen av Product Discovery, UX, dataanalys, samtal med användare och ett strategiskt synsätt på produktutveckling. Gartner varnar att snabb produktutveckling drivs av AI kan leda bland annat till problem med strategisk anpassning och ökat technical debt om teknisk takt inte följs av produktstyrning.
Därför kommer framtiden inte bara tillhöra företag som kan bygga snabbare. Den kommer också tillhöra de som är bättre på att välja vad de bygger.
För ibland är det bästa tekniska beslutet inte: "Låt oss göra ännu en funktion."
Utan: "Låt oss först ta reda på om vi verkligen behöver den."
