De scope creep-valkuil: hoe je nee zegt tegen functies die goed klinken maar het niet zijn
Je bouwde iets waar gebruikers van houden. Nu willen ze functies die redelijk klinken maar de app tien kanten op zouden trekken. Zo bepaal je welke verzoeken je bouwt en welke je beleefd afwijst.
Je hebt een app gelanceerd. Gebruikers kwamen opdagen. En nu zit je inbox vol met verzoeken om functies die allemaal als goede ideeën klinken.
“Kunnen we export naar Excel toevoegen?” Redelijk. “Kunnen facturen automatisch worden verstuurd?” Logisch. “Kunnen we integreren met Stripe?” Daar zit het echte geld. “Kun je een mobiele app toevoegen?” Iedereen vraagt daarom. “Kunnen we dit white-labelen voor onze eigen klanten?” Oh, nu is er een verdienmodel.
Elk verzoek klinkt op zichzelf slim. Samen klinkt het alsof je vijf verschillende producten aan het bouwen bent.
Dit is scope creep, en het doodt meer kleine met AI gebouwde apps dan technische problemen ooit zullen doen. Niet omdat je de functies bouwt — maar omdat je tijd, geld of je verstand verliest tijdens de poging.
Hoe scope creep een werkende app doodt
Dit is wat er gebeurt. Je zegt ja tegen de eerste drie verzoeken omdat ze redelijk lijken. Je vraagt je AI-bouwer ze toe te voegen. Het duurt twee weken in plaats van één omdat elke nieuwe functie tegen de bestaande code aan botst. Nu heb je een app die vijf dingen doet, en drie ervan goed en twee oké.
Dan komt verzoek vier: “Kunnen we verschillende rechtenniveaus hebben?” Opeens moet je heroverwegen wie wat kan zien op elk scherm. Dat is geen functie; dat is een architectuurverandering. Je vraagt je AI-bouwer het te doen. Het raakt alles. Twee weken worden drie. De app wordt trager omdat je aan elke weergave logica hebt toegevoegd.
Tegen verzoek acht ben je gestopt met het lanceren van nieuwe dingen voor je oorspronkelijke gebruikers, omdat je het te druk hebt om de functieverzoekmachine draaiende te houden. De mensen die drie maanden geleden van de app hielden, zijn gefrustreerd omdat niets waar ze om vroegen af is. De mensen die nieuwe verzoeken doen, zijn gefrustreerd omdat functies eindeloos duren.
Je bouwde iets dat werkt. Je brak het door alles te willen zijn.
Het beslissingskader
Je hebt een poort nodig. Elk functieverzoek gaat door drie vragen:
Vraag 1: Hoort dit thuis in deze app, of is het een andere app?
Je eerste app doet één taak heel goed. Een planningsapp plant dingen. Een factureringsapp factureert. Het zijn verschillende apps. Als iemand je planningsapp vraagt om te factureren, voeg je geen functie toe — je vraagt een planningsapp om boekhouding te doen. Dat is een ander product.
Een goede test: “Als ik deze functie nam en op zichzelf zou lanceren, zouden mensen die dan willen kopen?” Zo ja, dan hoort hij waarschijnlijk in een andere app. Als het antwoord is “nee, het slaat alleen ergens op als onderdeel van het grotere geheel”, dan bouw je de juiste scope.
Je krijgt verzoeken als “integreer met ons CRM”. Wat dat eigenlijk betekent, is “wees je eigen CRM”. Dat is een andere app. Je kunt later integreren met een CRM. Je kunt niet een CRM aan functies toevoegen zonder een CRM te worden.
Vraag 2: Lost dit een probleem op voor de meeste van je gebruikers, of alleen voor deze ene?
Eén klant houdt van je app en heeft een functie-idee. Het is een echt probleem dat ze hebben. Het is ook een echt probleem dat alleen zíj hebben.
Als je twintig gebruikers hebt en één vraagt om iets, check dan: zitten de andere negentien hier ook op te wachten, of bedacht deze persoon het zojuist? Je kunt het ze direct vragen: “Heb je, voordat je het mij vroeg, overwogen iemand anders te vragen of die het nodig heeft?” Meestal is het antwoord nee.
Dit is de gevaarlijke vraag, omdat de ene klant die het vraagt je belangrijkste klant kan zijn. Misschien moet je ze tevreden houden. Dat is een zakelijke beslissing, geen productbeslissing. Maar ga er met open ogen in: als je iets bouwt voor één klant, groei je je app niet, je bouwt een adviespraktijk.
Vraag 3: Wat kost dit en wat zijn de kosten voor het oorspronkelijke idee?
Alles kost iets. Export naar Excel kost je engineeringtijd. Het kost je app complexiteit. Het kost focus. Bouw dat in plaats van een prestatieoptimalisatie waar je gebruikers dagelijks over klagen, en je hebt een keuze gemaakt.
Vraag concreet: “Als ik dit bouw, wat bouw ik dan niet?” Als het antwoord is “niets, we hebben oneindig tijd”, ben je niet eerlijk. Die hebben we niet. Tijd is eindig.
De kosten voor het oorspronkelijke idee zijn vaak onzichtbaar. Wanneer je diep in functieverzoeken zit, stop je met het onderhouden van het kernding waar mensen van hielden. De kern wordt trager. De kern wordt buggier. De kern voelt verwaarloosd. En uiteindelijk vertrekken mensen omdat de app die geweldig werkte nu oké werkt en dingen doet waarvoor hij nooit was ontworpen.
Een echt voorbeeld: het intakeformulier
Iemand bouwde een eenvoudig intakeformulier voor klanten. Klanten vullen het in, de coach beoordeelt het, ze plannen in. Dat is de app.
Verzoek één: “Kan ik urgente intakes markeren?” Ja, dat is een variatie op de kernworkflow. Bouw het.
Verzoek twee: “Kan ik intakes exporteren naar Excel voor mijn administratie?” Dit is een documentfunctie. Het is niet de taak van de app. Intakes leven in de app. Als ze Excel nodig hebben, kunnen ze knippen en plakken. Maar oké, export slaat misschien ergens op als gemak. Bouw het.
Verzoek drie: “Kunnen intakes automatisch agenda-afspraken aanmaken?” Nu doe je planning. De app was voor intake, niet voor planning. Als iemand beide wil, willen ze waarschijnlijk een echt planningssysteem, geen hack die er eentje aan vastlijmt. Wijs het beleefd af.
Verzoek vier: “Kunnen coaches intake-vervolgberichten via sms sturen?” Nu ben je een communicatiesysteem. Nee.
Tegen verzoek drie heb je de grens bereikt. De app is intake. Al het andere is een andere app. Je kunt later integreren met die apps. Je kunt ze niet toevoegen zonder die apps te worden.
Hoe je nee zegt
Het moeilijkste is het daadwerkelijk zeggen. Je wilt je gebruikers niet frustreren.
Wees eerlijk: “Dat is een geweldig idee, maar het is een ander product dan wat we hier bouwen. Wat we bouwen is [jouw ene taak]. Als we planning of facturering of CRM-dingen proberen te doen, zijn we oké in alles en geweldig in niets.”
Vaak zal de klant het begrijpen. Ze vroegen omdat het idee bij ze opkwam, niet omdat ze je op de proef stellen.
Soms zullen ze terugduwen. “Maar ik heb beide nodig.” Dat is wanneer je aanbeveelt: gebruik de echte planningsapp. Gebruik de echte factureringsapp. Gebruik het echte CRM. Gebruik dan deze app voor wat hij goed doet. Dat is het eerlijke antwoord.
De verleiding om alles te zijn
Het moeilijkste aan het bouwen van een klein product is nee zeggen. Nee voelt als geld op tafel laten liggen. Wat als die klant echt voor beide had betaald? Wat als die functie je tien keer groter had gemaakt?
Misschien. Maar je bent geen tien keer groter product als je het niet lanceert. Je bent een half-afgemaakt product dat vijf dingen slecht doet. De mensen die van de kern hielden, zijn gefrustreerd. De mensen die de nieuwe functies wilden, zijn gefrustreerd. En je hebt jezelf in een hoek geschilderd waar iets nieuws toevoegen betekent dat je eerst vijf oude dingen moet refactoren.
De producten die groeien, zijn die welke één taak heel goed doen, en dan zorgvuldig toevoegen. Ze proberen niet vanaf dag één Salesforce te zijn. Ze zijn de app waar je naar grijpt als je dat ene ding moet doen, en de app die je vertrouwt om snel en betrouwbaar te zijn wanneer je het doet.
Zeg nee. Bescherm de kern. Doe dat, en je bouwt iets dat mensen echt willen gebruiken.