Så avgör du vilken användarfeedback du ska bygga (och vilken du ska släppa)
När folk väl börjar använda din app börjar önskemålen strömma in. Här är ett enkelt sätt att avgöra vilken användarfeedback som är värd att bygga med din AI-appbyggare, vilken du ska parkera och vilken du artigt ska säga nej till.
De första veckorna efter att folk börjat använda din app är tysta. Sedan börjar meddelandena. “Kan ni lägga till mörkt läge?” “Det vore toppen om jag kunde exportera till PDF.” “Kan ni göra knappen blå?” “Vi behöver verkligen integrationer med verktyget vi redan använder.” Inom en månad har du en lista på fyrtio saker, och en AI-appbyggare som gärna bygger vilken som helst av dem åt dig på en eftermiddag.
Den sista delen är fällan. När det är billigt och snabbt att bygga varje funktion slutar den svåra frågan vara “kan jag bygga det här?” och blir “borde jag?”. Flaskhalsen flyttar från dina händer till ditt omdöme, och ingen ger dig en guide till det.
Det här inlägget är ett enkelt sätt att sortera inkommande feedback i tre högar — bygg det, parkera det, släpp det — utan att du behöver en bakgrund inom produktledning. Målet är inte att säga nej till folk. Det är att se till att sakerna du faktiskt bygger är sakerna som verkligen för din app framåt.
Varför “bygg det bara” slutar fungera
För dina tio första funktioner är “bygg bara vad än någon ber om” en helt okej strategi. Du har inte tillräckligt många användare för att ha motstridiga åsikter, och varje funktion gör appen mer användbar än den tomma sak den var förra veckan.
Det slutar fungera ungefär när du har riktiga, olika användare. En frilansare vill ha en sak, en liten byrå vill ha motsatsen, och en engångsbesökare vill ha något som ingen av dem någonsin kommer att använda. Bygg alla tre och din app förvandlas till en skräplåda — full av grejer, svår att hitta något i, tung att bära. Varje funktion du lägger till är en funktion du måste hålla igång för alltid, förklara för nya användare och inte ha sönder när du ändrar något i närheten.
En AI-appbyggare gör det här värre innan den gör det bättre, eftersom den tar bort den naturliga bromsen. När en funktion tog en utvecklare två veckor tänkte du noga på om den var värd två veckor. När den tar byggaren tjugo minuter tänker du inte alls — du säger bara ja. Kostnaden försvann inte. Den flyttade från “tid att bygga” till “vikt att bära”, och vikt är svårare att se.
Tre frågor som sorterar nästan allt
När ett önskemål kommer in, kör det genom tre frågor i ordning. De flesta saker sorterar sig själva efter de två första.
1. Hjälper det här de jag byggde det för? Du byggde din app för någon specifik — bröllopsfotografer, ungdomstränare i fotboll, indie-poddvärdar. Ett önskemål från en av de personerna är värt mer än ett önskemål från någon som råkade titta in och aldrig kommer tillbaka. Om en funktion hjälper dina kärnpersoner att göra huvudsaken de kom för, hamnar den högt upp. Om den hjälper en besökare som egentligen inte är din användare, hamnar den långt ner, hur högljutt de än bad om den.
2. Hur många kommer faktiskt att använda den? Inte “vem bad om den” — utan vem som kommer att använda den. En person som ber högljutt är inte samma sak som tio personer som tyst skulle ha nytta av den. Var ärlig här, för högljudda önskemål känns som stora önskemål, och det är de oftast inte. Ett bra tecken: fråga personen vad de gör i stället idag. Om de har en klumpig nödlösning de använder dagligen är det ett verkligt behov. Om de “förmodligen skulle använda den ibland” är det en trevlig-att-ha i förklädnad.
3. Vad kostar det mig att bära den för alltid? Vissa funktioner är lätta. Ett nytt färgval, en omformulerad etikett, ett extra fält på ett formulär — bygg det och glöm det. Vissa funktioner är tunga: allt som rör betalningar, allt som skickar mejl till riktiga människor, allt som lägger till en hel ny sektion med sina egna regler. Tunga funktioner är inte dåliga, men de bör förtjäna sin vikt genom att klara de två första frågorna med god marginal.
De tre högarna
Kör de frågorna så hamnar nästan allt på ett av tre ställen.
Bygg det. Hjälper dina kärnpersoner, flera av dem kommer att använda det, och kostnaden att bära är rimlig. De här är enkla. Gör dem, och berätta för personen som frågade — folk som ser sin idé levererad blir dina mest lojala användare och din bästa källa till nästa bra idé.
Parkera det. Bra idé, men det är tidigt, eller bara en person vill ha det, eller det är tungt och du är inte säker än. Säg inte nej och bygg det inte. Skriv ner det någonstans där du faktiskt kommer att titta — en enkel lista, en anteckning, en tavla. Om tre personer till ber om samma sak under nästa månad har det precis befordrat sig självt till bygg-högen och berättat det för dig. Parkering är ingen kyrkogård; det är ett väntrum.
Släpp det. Det passar inte vad din app är till för, det skulle bara någonsin tjäna en person, eller det skulle göra appen sämre för alla andra. De här behöver ett artigt, ärligt nej. “Det är en genomtänkt idé, men det är inget jag planerar att lägga till — här är vad jag skulle föreslå i stället” bevarar relationen och skyddar appen. Att säga nej är en funktion. Varje nej är ett ja till att hålla appen enkel nog att folk förstår den.
Ett litet exempel
Någon vi känner driver en bokningsapp för musiklärare, helt byggd med en AI-appbyggare. På en vecka fick hon tre önskemål: en lärare ville ha automatiska påminnelse-sms till elever, en förälder ville kunna se alla sina barns lektioner i en enda vy, och en person ville ha appen översatt till latin “för skojs skull”.
Påminnelserna klarade alla tre frågorna — kärnanvändare, många av dem brottas med uteblivna bokningar, och sms är tungt men värt det. Byggt. Förälderns vy var en bra idé från en person, så hon parkerade den; två föräldrar till frågade inom tre veckor och den befordrade sig själv. Den latinska översättningen fick ett varmt nej. Inget av de besluten krävde ett kalkylark. De krävde tre frågor och viljan att besvara den tredje ärligt.
Det ingen berättar för dig
Den svåraste feedbacken att hantera är inte de dåliga idéerna. Det är de bra idéerna från folk du gillar, för en app som inte kan vara allt. Att släppa dem känns som att svika personen. Det gör det inte. Det snällaste du kan göra för folk som använder din app är att hålla den fokuserad nog att den förblir bra på den enda sak de kom för.
Nästa gång önskemålen hopar sig, öppna inte din AI-appbyggare först. Öppna din lista, kör varje punkt genom de tre frågorna och sortera in den i en hög. Byggandet är den lätta delen nu. Att avgöra vad som är värt att bygga är det egentliga jobbet — och det är ett jobb du kan göra utan att skriva en enda rad kod.