De meest productieve spanning in product teams is niet tussen engineering en design. Het is tussen maximizers en focusers.

Maximizers neigen naar snelheid, optionaliteit, parallelle bets. Focusers naar diepte, coherentie, minder doen voor meer.

Geen van beide heeft gelijk. Beide creëren waarde en risico.

Dit verklaart waarom sommige conflicten onoplosbaar voelen. Een maximizer ziet een focuser momentum doden. Een focuser ziet een maximizer vertrouwen verbranden voor korte termijn winst. Verschillende talen over wat “goed” betekent.

Ik ben een maximizer. Mijn instinct is “waarom niet beide?” Parallelle bets brengen kansen aan het licht die je mist met pure focus. Maar maximizen zonder beperking creëert ondiepe vooruitgang overal en diepe vooruitgang nergens.

Weten wanneer te maximizen en wanneer te focussen. Dat is de vaardigheid.

De slimste persoon in de kamer is niet altijd de meest waardevolle. De persoon die daadwerkelijk iets doet wel.

High agency is het geloof dat je kunt handelen, gecombineerd met de wil om door te zetten. Niet wachten op instructies. Niet vragen om toestemming voor elk detail. Een probleem zien en besluiten: ik los dit op.

Intelligentie zonder actie is potentiële energie die nooit converteert naar beweging. Je kunt briljant zijn en niks bereiken. Je kunt gemiddeld intelligent zijn en enorm veel voor elkaar krijgen.

Waarom is agency zo zeldzaam? We hebben decennia geoptimaliseerd voor compliance. Scholen belonen goede antwoorden op gestelde vragen, niet het stellen van interessante vragen. Bedrijven kochten gehoorzaamheid per kilo. Volg het proces, doe wat je gezegd wordt, wijk niet af.

Dat trainde agency eruit.

De mensen die vooruitkomen zijn degenen die het terug trainen. Die bias naar actie boven analyse kiezen. Die shippen en dan verbeteren in plaats van eindeloos plannen.

Analysis paralysis is comfortabel. Actie is eng. Maar actie is wat telt.

Er is een verschil tussen prompten tot iets werkt en engineering met AI-assistentie.

De eerste is hacken. Je probeert dingen tot het lukt, kopieert code die je niet begrijpt, en hoopt dat het blijft werken. Dat is prima voor experimenten en prototypes. Het is niet hoe je productiesoftware bouwt.

De tweede is wat Willison “vibe engineering” noemt. Je gebruikt AI als tool, maar de engineering fundamentals blijven. Tests schrijven. Code reviewen. Begrijpen wat je shipt. Verantwoordelijkheid nemen voor het resultaat.

De ironie: AI-tools maken engineering fundamentals belangrijker, niet minder. Als je code sneller kunt genereren, wordt de bottleneck het valideren van die code. En valideren vereist begrip.

Engineers die hun vak kennen krijgen leverage van AI. Ze kunnen meer doen, sneller. Engineers die alleen op AI leunen zonder de fundamentals, bouwen kaarthuizen.

Het speelveld wordt niet genivelleerd. Het wordt verbreed. De vraag is aan welke kant je staat.

Talent wordt vaak gezien als individuele capaciteit. Hoe slim is iemand? Hoe vaardig? Hoeveel ervaring?

Maar talent in isolatie is weinig waard. Wat ertoe doet is alignment. Past wat iemand kan en wil bij wat de organisatie nodig heeft?

Een briljante engineer die verkeerde problemen oplost is minder waardevol dan een goede engineer die de juiste problemen oplost. Een ervaren consultant die tegen de cultuur in werkt bereikt minder dan een junior die erin past.

De implicatie: “talent aannemen” is niet genoeg. Je moet talent aannemen dat aligned is met waar je naartoe wilt. En alignment verandert over tijd. Iemand die perfect paste in de startup-fase past misschien niet in de scale-up fase.

Het verklaart ook waarom sommige mensen ergens floreren en ergens anders vastlopen. Het is niet dat ze opeens minder capabel zijn. De alignment is weg.

AI coding tools beloven 10x snelheid. Wat ze vaak leveren is 10x meer code om te begrijpen en te onderhouden.

