Fällan med skenande omfattning: så säger du nej till funktioner som låter bra men inte är det
Du byggde något användarna älskar. Nu vill de ha funktioner som låter rimliga men som skulle dra appen i tio olika riktningar. Så här avgör du vilka önskemål du ska bygga och vilka du artigt ska tacka nej till.
Du lanserade en app. Användarna kom. Och nu är din inkorg full av funktionsönskemål som alla låter som bra idéer.
“Kan vi lägga till export till Excel?” Rimligt. “Kan fakturor skickas automatiskt?” Logiskt. “Kan vi integrera med Stripe?” Det är där de riktiga pengarna finns. “Kan du lägga till en mobilapp?” Alla ber om det. “Kan vi white-label:a det här för våra egna kunder?” Oj, nu finns det en affärsmodell.
Varje önskemål låter smart för sig självt. Tillsammans låter de som att du bygger fem olika produkter.
Det här är skenande omfattning, och det dödar fler små AI-byggda appar än vad tekniska problem någonsin gör. Inte för att du bygger funktionerna — utan för att du får slut på tid, pengar eller förstånd när du försöker.
Hur skenande omfattning dödar en fungerande app
Så här går det till. Du säger ja till de tre första önskemålen för att de verkar rimliga. Du ber din AI-byggare lägga till dem. Det tar två veckor istället för en eftersom varje ny funktion krockar med den befintliga koden. Nu har du en app som gör fem saker, gör tre av dem bra och två av dem hyfsat.
Sedan kommer önskemål fyra: “Kan vi ha olika behörighetsnivåer?” Plötsligt måste du tänka om vem som får se vad på varje skärm. Det är inte en funktion; det är en arkitekturförändring. Du ber din AI-byggare göra det. Den rör allt. Två veckor blir tre. Appen blir långsammare eftersom du har lagt till logik i varje vy.
Vid önskemål åtta har du slutat leverera nya saker till dina ursprungliga användare eftersom du är för upptagen med att hålla funktionsönskemålsmaskinen igång. Folk som älskade appen för tre månader sedan är frustrerade eftersom inget de bad om blir klart. Folk som lägger nya önskemål är frustrerade eftersom funktionerna tar en evighet.
Du byggde något som fungerar. Du gjorde sönder det genom att försöka vara allt.
Beslutsramverket
Du behöver en grind. Varje funktionsönskemål går igenom tre frågor:
Fråga 1: Hör det här hemma i den här appen, eller är det en annan app?
Din första app gör ett jobb riktigt bra. En bokningsapp bokar saker. En faktureringsapp fakturerar. Det är olika appar. Om någon ber din bokningsapp att fakturera lägger du inte till en funktion — du ber en bokningsapp att sköta bokföring. Det är en annan produkt.
Ett bra test: “Om jag tog den här funktionen och lanserade den fristående, skulle folk vilja köpa den?” Om ja, hör den förmodligen hemma i en annan app. Om svaret är “nej, det är bara meningsfullt som en del av den större grejen”, då bygger du rätt omfattning.
Du kommer få önskemål som “integrera med vårt CRM.” Vad det egentligen betyder är “var ditt eget CRM.” Det är en annan app. Du kan integrera med ett CRM senare. Du kan inte lägga till ett helt CRM:s funktioner utan att bli ett CRM.
Fråga 2: Löser det här ett problem för de flesta av dina användare, eller bara för den här enda?
En kund älskar din app och har en funktionsidé. Det är ett verkligt problem de har. Det är också ett verkligt problem som bara de har.
Om du har tjugo användare och en ber om något, kolla: väntar de andra nitton på det här också, eller kom den här personen just på det? Du kan fråga dem direkt: “Innan du frågade mig, har du funderat på att fråga någon annan om de behöver det här?” Oftast är svaret nej.
Det här är den farliga frågan eftersom den enda kund som frågar kan vara din viktigaste kund. Du kanske behöver hålla dem nöjda. Det är ett affärsbeslut, inte ett produktbeslut. Men gå in med öppna ögon: om du bygger något för en enda kund växer du inte din app, du bygger en konsultverksamhet.
Fråga 3: Vad kostar det här, och vad kostar det den ursprungliga idén?
Allt kostar något. Export till Excel kostar dig ingenjörstid. Det kostar din app komplexitet. Det kostar fokus. Bygg det istället för en prestandaförbättring som dina användare klagar på dagligen, så har du gjort ett val.
Fråga konkret: “Om jag bygger det här, vad bygger jag inte?” Om svaret är “inget, vi har oändligt med tid” är du inte ärlig. Det har vi inte. Tid är ändlig.
Kostnaden för den ursprungliga idén är ofta osynlig. När du är djupt nere i funktionsönskemål slutar du underhålla den kärngrej folk älskade hos dig. Kärnan blir långsammare. Kärnan blir buggigare. Kärnan känns försummad. Och till slut försvinner folk eftersom appen som fungerade jättebra nu fungerar hyfsat och gör saker den aldrig var byggd för.
Ett verkligt exempel: intagsformuläret
Någon byggde ett enkelt intagsformulär för klienter. Klienterna fyller i det, coachen granskar det, de bokar tid. Det är appen.
Önskemål ett: “Kan jag markera brådskande intag?” Ja, det är en variation av kärnflödet. Bygg det.
Önskemål två: “Kan jag exportera intag till Excel för mina anteckningar?” Det här är en dokumentfunktion. Det är inte appens jobb. Intagen finns i appen. Om de behöver Excel kan de kopiera och klistra in. Men okej, export kan vara meningsfullt som en bekvämlighet. Bygg det.
Önskemål tre: “Kan intag automatiskt skapa kalenderhändelser?” Nu sysslar du med bokning. Appen var till för intag, inte bokning. Om någon vill ha båda vill de förmodligen ha ett riktigt bokningssystem, inte ett hack som limmar fast ett. Tacka artigt nej.
Önskemål fyra: “Kan coacher skicka uppföljning på intag via SMS?” Nu är du ett kommunikationssystem. Nej.
Vid önskemål tre har du nått gränsen. Appen är intag. Allt annat är en annan app. Du kan integrera med de apparna senare. Du kan inte lägga till dem utan att bli de apparna.
Hur man säger nej
Det svåraste är att faktiskt säga det. Du vill inte frustrera dina användare.
Var ärlig: “Det är en bra idé, men det är en annan produkt än den vi bygger här. Det vi bygger är [ditt enda jobb]. Om vi försöker sköta bokning eller fakturering eller CRM-grejer blir vi hyfsade på allt och bra på inget.”
Ofta kommer kunden förstå. De frågade för att idén dök upp hos dem, inte för att de testar dig.
Ibland kommer de protestera. “Men jag behöver båda.” Det är då du rekommenderar: använd den riktiga bokningsappen. Använd den riktiga faktureringsappen. Använd det riktiga CRM:et. Använd sedan den här appen för det den gör bra. Det är det ärliga svaret.
Frestelsen att vara allt
Det svåraste med att bygga en liten produkt är att säga nej. Nej känns som att lämna pengar på bordet. Tänk om den kunden verkligen skulle ha betalat för båda? Tänk om den funktionen skulle ha gjort dig tio gånger större?
Kanske. Men du är inte en tio-gånger-större produkt om du inte levererar den. Du är en halvfärdig produkt som gör fem saker dåligt. Folk som älskade kärnan är frustrerade. Folk som ville ha de nya funktionerna är frustrerade. Och du har målat in dig i ett hörn där varje nytt tillägg innebär att du först måste bygga om fem gamla saker.
Produkterna som växer är de som gör ett jobb riktigt bra, och sedan lägger till försiktigt. De försöker inte vara Salesforce från dag ett. De är appen du griper efter när du behöver göra just den där grejen, och appen du litar på är snabb och pålitlig när du gör det.
Säg nej. Skydda kärnan. Gör det, så bygger du något folk faktiskt vill använda.