De belangrijkste productbeslissing is wat je niet bouwt

Vraag een team wat ze dit jaar hebben opgeleverd en je krijgt een lijst. Vraag wat ze hebben geschrapt en het wordt stil in de kamer.

Er zijn twee dingen waar ik bewust een streep door heb gezet tijdens het werken aan consumentenapps voor financiële diensten:

• Een "documentenhub".
• Een "meldingencentrum".

Je kunt ze je waarschijnlijk allebei voorstellen. Naar mijn mening zijn dit beide voorbeelden van het laten ontsnappen van de organisatie aan haar verantwoordelijkheid, ten koste van de gebruiker. Hoewel het eerlijk is om te zeggen dat veel gebruikers inmiddels getraind zijn om deze dingen te verwachten en ongeveer weten hoe ze werken — ook al zijn ze waardeloos.

Het onderliggende probleem is echter reëel. Het bedrijf heeft legacy-systemen die PDF's produceren — brieven, afschriften, dat soort zaken — omdat deze oorspronkelijk per post zouden worden verzonden. Compliance-experts zullen het ook hebben over "permanente communicatiekanalen". Je hebt dus ergens in de app een plek nodig om dat allemaal onder te brengen.

De luie oplossing is een documentenhub: een lijst met bestanden die je kunt selecteren en openen. Dat lijkt simpel.

Behalve dat elke betrokken stakeholder een "Columbo" wil uithangen en nog één dingetje wil toevoegen. Tegen de tijd dat het af is, heb je in feite Google Drive herbouwd, inclusief tagging, archivering, printen en delen via verschillende kanalen, elk met zijn eigen eigenaardigheden. Om nog maar niet te spreken van het overwinnen van de beveiligings- en authenticatiehordes, zodat de juiste persoon alleen de juiste documenten ziet. En zo gaat het maar door.

En dat is alleen al om het ding te bouwen.

Neem nog maar eens de overhead die je creëert om het manad na maand, jaar na jaar te onderhouden, telkens wanneer er een nieuwe iOS-releasecyclus aan komt en een eigenaardigheid waar je op vertrouwde om een stukje functionaliteit overeind te houden, eenzijdig wordt verwijderd door Apple. Of Google, of Microsoft, of Amazon.

Het meldingencentrum is hetzelfde verhaal, alleen met een andere openingszin. Een stakeholder vraagt of we niet gewoon een bel-icoontje met een klein rood stipje in de rechterbovenhoek van het scherm kunnen hebben. Geef het een paar maanden en je bent bezig met het bouwen van een slechte Gmail-kloon.

De rekening laten zien

Ik ben nu meerdere malen tegen beide scenario's aangelopen. Het is niet makkelijk om mensen een mentaal model te laten loslaten dat ze in hun hoofd hebben, vooral wanneer een focusgroep van klanten dit model in zekere mate valideert. De clichématige uitspraak van Henry Ford komt hierbij in gedachten: als je mensen had gevraagd wat ze wilden, hadden ze gezegd: snellere paarden, geen auto.

Wat volgens mij echt werkt, is het illustreren van de operationele kosten. Niet de bouwkosten, maar de onderhoudskosten over meerdere jaren. Dat brengt mensen meestal wel terug van de rand van de afgrond.

Maar het schrappen van het platform lost het oorspronkelijke probleem niet op. Hoe communiceren we met onze klanten op een manier die hen schikt en die voldoet aan onze wettelijke verplichtingen?

Het antwoord waar ik telkens op uitkom, is om elk scenario afzonderlijk te beoordelen. Wees strikt in wat er daadwerkelijk gezegd moet worden, en wanneer. Wees vervolgens meedogenloos in de vraag of daarvoor eerst een heel platform gebouwd moet worden. Het is dezelfde test die ik hanteer bij het kiezen van de juiste problemen om op te lossen: maakt het de boot sneller?

De meeste tijd — niet altijd, om eerlijk te zijn — is het antwoord om iets simpels te gebruiken, of iets dat al bestaat, zelfs als dat niet perfect is.

