Het functieverzoek dat je echt zou moeten bouwen (en hoe je dat herkent)

Je weet hoe je nee zegt tegen slechte functieverzoeken. Je hebt geleerd scope creep te onderscheiden van kernfuncties. Je beschermt de grenzen van je product.

Maar nu zit je in een ander dilemma: je hebt een dozijn verzoeken die allemaal door de test komen. Ze zijn allemaal voor je app. Ze zijn allemaal redelijk. Het zijn allemaal dingen die je gebruikers echt willen. Maar je kunt er maar drie bouwen.

Welke drie?

Hier gaan de meeste productbeslissingen mis. Oprichters kiezen degene die het meest indrukwekkend klinken, of de meest winstgevende, of degene die van hun belangrijkste klant kwamen. Soms hebben ze gelijk. Meestal zitten ze ernaast.

De signalen die ertoe doen

Signaal 1: Ongevraagde herhaling

Als drie aparte gebruikers om hetzelfde vragen zonder met elkaar te praten, is dat een signaal. Ze hebben het niet afgestemd. Ze bedachten het allemaal gewoon. Als vijf gebruikers erom vragen, is dat geen toeval — dat is een oprechte behoefte.

Het omgekeerde is belangrijk: als één gebruiker het vraagt en niemand anders, en je bouwt het, dan onderhoud je nu een functie die niemand anders gebruikt en waar die ene gebruiker misschien nog steeds niet blij mee is (omdat je hem net iets verkeerd bouwde).

Tel verzoeken voordat je bouwt. Niet die van de luidste klant of je grootste klant — tel de ongevraagde herhaling. Twee of drie onafhankelijke gebruikers die om hetzelfde vragen, is een veel sterker signaal dan één belangrijke klant die om vijf dingen vraagt.

Signaal 2: De work-around doet ertoe

Als je gebruikers hebt en ze blijven ook al ontbreekt de functie, dan hebben ze een work-around gevonden. Misschien doen ze het buiten je app. Misschien doen ze het handmatig. Misschien gebruiken ze er parallel een andere tool naast.

Maar ze blijven, wat betekent dat ze de functie niet nodig hebben om je app te gebruiken. Ze hebben hem nodig om je app beter te gebruiken. Dat is anders dan een blokkade.

De functies die er het meest toe doen, zijn degene die voorkomen dat mensen je app überhaupt kunnen gebruiken. De functies die fijn zijn om te hebben, zijn degene waar mensen omheen werken.

Let op welke verzoeken blokkades zijn. Iemand zegt “ik kan dit niet gebruiken totdat je X doet” versus iemand zegt “het zou geweldig zijn als je X had”. Dat onderscheid is goud waard.

Signaal 3: De functie hangt samen met het verdienmodel

Sommige functies ontsluiten compleet nieuwe manieren om geld te verdienen. “Factureer mijn klanten” ontsluit een verdienmodel waarbij je voor facturering rekent. “Export naar Salesforce” ontsluit integratie-omzet. “White-label voor wederverkopers” ontsluit een partnerkanaal.

Maar hier is de truc: je weet niet of die modellen zullen werken totdat je al aan het lanceren bent. Je kunt er niet omheen plannen. Je kunt ze alleen opmerken na het lanceren en zien of mensen ze echt gebruiken.

De meest succesvolle functietoevoegingen zijn degene waarbij het lanceren van de functie een markt onthult waarvan je niet wist dat hij bestond. Je bouwde export. Blijkt dat bedrijven je export in hun workflow willen inbedden. Nu heb je een integratieverhaal dat je niet had gepland.

Bouw functies omdat je gebruikers ze nodig hebben. Kijk dan of je gebruikers ze nodig hebben op een manier die nieuwe business creëert. Voorspel niet eerst het verdienmodel.

Signaal 4: Het verzoek om hulp

Als een gebruiker je vraagt om iets te bouwen, is dat een verzoek. Als een gebruiker vraagt of je iets zou kunnen bouwen en aanbiedt te helpen testen, is dat anders.

Mensen die aanbieden te helpen testen, zijn mensen die geïnvesteerd zijn in de uitkomst. Ze zullen de functie zorgvuldig gebruiken. Ze zullen bugs melden. Ze zullen je vertellen of het hun probleem echt oplost.

Mensen die alleen verzoeken, zijn mensen die hopen dat je magisch zult bouwen wat ze zich voorstellen. Soms doe je dat. Vaak niet.

Bouw eerst met de testers. Al het andere is bijzaak.

De verleiding om de prestigefunctie te bouwen

Elk product heeft één functie die, als je hem lanceert, je indrukwekkender doet klinken. Voor planningsapps is het integreren met Calendly. Voor takenapps is het integreren met Slack. Iedereen weet wat die zijn. Iedereen wil ze.

Hier is het ding: iedereen krijgt ze ook van iemand anders. Als jouw functie niet de beste, makkelijkste integratie met Slack is, voegt hij alleen complexiteit toe aan je app zonder je beroemd te maken.

De functies die je beroemd maken, zijn degene die je uniek gepositioneerd bent om te bouwen omdat je de problemen van je specifieke gebruikers beter begrijpt dan wie dan ook. Dat zijn niet de prestigefuncties. Dat zijn de saaie functies die echte problemen oplossen voor echte mensen.

Slack-integratie is indrukwekkend. Een tool waarmee je gebruikers één specifiek ding veel sneller kunnen doen dan Slack ooit overwoog, is waardevol.

Hoe je echt beslist

Wanneer je een batch functieverzoeken hebt die allemaal door de “valt dit binnen de scope?”-test komen, rangschik ze op:

1. Hoeveel gebruikers vroegen erom (onafhankelijk)? Meer is beter.
2. Is dit een blokkade of een nice-to-have? Blokkades zijn urgenter.
3. Kunnen je gebruikers hier vandaag omheen werken? Zo niet, dan is het belangrijker.
4. Wil iemand je helpen dit te testen? Zo ja, bouw het eerst.
5. Onthult dit een nieuwe markt? Zo misschien, dan is dat een bonus, geen reden.

Bouw dan in die volgorde. Niet de volgorde van indrukwekkend-klinkend. Niet de volgorde van je grootste klant. De volgorde van het echte signaal van de mensen die je app gebruiken.

De functie die je (nog) niet bouwt

Je krijgt verzoeken die het niet halen. Doe niet alsof je ze ooit zult bouwen. Vertel de gebruiker: “We bouwen dat nu niet. Hier is waarom. Hier is wat we wel bouwen. Hier is een alternatief dat voor jou zou kunnen werken.”

Die eerlijkheid doet er meer toe dan je denkt. Gebruikers weten liever dat je het niet gaat doen dan zes maanden hopend te wachten.

En soms, zodra je nee hebt gezegd, vindt de gebruiker een work-around, of een andere tool, of lost hij het probleem op een andere manier op. Dat is oké. Je kunt niet alles voor iedereen zijn.

De producten die winnen, zijn degene die hun taak goed doen en zorgvuldig luisteren naar wat gebruikers echt nodig hebben, niet degene die alles proberen te zijn en uiteindelijk niets worden.