John Sheehan, CEO et co-fondateur de Runscope
On ne compte plus les startups qui appuient leurs services sur des APIs. Après une longue expérience dans le domaine, et plusieurs startups créées à son actif, John est passé au niveau supérieur : il crée des outils pour la maîtrise des architectures basées sur des APIs.
Il nous parle de l'expérience de l'entrepreneuriat, et n'hésite pas à être riche en conseils d'initié. Il nous parle aussi de son parcours, de comment il en est venu à maîtriser le sujet, et de l'importance de travailler sur des sujets qu'on maîtrise.
Je suis John Sheehan, CEO et co-fondateur de Runscope, basé à San Francisco, et nous faisons des outils de debugging et de test d'API pour les développeurs.
Runscope a été démarré avec l'idée que toutes les applications aujourd'hui sont distribuées ; nous avons toutes ces pièces différentes, et elles se parlent toutes via API, et pourtant nous n'avons pas vraiment d'outils qui comprennent la nature des applications distribuées modernes.
Ce que nous voulions faire, c'était moderniser les outils autour de la consommation d'APIs pour les développeurs d'application. Nous avons commencé avec un outil de debugging, pour donner de la visibilité, et de là, nous nous sommes dirigés vers le monitoring, parce qu'une fois que votre app tourne bien, et que vous avez résolu votre problème, ce que vous voulez vraiment savoir, c'est si vos APIs fonctionnent bien à tout moment en tâche de fond, et vous assurer qu'elles ne s'effondrent pas, pour vous assurer que ça ne casse pas votre application. Donc, nous avons lancé un autre produit en novembre dernier, il y a 6 mois, qui s'appelle Runscope Radar, qui monitore automatiquement les services back-end et les APIs.
C'est définitivement un besoin que nous avons tous les jours ; nous utilisons Runscope tous les jours pour construire Runscope ! Nous avons construit le produit que nous voulions utiliser, et dont nous souhaitions l'existence. Nous n'aurions pas pu construire cette compagnie et ce produit sans... le produit !
Je pense que l'idée de Runscope venait de plusieurs choses.
Il y a quelques années, j'ai démarré à Twilio, j'étais un des premiers employés là-bas, dans les 10 premiers ; et pareil mon co-fondateur Frank, on était tous les deux très tôt à Twilio. On y a été attiré pour construire des outils, et aider les développeurs à réussir à travers ces outils.
Je passais mon temps à aider les développeurs à démarrer avec Twilio, et je commençais à voir le même problème chez tous les clients : quand tu lances quelques appels à une API, c'est facile ; quand tu commences à en lancer quelques millions par jour, ça devient beaucoup plus compliqué, il faut garder un oeil dessus pour s'assurer qu'elles fonctionnent bien.
Et ça m'a suivi après mon départ de Twilio, et que j'ai rejoint la compagnie "If This Then That" (IFTTT) ; ils ont une tonne d'API intégrées, leur produit entier est fait d'intégration d'APIs. J'ai commencé à retrouver les mêmes problèmes, parce que nous faisions à nouveaux des millions d'appels à des APIs. Une API particulièrement mauvaise fonctionnait sur ma machine locale, mais ne fonctionnait pas sur notre environnement de recette, et on ne pouvait pas installer d'outil sur notre environnement de recette pour voir le trafic incorrect, et donc j'ai pensé à cette idée qui est devenue notre inspecteur de trafic, un outil de debugging, que tu peux lâcher où tu veux, peu importe où, tant que tu peux changer le hostname, alors tu peux voir tout le trafic de cet endpoint.
Et juste après que nous lancions ça, j'ai réalisé : "oh, c'est des données très intéressantes, qui m'aident non seulement à débugger, mais qui va m'aider à faire beaucoup d'autres choses intéressantes."
À propos de la culture tech à San Francisco.
Il y a beaucoup de caractéristiques uniques à la culture de San Francisco.
Je n'ai jamais été nulle part où il y avait une concentration si élevée de talents techniques. Tu trouveras des gens tout aussi talentueux partout, mais pas une telle densité de gens hautement qualifiés. Sur la rue où nous travaillons, ici à San Francisco, entre le stade de baseball et Market Street, c'est un enchaînement de startups, et elles sont toutes remplies de talents d'ingénierie et de design de haut vol. Il n'y a pas beaucoup d'entre endroits qui en ont autant.
Il y a aussi un niveau d'ambition que je n'ai jamais vu ailleurs. Peut-être que c'est la partie de moi qui a grandi dans le Midwest, où tout est calme et stable (et c'est super, c'est parfait pour beaucoup de gens) mais l'attitude ici est de chercher à frapper fort, s'attaquer à des gros problèmes.
L'autre chose est l'aversion au risque, les gens ici sont partants pour prendre des risques, sur des choses qui vont être énormes ou pas, mais l'ambition que ça devienne énorme prend le pas sur le risque à faire des choses que tu ne ferais pas sinon.
Je pense que le meilleur conseil que je donne aux gens, c'est : fais ce que tu connais, travaille sur un sujet que tu connais. Je ne sais pas comment gérer une startup, j'apprends tous les jours ; mais je sais très bien comment gérer les APIs. Ça rend les décisions sur ce qu'il faut construire, quelles sont les priorités, qui sont nos clients, comment leur parler, ... ça rend tout ça très clair, parce qu'on a une compréhension très solide des problèmes, j'ai vécu tous ces problèmes pendant des années, avant qu'on construise ces outils pour les résoudre.
Le temps que j'ai mis à me lancer dans un sujet que je ne connaissais pas, juste parce que c'était lucratif, ou quelle que soit la raison, je ne réussissais pas aussi bien, parce que je n'avais pas l'expertise du sujet suffisante pour ne pas avoir à m'inquiéter de savoir ce qu'il faut faire.
Tu peux te casser la tête à comprendre ce qu'il faut construire, et quels sont les problèmes, quelles sont les solutions, et gérer une compagnie en même temps. Je me sens libéré d'avoir à comprendre les problèmes et solutions, parce que je les connais déjà tellement bien, qu'on peut se concentrer juste sur la construction d'une excellente compagnie.
Donc, ce que je dirais : travaille sur les problèmes que tu connais, c'est le meilleur conseil startup que je peux donner.
L'autre gros conseil que je peux donner, c'est : trouve le bon co-fondateur.
Je ne pense pas que je pourrais faire ça du tout sans avoir un co-fondateur en qui je peux avoir confiance, qui prendra des décisions quand je ne suis pas là, qui comprend complètement le problème, la roadmap, qui te poussera quand tu auras besoin d'être poussé, et avec qui avoir une compréhension mutuelle, même des moments difficiles, quand la levée de fonds se passe mal, quand vous galérez à recruter, etc. Quelqu'un dans les tranchées avec toi, sur lequel tu peux t'appuyer, fera une énorme différence pour rendre tout ça viable à long terme.
Donc : trouve le bon co-fondateur.
J'ai fait plusieurs startups avant en tant que fondateur unique, et c'est épuisant, il y a juste trop de choses à gérer ! Mais, avoir quelqu'un avec qui équilibrer la charge... Si j'ai besoin de me focaliser sur quelque chose qui n'est pas lié au produit, je sais que ça va continuer à avancer. Je pense que c'est le truc le plus important en tant que fondateur unique : la compagnie ne bouge que quand tu bouges, les choses n'avancent que quand tu avances. Mais dès que tu as une deuxième personne, les choses avancent même quand tu n'es pas disponible. Et dès que tu as des employés, c'est extra tout ce qui bouge, même quand tu ne fais rien.
Mais à deux personnes, il y a toujours quelque chose en mouvement, c'est important de construire ce momentum dans une startup ; et c'est beaucoup plus simple de construire ce momentum s'il y a deux personnes qui poussent les choses. Deux, ou plus !
Vous devriez parler à Julien Genestoux. Julien est le fondateur de SuperFeedr, et il fait des choses très intéressantes, il essaie de réhabiliter (non attends, quel est le mot qu'il utilise ?) réinventer le RSS, en gros.
SuperFeedr est un service de gestion de flux, ça facilite la consommation de flux. Ils sont derrière PubSubHubbub, le protocole de push de flux en temps réel. RSS a quelque peu été endommagé ces dernières années, Google Reader est mort, et d'autres services ont coupé leurs flux RSS, et il essaie d'aider les producteurs de media à comprendre comment ils peuvent utiliser RSS toujours aujourd'hui, et toujours en gagner ce dont ils en ont besoin : la publicité, et comprendre que ce n'est pas diverger du trafic depuis le site web, mais améliorer l'expérience que les gens auront avec le contenu.
SuperFeedr est très intéressant, et Julien est très passionné à propos du RSS, et la distribution de contenu.
Pour le contacter : Twitter.