Verzet je, verzet je, verzet je tegen de verleiding om een one-size-fits-all oplossing te bouwen.

Ik heb zelfs gezien dat een meldingencentrum werd gebouwd, waarna bleek dat de intentie van het oorspronkelijke bericht niet kon worden vervuld door het systeem dat juist gebouwd was om dat bericht te dragen.

Mijn advies bestaat daarom uit twee delen: wees uiterst kieskeurig over wat je toelaat in je systeem, en wees militant in het verwijderen van zaken.

Niemand wordt gepromoveerd voor het verwijderen van zaken

Het tweede deel is veel moeilijker dan het eerste, en dat komt niet simpelweg door angst. Gerry McGovern zegt hier al lange tijd het volgende:

Degenen die creëren en lanceren zijn de mensen die worden beloond en bewonderd, omdat we nog steeds een cultuur hebben die de productie van zaken boven alles waardeert. Het beoordelen, het onderhouden, het verwijderen — dit alles wordt gezien als minderwaardig werk.

Zijn Top Tasks-onderzoek wees uit dat het strippen van ongeveer 80 tot 90 procent van de inhoud van een website ervoor zorgde dat bedrijven meer verkochten, minder supportgesprekken kregen en dat mensen sneller vonden wat ze zochten. Verwijdering als de verbetering op zich, niet als het opruimen achteraf. Ik heb dit argument op kleinere schaal al eens gebruikt bij het verwijderen van de FAQ-pagina.

En dit gaat dieper dan het organogram. Klotz en collega's schreven in Nature over acht experimenten waarbij bleek dat mensen systematisch subtractieve wijzigingen over het hoofd zien, zelfs wanneer weglaten overduidelijk de betere zet was. Additieve ideeën komen snel en goedkoop. Subtractieve ideeën kosten echte cognitieve inspanning. We zijn hier simpelweg biologisch op geprogrammeerd.

Dit betekent dat het hersenvermogen nodig is om uit te zoeken wat succes werkelijk inhoudt. En succes is meestal iets dat zich afspeelt in de wereld van de klant, in plaats van in de wereld van de organisatie.

Maar bouwen is tegenwoordig bijna gratis, toch?

DHH is dolenthousiast over eindeloze executie — in het tijdperk van AI-agents is elk idee, elke intuïtie en elk experiment direct binnen handbereik. Ik denk dat het makkelijk is om dat te misinterpreteren als een argument om constant meer spullen te maken.

Het gebruik van agents voor het snoeien lijkt mij een slimmere zet. Om het onderhoud te doen. Om dingen doelgericht en zorgvuldiger te verwijderen dan wie dan ook met de hand zou kunnen.

Het werk Maintenance of Everything van Stewart Brand rust op de paradox dat onderhoud absoluut noodzakelijk is en tegelijkertijd volledig optioneel. Of liever gezegd: optioneel totdat het essentieel wordt.

De olifant in de coltrui

De olifant in de kamer, gehuld in een op maat gemaakte zwarte Issey Miyake-coltrui, is natuurlijk de matrix van Steve Jobs uit 1997. Twee consumentenproducten, twee professionele producten, en één sterproduct in elk vak.

De productmatrix van Steve Jobs (1997)

	Consument	Professional
Desktop	iMac	Power Macintosh
Portable	iBook	PowerBook

Vier vakken. Eén product in elk. Al het andere werd geschrapt.

Hij stopte vervolgens alle andere productlijnen waar mensen aan werkten. Hierdoor werd het engineeringtalent gebundeld in plaats van versnipperd. Het was een dappere zet, en het werkte.

Apple heeft inmiddels ongeveer 52 verschillende producten en diensten, dus het einddoel was nooit om slechts vier dingen te verkopen. Het punt was om de organisatie te focussen op de belangrijkste zaken, zodat ze de opportuniteitskosten niet verspilden — de kosten die hen in staat stelden een van de grootste corporaties ter wereld te worden.

Eén ding tegelijk. Une chose à la fois.

(Ik had een korter bericht geschreven, maar ik kon niet bedenken wat ik eruit moest halen.)