Standish Group studerade en mängd avslutade mjukvaruprojekt och rapporterade en siffra som fortfarande får produktägare att rygga tillbaka: 64% av alla funktioner används sällan eller aldrig. Uppdelat: 45% används aldrig alls, 19% används sällan, och bara 17% används alltid eller ofta. Med andra ord är ungefär två tredjedelar av allt ett typiskt team bygger, ur användarens perspektiv, dekoration.
Det fyndet (först presenterat av Standishs ordförande Jim Johnson på konferensen XP 2002) är över två decennier gammalt, och det obekväma är att nyare data håller med. Slöseriet är inte ett fel i hur ett enskilt team arbetade. Det är standardutfallet av att bygga mycket innan man lärt sig något.
Det mesta du bygger kommer aldrig att användas
Modern analys berättar samma historia med större underlag. Produktplattformen Pendo, som tittade på anonymiserad användning över hundratals applikationer, fann att omkring 80% av alla funktioner sällan eller aldrig används, och att ungefär 12% av funktionerna driver 80% av den dagliga användningen. De satte också en prislapp på det: publika molnbolag lägger uppskattningsvis 29,5 miljarder dollar per år på funktioner som kunderna knappt rör.
Läs det som en planeringsbegränsning, inte ett moraliskt misslyckande. Före lansering vet ingen (inte heller du) tillförlitligt vilka 17% av funktionerna som kommer att spela roll. Du gissar. Frågan är om du lägger tolv månader på att agera på en gissning, eller tolv veckor på att testa den.
Kostnaden för att bygga sådant ingen vill ha
Funktionsdatan handlar om slöseri inuti produkter som åtminstone hittade en marknad. Den hårdare siffran handlar om produkter som inte gjorde det. I CB Insights analys av startup-obduktioner var den enskilt vanligaste orsaken till att bolag misslyckades att de byggde något ingen ville ha: 42% av de misslyckade startupbolagen angav "inget marknadsbehov".
Det är hela argumentet för MVP i en enda statistik. Den största risken i en ny produkt är nästan aldrig "kan vi bygga den?". Den är "vill någon ha den?". Varje extra funktion du skeppar innan du svarat på den andra frågan mångdubblar kostnaden för att ha fel, utan att förbättra dina chanser att ha rätt.
Så avgör du måste-ha mot trevligt-att-ha
"MVP" misstas för "billig och halvfärdig". Det är ingetdera. En riktig minsta gångbara produkt är det minsta som levererar kärnvärdet och låter dig lära av riktiga användare. Disciplinen ligger i att skära bort. Några frågor som gör skärandet åt dig:
- Tjänar den det enda kärnjobbet? Namnge det enda jobb användaren anställer din produkt för att göra. Stödjer en funktion inte direkt det jobbet är den en kandidat att skära bort, inte att bygga.
- Stoppar dess frånvaro lanseringen? Om svaret är nej är det ett trevligt-att-ha. Trevligt-att-ha är inte dåliga idéer. Det är bra idéer utan bevis ännu.
- Vad lär den dig? Föredra bygget som ger en tydlig signal (använde folk den? betalade de?) framför bygget som bara ger mer produkt.
- Kan den vänta på en riktig förfrågan? Många "nödvändiga" funktioner överlever just för att ingen användare någonsin ber dem motivera sin existens. Låt marknaden dra ut funktionerna ur dig.
Skär hårt, skeppa kärnan, och låt sedan användningsdata, inte åsikter på ett planeringsmöte, berätta vad du ska bygga härnäst.
Så tänker vi på True Dev
Vi har byggt mjukvara sedan 1997, och det mest värdefulla vi gör för en kund är ofta att prata bort dem från funktioner. Vi tänker produkt, inte bara kod. Det betyder att vi hjälper dig hitta kärnjobbet, skala en lansering du faktiskt kan skeppa, och designa den så att de första veckorna av riktig användning lär dig något. Målet är inte att skriva mindre mjukvara för sakens skull. Det är att lägga din budget på de 17% som spelar roll och upptäcka resten från användarna istället för att gissa.
Har du en produktidé är det billigaste misstaget det du fångar innan du bygger det. Starta ett projekt med oss så hjälper vi dig att skala den minsta lansering som bevisar poängen, eller titta på våra tjänster för att se hur vi arbetar.
