Hoe je beslist welke gebruikersfeedback je bouwt (en welke je loslaat)
Zodra mensen je app gebruiken, beginnen de verzoeken binnen te stromen. Dit is een simpele manier om te beslissen welke gebruikersfeedback het waard is om te bouwen met je AI-appbouwer, welke je parkeert, en tegen welke je beleefd nee zegt.
De eerste paar weken nadat mensen je app beginnen te gebruiken, zijn rustig. Dan beginnen de berichten. “Kun je een donkere modus toevoegen?” “Het zou geweldig zijn als ik naar pdf kon exporteren.” “Kun je de knop blauw maken?” “We hebben echt integraties nodig met de tool die we al gebruiken.” Binnen een maand heb je een lijst van veertig dingen, en een AI-appbouwer die er met plezier in een middag elke van zal bouwen.
Dat laatste deel is de valkuil. Wanneer elke functie bouwen goedkoop en snel is, houdt de moeilijke vraag op “kan ik dit bouwen?” te zijn en wordt “zou ik dat moeten?” De flessenhals verschuift van je handen naar je oordeel, en niemand overhandigt je daar een gids voor.
Deze post is een simpele manier om binnenkomende feedback in drie stapels te sorteren — bouw het, parkeer het, laat het los — zonder een productmanagement-achtergrond nodig te hebben. Het doel is niet om nee te zeggen tegen mensen. Het is om ervoor te zorgen dat de dingen die je wel bouwt de dingen zijn die je app echt vooruit helpen.
Waarom “bouw het gewoon” stopt met werken
Voor je eerste tien functies is “bouw gewoon wat iemand vraagt” een prima strategie. Je hebt niet genoeg gebruikers om tegenstrijdige meningen te hebben, en elke functie maakt de app nuttiger dan het lege ding dat hij vorige week was.
Het stopt met werken rond de tijd dat je echte, verschillende gebruikers hebt. Een freelancer wil het ene, een klein bureau wil het tegenovergestelde, en een eenmalige bezoeker wil iets dat geen van beiden ooit zal gebruiken. Bouw alle drie en je app verandert in een rommellade — vol met spul, moeilijk om iets te vinden, zwaar om te dragen. Elke functie die je toevoegt, is een functie die je voor altijd werkend moet houden, aan nieuwe gebruikers moet uitleggen, en niet moet breken wanneer je iets ernaast verandert.
Een AI-appbouwer maakt dit erger voordat het het beter maakt, want het verwijdert de natuurlijke rem. Toen een functie een ontwikkelaar twee weken kostte, dacht je goed na over de vraag of het twee weken waard was. Wanneer het de bouwer twintig minuten kost, denk je helemaal niet na — je zegt gewoon ja. De kosten verdwenen niet. Ze verschoven van “tijd om te bouwen” naar “gewicht om te dragen”, en gewicht is moeilijker te zien.
Drie vragen die bijna alles sorteren
Wanneer een verzoek binnenkomt, voer het door drie vragen op volgorde. De meeste dingen sorteren zichzelf na de eerste twee.
1. Helpt dit de mensen voor wie ik dit bouwde? Je bouwde je app voor iemand specifieks — trouwfotografen, jeugdvoetbaltrainers, indie-podcasthosts. Een verzoek van een van die mensen is meer waard dan een verzoek van iemand die binnenliep en nooit terugkomt. Als een functie je kernmensen helpt het hoofdding te doen waarvoor ze kwamen, gaat hij naar de top. Als hij een bezoeker helpt die niet echt je gebruiker is, gaat hij naar de bodem, hoe luid ze ook vroegen.
2. Hoeveel mensen zullen hem echt gebruiken? Niet “wie vroeg erom” — wie zal hem gebruiken. Eén persoon die luid vraagt, is niet hetzelfde als tien mensen die er stilletjes baat bij zouden hebben. Wees hier eerlijk, want luide verzoeken voelen als grote verzoeken, en dat zijn ze meestal niet. Een goede aanwijzing: vraag de persoon wat ze vandaag in plaats daarvan doen. Als ze een onhandige work-around hebben die ze dagelijks gebruiken, is dat een echte behoefte. Als ze “het waarschijnlijk soms zouden gebruiken”, is het een nice-to-have in een kostuum.
3. Wat kost het me om hem voor altijd te dragen? Sommige functies zijn licht. Een nieuwe kleuroptie, een herwoord label, een extra veld op een formulier — bouw het en vergeet het. Sommige functies zijn zwaar: alles dat betalingen raakt, alles dat e-mail naar echte mensen stuurt, alles dat een hele nieuwe sectie met zijn eigen regels toevoegt. Zware functies zijn niet slecht, maar ze zouden hun gewicht moeten verdienen door de eerste twee vragen ruim te doorstaan.
De drie stapels
Voer die vragen uit en bijna alles belandt op een van drie plekken.
Bouw het. Helpt je kernmensen, meerdere van hen zullen hem gebruiken, en de kosten om te dragen zijn redelijk. Deze zijn makkelijk. Doe ze, en vertel de persoon die het vroeg — mensen die hun idee gelanceerd zien, worden je meest loyale gebruikers en je beste bron voor het volgende goede idee.
Parkeer het. Goed idee, maar het is vroeg, of slechts één persoon wil het, of het is zwaar en je weet het nog niet zeker. Zeg geen nee en bouw het niet. Schrijf het ergens op waar je echt zult kijken — een simpele lijst, een notitie, een bord. Als er de komende maand nog drie mensen om hetzelfde vragen, promoveerde het zichzelf zojuist naar de bouwstapel en vertelde je dat. Parkeren is geen kerkhof; het is een wachtkamer.
Laat het los. Het past niet bij waar je app voor is, het zou alleen ooit één persoon bedienen, of het zou de app voor iedereen anders slechter maken. Deze hebben een beleefd, eerlijk nee nodig. “Dat is een doordacht idee, maar het is niets dat ik van plan ben toe te voegen — hier is wat ik in plaats daarvan zou voorstellen” behoudt de relatie en beschermt de app. Nee zeggen is een functie. Elke nee is een ja tegen de app simpel genoeg houden dat mensen hem begrijpen.
Een klein voorbeeld
Iemand die we kennen runt een boekingsapp voor muziekdocenten, volledig gebouwd met een AI-appbouwer. In één week kreeg ze drie verzoeken: een docent wilde automatische herinneringsberichten naar studenten, een ouder wilde een manier om alle lessen van hun kinderen in één weergave te zien, en één persoon wilde de app vertaald naar het Latijn “voor de lol”.
De herinneringen doorstonden alle drie de vragen — kerngebruikers, velen ervan hebben te maken met no-shows, en sms is zwaar maar het waard. Gebouwd. De ouderweergave was een goed idee van één persoon, dus parkeerde ze hem; twee ouders extra vroegen binnen drie weken en het promoveerde zichzelf. De Latijnse vertaling kreeg een warm nee. Geen van die beslissingen had een spreadsheet nodig. Ze hadden drie vragen nodig en de bereidheid om de derde eerlijk te beantwoorden.
Het deel dat niemand je vertelt
De moeilijkste feedback om af te handelen, zijn niet de slechte ideeën. Het zijn de goede ideeën van mensen die je mag, voor een app die niet alles kan zijn. Die loslaten voelt als de persoon teleurstellen. Dat is het niet. Het vriendelijkste dat je kunt doen voor de mensen die je app gebruiken, is hem gefocust genoeg houden dat hij goed blijft in het ene ding waarvoor ze kwamen.
De volgende keer dat de verzoeken zich opstapelen, open niet eerst je AI-appbouwer. Open je lijst, voer elk item door de drie vragen, en sorteer het in een stapel. Het bouwen is nu het makkelijke deel. Beslissen wat het waard is om te bouwen, is het echte werk — en het is werk dat je kunt doen zonder ook maar één regel code te schrijven.