Notities over het bouwen van een stil product

Mole voor Mac passeerde ongeveer drie weken na de lancering een kleine verkoopmijlpaal. In plaats van over de cijfers te schrijven, wil ik een paar keuzes opschrijven die ik onderweg maakte, omdat de meeste ingaan tegen de instincten van een werkende engineer, en het de keuzes zijn die ik als eerste zou verdedigen. Als je je eigen product bouwt, bespaart een deel hiervan je misschien een omweg.

Ik beantwoord elke e-mail zelf

Elk stuk support sinds de lancering is met de hand afgehandeld: terugbetalingen, activatie-resets, een prijsverschil terugbetalen na een korting, gewone vragen. Het volume is klein, ruim onder één procent van de gebruikers schrijft ooit, en ik had in een halfuur een agent kunnen aansluiten om het af te handelen. Ik koos daar niet voor, om twee redenen.

Ten eerste is support de plek waar het product je de waarheid vertelt. Een verzoek om terugbetaling zegt waarom het product iemand teleurstelde. Een onhandige vraag zegt welk deel van de app zichzelf niet uitlegt. Een paar e-mails heen en weer laten zien wat iemand echt wilde, en dat is vaak niet het ding waar diegene eerst om vroeg. Filter dat op dag één door automatisering en je verliest het signaal precies wanneer je het het hardst nodig hebt.

Ten tweede maakt elk geval zelf afhandelen je vloeiend. Na genoeg rondes ken je het beste antwoord op elke klasse problemen, en weet je welke problemen het product zelf moet opvangen zodat de vraag nooit meer wordt gesteld. Wanneer het volume groeit en ik wel automatisering inzet, zal die die vloeiendheid coderen in plaats van giswerk.

Mijn drempel voor automatisering is geen ticketaantal. Ik wil dat de vraag terugkomt, dat het antwoord stabiel blijft, en dat de uitzonderingen begrepen zijn. Tot dan is het rommelige gesprek het onderzoek. Daarna kan automatisering het bekende pad afhandelen, terwijl een ongewoon geval makkelijk bij een mens terechtkomt.

Tot nu toe houdt de aanpak stand: ik heb niets aan marketing uitgegeven, de groei is mond-tot-mond, en het terugbetalingspercentage ligt onder 0,8 procent.

De steiger kan wachten

Dezelfde logica geldt voor infrastructuur. Ik zette vóór de lancering geen ticketsysteem, een helpdesk of een kennisbank op. Engineers bouwen graag eerst de ondersteunende machinerie, omdat dat het deel is dat ze weten te bouwen, en AI heeft er een klus van een halve dag van gemaakt, wat het verleidelijker maakt en net zo makkelijk om te vroeg te optimaliseren. De halve dag is echt; de doorlopende kosten van een systeem verzorgen dat je nog niet nodig had ook. Ik zou het systeem toevoegen wanneer het ontbreken verzoeken laat verloren gaan, de reactietijd verbergt, of hetzelfde antwoord inconsistent maakt. Daarvóór is de inbox eenvoudiger en informatiever.

Beslissen wat je niet bouwt

Het verschil tussen een goed product en een gemiddeld product zit vooral in de dingen die het weigert te doen. Welke functies in welke release horen, welke verzoeken echte behoeften zijn en welke er alleen als klinken, welke oprecht goede ideeën toch niet in dit product horen. Ik heb me verontschuldigd bij mensen die functies voorstelden die op hun eigen voorwaarden goed waren, omdat een Mac vol leuke trucs zit die Mole niet hoort uit te voeren. Ja zeggen tegen alles geeft een stoofpot, en een stoofpot is lastig te onderhouden en nog lastiger te vertrouwen met het verwijderen van bestanden.

Ik houd ongeveer een half jaar van het pad van het product in mijn hoofd: wat elke versie toevoegt, wat buiten blijft, en waar dingen landen zodat iemand die voor het eerst komt ze vindt zonder instructies. Als de gewone eerste taak een handleiding nodig heeft, heeft de interface de mensen gefaald die ik het liefst bereik. Documentatie telt nog steeds voor diepte, randgevallen en vertrouwen, maar die hoort de basisvorm van het product niet te redden. Het oude scheermes zegt het het best: voeg geen entiteit toe tenzij die noodzakelijk is.

Ik gebruik nu drie veto's voordat een functie de roadmap bereikt. Die hoort geen altijd-aan-timer, listener of samplekosten toe te voegen, tenzij je de functie bent binnengegaan. Die hoort de geprivilegieerde helper niet te verbreden of om een nieuwe toestemming te vragen alleen om een klein gemak mogelijk te maken. En die hoort geen instelling toe te voegen wanneer een rustige standaard de beslissing voor iedereen kan nemen. Dit zijn geen universele regels voor software. Het is een budget voor dit product: resident werk, privilege en configuratie zijn allemaal vormen van oppervlak die mensen voor altijd moeten vertrouwen.

De positie

De positie van Mole is één zin: een stille bewaarder voor je Mac. Die schoont op, verwijdert, optimaliseert, analyseert en kijkt mee, en blijft verder uit de weg. De ambitie is eenvoudig te zeggen: als één op de honderd Mac-gebruikers Mole houdt, is het echt nuttig geworden. Onlangs begonnen enkele visueel beperkte gebruikers het te gebruiken en liepen ze tegen ruwe randen aan, dus schoven toegankelijkheids-fixes vóór nieuwe functies. Ik kijk ernaar uit hoe de app voor hen voelt; een stille bewaarder hoort voor iedereen stil te zijn.

Producten menselijk houden in het AI-tijdperk

AI maakte veel van dit product mogelijk. Die verving het praten met de mensen die het gebruiken niet, en ik denk niet dat die dat hoort te doen. Efficiëntie is nu makkelijk te kopen; het gevoel en het vertrouwen tussen een ontwikkelaar en de gebruikers moet nog steeds verdiend worden, één gesprek tegelijk. Misschien is dat hoe producten die met AI zijn gebouwd hun menselijke warmte houden: de code kan worden gegenereerd, de relatie niet.

Dit is mijn eerste betaalde product, en een deel van deze keuzes kan verkeerd blijken. Als je deze weg langer hebt gelopen dan ik en ziet dat ik iets doms doe, hoor ik dat graag. Hoe Mole hier in de eerste plaats kwam, is een langer verhaal, verteld in Van een shellscript van 500 regels naar een Mac-app.