De valkuil zit niet in de AI. Het zit in hoe we het gebruiken. Als je AI behandelt als een code-generator die output produceert, krijg je precies dat: meer output. Meer bestanden, meer functies, meer regels. Maar meer code is niet hetzelfde als betere software.

Het probleem verschuift. In plaats van code schrijven, ben je nu code reviewen. Code die je niet zelf schreef, die patronen volgt die je niet koos, die aannames maakt die je niet valideerde.

De paradox: hoe sneller je code genereert, hoe meer tijd je kwijt bent aan begrijpen wat er gegenereerd is.

Wat werkt is AI gebruiken als denkpartner, niet als typist. Laat het meedenken over architectuur, edge cases, alternatieve aanpakken. De waarde zit in de dialoog, niet in de output.

Ive vertelt over een moment vroeg bij Apple. Steve Jobs vroeg of hij iets wilde proberen. Ive zei simpelweg: “Yes.”

Geen voorbehouden. Geen “laat me erover nadenken.” Geen “wat als het niet werkt?” Gewoon ja.

De meeste mensen aarzelen. Ze wachten op meer informatie, willen zekerheid voordat ze committen. Maar zekerheid komt zelden vooraf. Die bouw je achteraf, door te doen en bij te sturen.

Het is makkelijk om dit af te doen als roekeloosheid. Dat is het niet. Ja zeggen zonder alle antwoorden te hebben is vertrouwen dat je het uitzoekt als het nodig is. Het is geloven dat je capabel genoeg bent om problemen op te lossen die je nog niet kent.

Nee zeggen is veilig. Je kunt niet falen aan iets waar je niet aan begint. Maar je kunt ook niet groeien aan iets waar je niet aan begint.

Soms is “yes” het enige antwoord dat ertoe doet.

Het verschil tussen managen en leiden wordt zichtbaar onder druk.

Managers trekken zich terug in controlemodus. Meer regels, meer checkpoints, meer rapportages. Het voelt productief maar het signaleert wantrouwen.

Leiders stappen in vertrouwensmodus. Ze leggen de situatie uit, vragen om input, en geven mensen ruimte om te handelen. Het voelt kwetsbaar maar het bouwt eigenaarschap.

Het scherpste contrast: informatie. Managers behandelen details als machtsmiddel. Hoe minder anderen weten, hoe afhankelijker ze zijn. Leiders doen het omgekeerde. Ze delen alles wat relevant is en vertrouwen erop dat mensen er goed mee omgaan.

Waar het echt op aankomt is ongemak. Moeilijke gesprekken, slecht nieuws, conflicten. Managers vermijden ze of verpakken ze in processen. Leiders leunen erin, direct maar met zorg. “Dit is moeilijk, maar ik geef om je, dus laten we praten.”

Dat is leiderschap gedestilleerd. Niet de makkelijke dingen goed doen. De moeilijke dingen niet uit de weg gaan.

ChatGPT onthoudt dingen over je. Het bouwt een profiel op basis van je gesprekken en past toekomstige antwoorden daarop aan. Handig, maar ook een beetje ongemakkelijk als je niet precies weet wat het onthoudt.

Claude doet het anders. Elke conversatie start vers. Geen automatisch profiel, geen onzichtbare personalisatie. Als je wilt dat Claude iets onthoudt, moet je het expliciet vragen.

De designkeuze is interessant. De meeste AI-bedrijven optimaliseren voor gemak. Anthropic lijkt te optimaliseren voor voorspelbaarheid en controle.

In professionele context is dat waardevoller dan het klinkt. Je wilt weten wat het model weet. Je wilt niet verrast worden door aannames gebaseerd op een gesprek van drie weken geleden dat je vergeten bent.

Het is een trade-off. Minder magische personalisatie, meer transparantie. Voor casual gebruik is ChatGPT’s aanpak prettiger. Voor werk waar consistentie en controle ertoe doen, voelt Claude’s aanpak beter.

Collison’s advies gaat tegen de standaard carrièrewijsheid in.

Ga vroeg diep op meerdere dingen. De vraag “specialist of generalist?” is verkeerd gesteld. Doe beide. Word heel goed in twee of drie dingen in plaats van oké in tien. Vroege expertise compoundeert. De opties die het creëert kun je later niet meer bouwen.

