Notes sur la construction d’un produit discret

Mole for Mac a franchi un petit cap de ventes environ trois semaines après le lancement. Plutôt que d’écrire sur les chiffres, je veux noter quelques choix que j’ai faits en chemin, parce que la plupart d’entre eux vont à l’encontre des réflexes d’un ingénieur en activité, et ce sont les choix que je défendrais en premier. Si vous construisez votre propre produit, peut-être que certaines de ces lignes vous éviteront un détour.

Je réponds à chaque e-mail moi-même

Depuis le lancement, chaque demande de support a été traitée à la main : remboursements, réinitialisations d’activation, remboursement d’un écart de prix après une réduction, questions ordinaires. Le volume est faible, bien moins d’un pour cent des utilisateurs écrivent, et j’aurais pu brancher un agent pour s’en occuper en une demi-heure. J’ai choisi de ne pas le faire, pour deux raisons.

D’abord, le support est l’endroit où le produit vous dit la vérité. Une demande de remboursement vous dit pourquoi le produit a déçu quelqu’un. Une question maladroite vous dit quelle partie de l’app n’arrive pas à s’expliquer. Quelques échanges d’e-mails font émerger ce qu’un utilisateur voulait vraiment, ce qui n’est souvent pas ce qu’il a demandé en premier. Filtrer cela par de l’automatisation dès le premier jour, c’est perdre le signal exactement au moment où vous en avez le plus besoin.

Ensuite, traiter chaque cas vous rend fluide. Après assez de tours, vous connaissez la meilleure réponse à chaque classe de problème, et vous savez quels problèmes le produit devrait absorber pour que la question ne soit plus jamais posée. Quand le volume croîtra et que j’introduirai de l’automatisation, elle encodera cette fluidité au lieu de suppositions.

Mon seuil pour automatiser n’est pas un nombre de tickets. Je veux que la question se répète, que la réponse reste stable, et que les exceptions soient comprises. Jusque-là, la conversation un peu brouillonne est la recherche. Au-delà, l’automatisation peut prendre en charge le chemin connu tout en rendant facile pour un cas inhabituel d’atteindre une personne.

Jusqu’ici l’approche tient : je n’ai rien dépensé en marketing, la croissance se fait de bouche à oreille, et le taux de remboursement est inférieur à 0,8 pour cent.

L’échafaudage peut attendre

La même logique s’applique à l’infrastructure. Je n’ai pas mis en place de système de tickets, de centre d’aide ou de base de connaissances avant le lancement. Les ingénieurs adorent construire d’abord la machinerie de soutien, parce que c’est la partie qu’ils savent construire, et l’IA en a fait un travail d’une demi-journée, ce qui le rend plus tentant et tout aussi facile à optimiser trop tôt. La demi-journée est réelle ; le coût continu de soigner un système dont vous n’aviez pas encore besoin l’est aussi. J’ajouterais le système quand l’absence commence à faire perdre des demandes, à masquer le temps de réponse, ou à rendre la même réponse incohérente. Avant cela, la boîte de réception est plus simple et plus informative.

Décider de ce qu’il ne faut pas construire

La différence entre un bon produit et un produit moyen, c’est surtout ce qu’il refuse de faire. Quelles fonctionnalités appartiennent à quelle version, quelles demandes sont de vrais besoins et lesquelles n’en ont que l’air, quelles idées vraiment bonnes n’ont toujours pas leur place dans ce produit. Je me suis excusé auprès d’utilisateurs qui proposaient des fonctionnalités bonnes en elles-mêmes, parce qu’un Mac a plein d’astuces agréables que Mole ne devrait pas exécuter. Dire oui à tout, c’est obtenir un ragoût, et un ragoût est difficile à maintenir et encore plus difficile à confier pour supprimer des fichiers.

Je garde environ un semestre du chemin du produit dans ma tête : ce que chaque version ajoute, ce qui reste dehors, et où les choses se posent pour qu’un premier utilisateur les trouve sans instructions. Si la première tâche courante a besoin d’un manuel, l’interface a échoué auprès des personnes que je veux le plus atteindre. La documentation compte encore pour la profondeur, les cas limites et la confiance, mais elle ne doit pas sauver la forme de base du produit. Le vieux rasoir le dit le mieux : n’ajoutez pas d’entité à moins qu’elle soit nécessaire.

J’utilise maintenant trois vetos avant qu’une fonctionnalité atteigne la feuille de route. Elle ne doit pas ajouter de minuteur permanent, d’écouteur ou de coût d’échantillonnage tant que l’utilisateur n’est pas entré dans la fonctionnalité. Elle ne doit pas élargir l’assistant privilégié ni demander une nouvelle permission seulement pour rendre possible un petit confort. Et elle ne doit pas ajouter un réglage quand une valeur par défaut calme peut décider pour tout le monde. Ce ne sont pas des règles universelles pour le logiciel. C’est un budget pour ce produit : le travail résident, le privilège et la configuration sont toutes des formes de surface que les utilisateurs doivent pouvoir confier pour toujours.

La position

La position de Mole tient en une phrase : un gardien discret pour votre Mac. Il nettoie, désinstalle, optimise, analyse et surveille, et sinon reste hors du chemin. L’ambition est simple à formuler : si un utilisateur Mac sur cent garde Mole sous la main, il sera devenu vraiment utile. Récemment, des utilisateurs malvoyants ont commencé à s’en servir et ont rencontré des aspérités, aussi les correctifs d’accessibilité ont-ils passé devant les nouvelles fonctionnalités. J’ai hâte de voir comment l’app se sent pour eux ; un gardien discret doit l’être pour tout le monde.

Garder les produits humains à l’ère de l’IA

L’IA a rendu une grande part de ce produit possible. Elle n’a pas remplacé le fait de parler aux personnes qui l’utilisent, et je ne pense pas qu’elle le devrait. L’efficacité s’achète facilement aujourd’hui ; le sentiment et la confiance entre un développeur et ses utilisateurs doivent encore se gagner une conversation à la fois. Peut-être est-ce ainsi que les produits construits avec l’IA gardent leur chaleur humaine : le code peut être généré, la relation ne le peut pas.

C’est mon premier produit payant, et certains de ces choix pourront s’avérer faux. Si vous avez parcouru cette route plus longtemps que moi et me voyez faire quelque chose d’absurde, j’aimerais l’entendre. Comment Mole en est arrivé là est une histoire plus longue, racontée dans D’un script shell de 500 lignes à une app Mac.