Bouwen in plaats van verkopen is de overtuigendste vorm van uitstelgedrag die een founder heeft, want er blijft iets echts van over. Je voegt een feature toe, de app wordt echt beter en je hebt het gevoel dat je gewerkt hebt. Maar als niemand de laatste vijf dingen heeft gebruikt die je bouwde, is het zesde geen productwerk.
Het is vermijding met een commitgeschiedenis. Het eerlijke signaal dat je dit doet is simpel: je blijft een product verbeteren dat bijna niemand heeft gezien.
Moet ik features bouwen of klanten zoeken
Als je het moet vragen, weet je het al. Wat je verraadt, is niet de vraag, maar je reflex zodra outreach ongemakkelijk wordt. De feature request voelt dringend, de roadmap loopt achter en het volgende ding bouwen voelt als de verantwoorde keuze. Niets daarvan gaat over de klant.
Het gaat erover dat jij je prettiger voelt in je editor dan in iemands inbox.
Dit is de simpele versie. Zolang echte mensen niet hebben gebruikt wat je al hebt, kunnen meer features je niets vertellen. Je geeft antwoorden op vragen die nog niemand heeft gesteld. De enige informatie die in het begin telt, komt van iemand buiten je eigen hoofd die het ding aanraakt en daarna blijft of vertrekt.
Tot dat gebeurt, is elke feature een gok bovenop een gok.
Hoe zie ik het verschil tussen bouwen om te vermijden en echt productwerk
Echt productwerk begint bij een persoon. Iemand gebruikte het product, liep tegen een muur, vertelde het je of liet het zien met wat hij deed, en jij lost precies die muur op. Bouwen om te vermijden begint bij denkbeeldige mensen. Je stelt je een gebruiker voor die dit zou willen en je bouwt voor hem.
Het verschil zit erin of je kunt zeggen voor wie de feature is en kunt aanwijzen wanneer die persoon hem nodig had. Is het antwoord hypothetisch ("een gebruiker wil misschien naar CSV exporteren"), dan is het een gok.
Is het antwoord concreet ("drie van de zeven mensen die het probeerden vroegen in dezelfde week om CSV"), dan is het werk. Zeven mensen is genoeg om op te handelen. Nul mensen is geen kleinere versie van zeven. Het is een andere categorie, en geen enkele hoeveelheid bouwen verandert dat.
Een feature waar niemand om vroeg is geen vooruitgang. Het is een inzet op tafel voordat er iemand kwam zitten.
Feature creep zonder gebruikers
Feature creep met gebruikers is een kwestie van discipline. Feature creep zonder gebruikers is een kwestie van verstoppen, en dat is erger, want het voelt als het tegenovergestelde van verstoppen. Je produceert. De repo is druk. De changelog is lang.
En al die tijd blijft het echte knelpunt liggen: een vreemde naar het ding laten kijken. Het is de enige taak zonder code om te schrijven en zonder duidelijk gevoel dat hij af is.
Ik heb een instellingenpagina gerefactord om maar geen vijf berichten te hoeven sturen. Die berichten hadden me iets geleerd. De instellingenpagina leerde me niets, behalve dat ik goed ben in berichten ontwijken.
Heb je ooit je databaseschema omgegooid op een dag dat je jezelf outreach had beloofd, dan ken je dat gevoel precies, en je weet dat het geen deugd is.
Stop met bouwen, begin met verkopen: de regel die echt werkt
Wilskracht lost dit niet op, want bouwen voelt echt goed en verkopen voelt echt slecht. Je hebt een regel nodig die de beslissing voor je neemt, dus dit is de regel die ik gebruik. Hij heeft bewust maar één bewegend onderdeel.
Geen nieuwe feature tot N van de juiste mensen de huidige hebben gezien.
Dat is de hele regel. De uitwerking eromheen:
- Kies N en de persoon. Klein en echt. Zoiets als "twintig solo founders die hun eigen outbound doen." Geen markt, maar een persoon die je voor je ziet. Als je ze niet voor je ziet, kun je ze ook niet tellen.
- "Gezien" betekent gebruikt, niet bezocht. Een paginaweergave is geen persoon. Aangemeld, rondgeklikt, of jij liep het samen met ze door. Dat telt als gezien.
- Wat je nu hebt, ligt vast tot je N haalt. Bugs die gebruik blokkeren mag je fixen. Oppoetsen, nieuwe onderdelen, het ding dat je zo graag wilt bouwen: allemaal op slot.
- Haal je N, lees dan eerst wat er gebeurde voordat je bouwt. Wat deden ze, waar liepen ze vast, waar vroegen ze twee keer om. Nu heb je een lijst die van buiten je hoofd komt.
- Dan, en pas dan, bouw je het bovenste punt. En de teller gaat terug naar nul. De volgende feature wacht op de volgende N.
De regel werkt omdat de ongemakkelijke taak de enige taak wordt die open staat. Je wilt bouwen, en de enige weg terug naar bouwen loopt dwars door de outreach die je steeds vermeed. Het is geen gevecht met je wilskracht meer, het is een poort.
Waar een tool past, en waar niet
Je kunt deze regel vandaag draaien met niets meer dan een spreadsheet en je eigen inbox, en dat moet je ook doen, in elk geval tot mensen het ding laten zien de enige stap is die nog misgaat. Als je probleem is dat je blijft bouwen in plaats van shippen, lost geen software dat op. De poort hierboven is gratis, en hij is de hele oplossing.
De enige plek waar een tool zijn geld waard is, is stap twee, waar "gezien" moet betekenen dat N echte mensen echt keken. Met de hand schaalt dat niet. Een echte walkthrough voor één persoon kost tien minuten, twintig ervan kosten je hele week, en dus verandert het stilletjes in een algemene massamail die niemand bekijkt.
Voor die muur heb ik Personade gebouwd. Ja, dat is dus nog iets wat ik bouwde in plaats van te verkopen. Het verschil is dat het bestaat om je terug te duwen naar versturen.
Het draait je outreach op LinkedIn: het connectieverzoek, het bericht en de follow-ups, verstuurd vanaf je eigen account, en het stopt zodra iemand antwoordt. Is een walkthrough je bericht, dan geeft een video-add-on elke lead een eigen versie met een opening die alleen voor hem bedoeld is, en laat je zien wie keek. Dat is het signaal "gezien", voor je geteld.
Wat het niet doet: je outreach schrijven, je N kiezen, of een product dat niemand wil veranderen in een product dat mensen wel willen. Die delen blijven bij jou.
Wil je de uitgebreide versie van waarom deze verschuiving gebeurde, dan schreef ik over waarom bouwen gratis werd en verkopen niet. En als het diepere probleem is dat je distributie helemaal hebt overgeslagen, begin dan daar.
Veelgestelde vragen
Moet ik meer features bouwen of me richten op klanten? Eerst klanten, bijna altijd. Een feature leert je pas iets als echte mensen het product hebben gebruikt en je hebben laten zien waar het breekt. Zonder gebruikers is een nieuwe feature een gok zonder iets om hem aan te toetsen. Stel een regel die je kunt handhaven: geen nieuwe feature tot een vast aantal van de juiste mensen de huidige echt heeft gebruikt.
Hoe weet ik of ik bouw om verkopen te vermijden? Stel twee vragen over de feature. Voor wie is hij, en wanneer liepen ze tegen de muur die hij oplost. Kun je echte mensen en het precieze moment noemen, dan is het productwerk. Is de gebruiker hypothetisch en is het moment "ooit", dan is het vermijding. Drukke repo's en lange changelogs voelen als vooruitgang, maar meten niets zolang niemand het product heeft gezien.
Wat is een goede regel tegen feature creep zonder gebruikers? Zet het product vast tot een vast aantal van de juiste mensen heeft gebruikt wat je al bouwde. Kies iets kleins en echts, zoals twintig. "Gebruikt" betekent dat ze zich aanmeldden en rondklikten, niet dat ze een pagina bezochten. Pas als je dat aantal haalt, lees je wat ze deden en bouw je het vaakst gevraagde punt. Daarna gaat de teller terug naar nul en begin je opnieuw.
De features waar je trots op bent, zijn onzichtbaar voor iedereen behalve jou, tot iemand buiten je hoofd een reden heeft om ze aan te raken. Dat is geen bouwprobleem, en het bouwprobleem heb je al opgelost.
Het is de enige taak zonder duidelijk gevoel dat hij af is, en precies daarom verliest hij steeds van de taak die dat gevoel wel geeft. Zet deze week die poort voor jezelf neer en laat hem beslissen.