Status loopt achter op realiteit. De veilige carrièrepaden van vandaag zijn gebaseerd op de wereld van gisteren. Banking, dan consulting, dan big tech. Elke generatie denkt dat hun veilige keuze voor altijd zal duren. Dat is zelden waar.

Bouw netwerken online. De beste kansen komen via mensen die je digitaal ontmoet, niet via lokale koffiemeetings. Remote werk heeft de geografie van opportunity veranderd. Beperk jezelf niet tot je stad.

Vermijd treinspoor-denken. Studie, master, corporate, promotie. Het voelt veilig omdat iedereen het doet. Maar dat is precies waarom het risicovol is. Je concurreert met iedereen op hetzelfde spoor. De interessante kansen zitten op paden waar minder mensen lopen.

Als je de massa volgt, concurreer je met de massa. Als je op jezelf wedt, concurreer je met bijna niemand.

Slootman runt bedrijven anders. Geen consensuscultuur, geen eindeloze meetings, geen iedereen-blij-houden. Focus en executie.

Over gedrag versus prestatie: prestatie is iets waar je tijd voor geeft. Iemand kan groeien in hun rol. Gedrag is een keuze. Als iemand zich misdraagt, is dat geen ontwikkelpunt. Het is een beslissing die ze maken.

Over prioriteren: niet kiezen is het ergste wat je kunt doen. Dan compromitteer je alles. Alles een beetje doen betekent niets goed doen. Kies, commit, executeer.

Over ambitie: het komt voort uit een gebrek aan aanpassing. Een perfect gebalanceerd persoon zou geen ambitie hebben. Waarom zou je? Je bent tevreden. Maar mensen met ambitie hebben een kloof tussen waar ze zijn en waar ze willen zijn. Die kloof drijft ze.

Over sales: geweldige verkopers kunnen geen slecht product verkopen. Maar slechte verkopers kunnen wel een geweldig product verkopen. Het product doet het zware werk. Sales kan het alleen versnellen of vertragen.

Over hiring: langzamer maar beter aannemen. De kosten van een verkeerde hire zijn enorm. Niet alleen in geld, maar in tijd, energie, en teamdynamiek. Wachten op de juiste persoon is bijna altijd beter dan snel de verkeerde aannemen.

Veel mensen speculeren over AI die coderen vervangt. Minder praten over hoe het vandaag werkt. Dit is wat we zien bij het gebruik van Cursor en Claude Code in een 12 jaar oude SaaS met ongeveer 40 developers.

Productiviteit is omhoog—misschien 20 procent maar ongelijk. Agents zijn geweldig voor refactors, klusjes en ideeën deblokkeren. Ze zijn zwakker bij subtiele bug fixes en schrijven geen mooie code.

De grootste winst is ambitie. Solo developers shippen nu projecten die vroeger een team kostten. Kosten zijn laag—onze zwaarste Claude-gebruikers geven amper vijftig dollar per maand uit.

Het moeilijke deel van programmeren is nog steeds beslissen wat de software moet doen. Ideeën omzetten in syntax wordt alleen maar sneller.

Je hebt coördinaten: 52.3676, 4.9041. Je wilt een adres: Amsterdam, Nederland. Simpel toch?

Niet echt. Welk adres? Het dichtstbijzijnde gebouw? De straat? De wijk? De stad? Het land? Het hangt af van wat je gebruiker nodig heeft, en dat verschilt per context.

Nog lastiger: grenzen zijn fuzzy. Sta je in Amsterdam of in Amstelveen? De gemeentegrens loopt soms door een parkeerplaats. Postcodes overlappen niet altijd netjes met wijken. Sommige adressen bestaan officieel niet maar worden wel gebruikt.

De technische uitdaging is niet het algoritme. Het is beslissen wat “correct” betekent voor jouw use case. En dat is een productbeslissing, geen engineering beslissing.

Mooie reminder dat ogenschijnlijk simpele features vaak politieke en UX-vragen verbergen die niemand vooraf bedacht had.

Horowitz schreef dit in 1996. Het is nog steeds relevant.

