Funktionsönskemålet du faktiskt borde bygga (och hur du känner igen det)

Du vet hur man säger nej till dåliga funktionsönskemål. Du har lärt dig att skilja scope creep från kärnfunktioner. Du skyddar din produkts gränser.

Men nu sitter du i en annan knipa: du har ett dussin önskemål som alla klarar testet. De är alla till din app. De är alla rimliga. De är alla saker som dina användare faktiskt vill ha. Men du kan bara bygga tre av dem.

Vilka tre?

Det är här de flesta produktbeslut går fel. Grundare väljer dem som låter mest imponerande, eller mest lönsamma, eller dem som kom från deras viktigaste kund. Ibland har de rätt. Oftast har de fel.

Signalerna som spelar roll

Signal 1: Spontan upprepning

Om tre separata användare ber om samma sak utan att ha pratat med varandra är det en signal. De koordinerade inte. De kom alla bara på det. Om fem användare ber om det är det inte ett sammanträffande — det är ett genuint behov.

Det omvända är viktigt: om en användare ber och ingen annan gör det, och du bygger det, så underhåller du nu en funktion som ingen annan använder och som den ena användaren ändå kanske inte är nöjd med (eftersom du byggde den lite fel).

Räkna önskemålen innan du bygger. Inte dem från den högljuddaste kunden eller din största klient — räkna den spontana upprepningen. Två eller tre oberoende användare som ber om samma sak är en mycket starkare signal än en viktig kund som ber om fem saker.

Signal 2: Provisorierna spelar roll

Om du har användare och de stannar kvar trots att funktionen saknas, har de hittat ett provisorium. Kanske gör de det utanför din app. Kanske gör de det manuellt. Kanske använder de ett annat verktyg parallellt.

Men de stannar, vilket betyder att de inte behöver funktionen för att använda din app. De behöver den för att använda din app bättre. Det är skillnad från ett hinder.

Funktionerna som spelar störst roll är de som hindrar folk från att använda din app överhuvudtaget. Funktionerna som är trevliga att ha är de som folk hittar provisorier kring.

Var uppmärksam på vilka önskemål som är hinder. Någon säger “jag kan inte använda det här förrän du gör X” jämfört med någon som säger “det vore toppen om du hade X”. Den distinktionen är guld värd.

Signal 3: Funktionen hänger ihop med affärsmodellen

Vissa funktioner låser upp helt nya sätt att tjäna pengar. “Fakturera mina kunder” låser upp en affärsmodell där du tar betalt för fakturering. “Exportera till Salesforce” låser upp integrationsintäkter. “White-label för återförsäljare” låser upp en partnerkanal.

Men här är knepet: du vet inte om de modellerna kommer att fungera förrän du redan lanserar. Du kan inte planera kring dem. Du kan bara märka dem efter att du lanserat och sett om folk faktiskt använder dem.

De mest framgångsrika funktionstilläggen är de där lanseringen av funktionen avslöjar en marknad du inte visste fanns. Du byggde export. Det visar sig att företag vill bädda in din export i sitt arbetsflöde. Nu har du en integrationsberättelse du inte planerade.

Bygg funktioner för att dina användare behöver dem. Sedan håll utkik efter om dina användare behöver dem på ett sätt som skapar ny affär. Förutsäg inte affärsmodellen först.

Signal 4: Erbjudandet att hjälpa till

Om en användare ber dig bygga något är det ett önskemål. Om en användare frågar om du skulle kunna bygga något och erbjuder sig att hjälpa till att testa det, är det annorlunda.

Folk som erbjuder sig att hjälpa till att testa är folk som är investerade i utfallet. De använder funktionen omsorgsfullt. De rapporterar buggar. De berättar för dig om den faktiskt löser deras problem.

Folk som bara önskar är folk som hoppas att du magiskt bygger det de föreställer sig. Ibland gör du det. Ofta gör du det inte.

Bygg med testarna först. Allt annat är sekundärt.

Frestelsen att bygga prestigefunktionen

Varje produkt har en funktion som, om du lanserar den, får dig att låta mer imponerande. För bokningsappar är det att integrera med Calendly. För uppgiftsappar är det att integrera med Slack. Alla vet vad de är. Alla vill ha dem.

Här är grejen: alla får dem också från någon annan. Om din funktion inte är den bästa, enklaste integrationen med Slack, så lägger den bara till komplexitet i din app utan att göra dig berömd.

Funktionerna som gör dig berömd är de som du är unikt positionerad att bygga eftersom du förstår dina specifika användares problem bättre än någon annan. Det är inte prestigefunktionerna. Det är de tråkiga funktionerna som löser riktiga problem för riktiga människor.

Slack-integration är imponerande. Ett verktyg som låter dina användare göra en specifik sak mycket snabbare än Slack någonsin tänkte på är värdefullt.

Hur du faktiskt bestämmer dig

När du har en hög funktionsönskemål som alla klarar “är det här inom omfattningen?”-testet, rangordna dem efter:

1. Hur många användare bad om det (oberoende av varandra)? Fler är bättre.
2. Är det ett hinder eller trevligt att ha? Hinder är mer akuta.
3. Kan dina användare hitta ett provisorium kring det idag? Om inte är det viktigare.
4. Kommer någon att hjälpa dig testa det? Om ja, bygg det först.
5. Kommer det att avslöja en ny marknad? Om kanske, är det en bonus, inte ett skäl.

Bygg sedan i den ordningen. Inte i ordningen efter vad som låter imponerande. Inte i ordningen efter din största kund. I ordningen efter faktisk signal från folk som använder din app.

Funktionen du inte ska bygga (än)

Du kommer att ha önskemål som inte når hela vägen. Låtsas inte att du bygger dem någon dag. Berätta för användaren: “Vi bygger inte det just nu. Här är varför. Här är vad vi bygger. Här är ett alternativ som kanske fungerar för dig.”

Den ärligheten spelar större roll än du tror. Användare vill hellre veta att du inte tänker göra det än vänta i sex månader och hoppas.

Och ibland, när du väl sagt nej, hittar användaren ett provisorium, eller ett annat verktyg, eller löser problemet på ett annat sätt. Det är okej. Du kan inte vara allt för alla.

Produkterna som vinner är de som gör sitt jobb väl och lyssnar noga på vad användare faktiskt behöver, inte de som försöker vara allt och slutar med att vara ingenting.