Het onderscheid is simpel. Een goede product manager gedraagt zich als de CEO van het product. Niet in de zin van autoriteit, maar in de zin van eigenaarschap. Alles wat misgaat is hun probleem. Alles wat goed gaat is het team.

Een slechte product manager heeft excuses. Engineering leverde niet. Sales beloofde dingen die niet konden. Marketing begreep de positioning niet. Altijd iemand anders.

Dit geldt direct voor CRM-implementaties. De beste CRM-architecten nemen dezelfde houding aan. Ze anticiperen op wat gebruikers nodig hebben voordat die erom vragen. Ze focussen op business outcomes, niet op technische specs of feature checklists.

Een CRM dat technisch perfect is maar niet gebruikt wordt, is een mislukt CRM. Net zoals een product met geweldige features dat niemand koopt een mislukt product is.

De vraag is niet “werkt het?” maar “lost het het probleem op waarvoor we het bouwden?” Goede product managers en goede CRM-architecten blijven die vraag stellen tot het antwoord ja is.

OpenAI’s gids snijdt door de hype. Agents zijn geen magie. Het zijn loops die tools aanroepen tot een taak klaar is.

De kern: geef een model toegang tot tools, laat het beslissen welke tool te gebruiken, voer de tool uit, geef het resultaat terug aan het model, herhaal tot klaar. Dat is een agent.

Waar het interessant wordt is de orkestratie. Wanneer geef je de agent vrijheid en wanneer dwing je structuur af? Te veel vrijheid en het model hallucineert paden die nergens toe leiden. Te veel structuur en je had net zo goed een script kunnen schrijven.

De praktische les: begin klein. Eén tool, één taak, duidelijke grenzen. Voeg complexiteit toe als je begrijpt waar het misgaat. De meeste agent-projecten falen niet door te weinig capabilities, maar door te veel.

Werner Vogels schreef zeven wetten voor kostenbewuste architectuur. De kern: kosten zijn een architectuurbeslissing, geen afterthought.

De eerste wet is het belangrijkst. Maak kosten een non-functional requirement. Net zoals je performance en security meeneemt in design, neem je kosten mee. Niet pas als de rekening komt, maar vooraf.

De tweede wet: observeer en meet wat je spendeert. Je kunt niet optimaliseren wat je niet meet. Dit klinkt voor de hand liggend, maar de meeste teams weten niet wat hun systeem kost per transactie, per gebruiker, per feature.

Wat dit relevant maakt voor CRM-implementaties: dezelfde principes gelden. Een CRM dat €100 per gebruiker per maand kost maar half gebruikt wordt, is slecht ontworpen. Niet technisch, maar economisch.

De les is breder dan cloud architectuur. Elke systeem dat je bouwt heeft een kostenkant. Negeer je die, dan ontdek je het te laat.

De meeste managers focussen op wat misgaat. Begrijpelijk. Problemen vragen om aandacht. Maar het effect is dat mensen alleen van je horen als er iets fout is.

Sinek draait het om. Betrap mensen op het goed doen van dingen. Niet wachten tot de jaarlijkse review, maar in het moment. “Dit deed je goed, en dit is waarom het ertoe doet.” Het inspireert de persoon en het signaleert naar het team wat gewenst gedrag is.

Over feedback: we geven het vaak zoals we het zelf willen ontvangen. Dat is de fout. De vraag is hoe de ander het wil horen. Sommige mensen willen directheid. Anderen hebben tijd nodig om zich voor te bereiden. “Is dit een goed moment?” of een agenda-afspraak kan het verschil maken tussen feedback die landt en feedback die afketst.

Timing ook. Tenzij iets urgent of gevaarlijk is, bewaar verbeterpunten tot het einde van de dag. Laat iemand focussen op het werk zonder onderbroken te worden door kritiek. Later is er ruimte voor reflectie.

Het grotere punt: interesse tonen in wie iemand wil worden, niet alleen wat iemand voor je doet. Waar dromen ze van? Wat willen ze bereiken, ook buiten het werk? Het doel is niet alleen dat iemand presteert. Het is dat iemand de organisatie verlaat als een betere versie van zichzelf, omdat ze zich gesteund voelden in hun groei.

Dat is de maatstaf. Niet of je targets hebt gehaald. Of de mensen die voor je werkten er beter van werden.