Granola's Chris Pedregal on Building a $1.5B AI Company

**Résumé de l’épisode : Dan Shipper interviewe Chris, co‑fondateur et CEO de Granola** Dans cet entretien, Dan Shipper retrouve Chris, co‑fondateur et PDG de Granola, l’une des premières applications d’IA qui a suscité l’étonnement « Holy … c’est réellement fonctionnel ». Granola a rapidement grandi : plus de 55 employés, une valorisation d’environ 1,5 milliard de dollars, et une place de pionnier dans le domaine des notes de réunion automatisées. La discussion porte sur les enjeux de la croissance d’une startup IA, les choix de produit, la structuration des équipes, et la vision à moyen terme. --- ### 1. La réalité du “knife fight” des startups Chris rappelle que les startups sont « des combats à couteau » : elles restent difficiles tant quand les choses fonctionnent que lorsqu’elles échouent. Même avec un succès apparent, il faut constamment se battre pour rester à la pointe. Il insiste sur le fait que la perception publique (« nous tuons tout ») masque la complexité quotidienne du management, du recrutement et de la mise à l’échelle. --- ### 2. Positionnement de Granola face à la concurrence Granola a été l’un des premiers outils d’IA à proposer des transcriptions et résumés de réunions. Rapidement, d’autres acteurs (Notion, OpenAI, Zoom) ont copié cette fonctionnalité. Chris explique que ces copies n’ont pas eu d’impact majeur sur la croissance de Granola : l’entreprise continue d’attirer des utilisateurs grâce à son exécution et à son focus sur d’autres problématiques. Il voit la concurrence comme une confirmation que le marché se développe, et non comme une menace existentielle. --- ### 3. Organisation interne : le modèle « pirate / architecte » Pour gérer la rapidité d’expérimentation et la solidité du produit, Granola adopte deux rôles clés : - **Le pirate** : construit rapidement un prototype pour valider une idée, sans se soucier de l’architecture sous‑jacente. - **L’architecte** : travaille en parallèle pour transformer le prototype viable en système maintenable et évolutif. Un pirate est dédié à chaque produit, tandis qu’un architecte peut intervenir sur plusieurs projets. Cette séparation permet d’équilibrer vitesse d’innovation et robustesse. --- ### 4. Processus de conception : la phase de « shaping » Granola s’inspire du cadre « Shape Up » de Basecamp. Le processus se décline en trois étapes : 1. **Shaping** – exploration de multiples solutions à partir d’un « job‑to‑be‑done ». 2. **Validation** – test auprès d’un petit groupe d’utilisateurs pour vérifier l’utilité. 3. **Construction** – mise en production d’une version fiable, scalable et performante. Cette approche aide à éviter le sur‑développement et à rester centré sur les besoins réels. --- ### 5. Le défi du « handrail » : être invisible jusqu’à ce que l’on soit indispensable Chris compare Granola à une rampe d’escalier : elle doit rester invisible pendant la marche, mais intervenir immédiatement lorsqu’on trébuche. L’objectif est de fournir des aides contextuelles (briefs de réunion, résumés) uniquement quand l’utilisateur en a besoin, sans encombrer l’interface. Cette philosophie guide le design de nouvelles fonctionnalités. --- ### 6. Pré‑génération de contenu et métriques d’efficacité Granola a expérimenté la **pré‑génération** de briefs avant les réunions. Le système crée massivement des résumés (des millions) en amont, sachant que seul un petit pourcentage sera effectivement consulté. L’idée est que, lorsqu’un utilisateur a besoin d’un rappel de 15 secondes avant une réunion, le brief est déjà prêt, réduisant le temps d’attente à zéro. Mesurer l’efficacité de cette approche reste difficile. Chris évoque plusieurs pistes : - Comparer l’usage avec et sans pré‑génération. - Analyser le taux de clics sur les briefs déjà générés vs. ceux générés à la demande. - Étudier l’impact sur la satisfaction utilisateur et la productivité perçue. Aucun indicateur définitif n’a encore été retenu. --- ### 7. Le problème du « time‑travel » et de l’asynchronie Dans les interactions agent‑humain, il y a un décalage entre le lancement d’une tâche (ex. : demander à un agent de préparer un document) et le moment où l’utilisateur consulte le résultat. Ce « time‑travel » crée une charge cognitive : l’utilisateur doit garder en mémoire le contexte pendant l’attente. Granola explore des UI qui minimisent ce gap, par exemple en affichant des notifications proactives ou en intégrant les résultats directement dans le flux de travail (Slack, Codeex, etc.). --- ### 8. Intégration avec Codeex et les espaces de travail « agentic » Chris passe du temps quotidiennement dans **Codeex**, l’environnement de développement intégré qui permet d’embarquer des agents IA dans le navigateur. Il décrit deux surfaces de travail : - **Slack/agents asynchrones** : délégation de tâches (ex. : créer une PR, proposer des noms de produit) via des bots qui répondent dans les canaux. - **Codeex (ou applications natives)** : interaction synchronisée où l’agent et l’utilisateur partagent le même UI, voient les mêmes changements en temps réel, et peuvent annoter ou corriger le résultat immédiatement. Il montre un exemple concret : demander à Codeex de changer d’opérateur internet. L’agent ouvre le site du fournisseur, se connecte, discute avec le service client automatisé, et finalise le changement tout en laissant l’utilisateur suivre le processus dans le même onglet. --- ### 9. Gestion du contexte et de la « présence » de l’agent Granola collecte un vaste ensemble de données (réunions, Slack, emails) pour créer un **profil dynamique** de chaque utilisateur. Ce profil pourrait être injecté dans n’importe quel agent via une API ou un MCP (Machine‑Control‑Protocol). Chris veut que le contexte soit portable : un agent dans Codeex, un CRM, ou un outil de messagerie doit pouvoir accéder aux mêmes informations. Il souligne le besoin d’une UI qui expose la « présence » de l’agent (ex. : curseur, surlignage) afin que l’utilisateur comprenne où l’agent intervient, surtout dans des environnements collaboratifs comme les documents partagés. --- ### 10. Stratégie produit : être le meilleur dans des niches ciblées Granola ne cherche pas à couvrir tous les cas d’usage. La stratégie est de **devenir le meilleur du monde** sur quelques tâches critiques liées aux réunions : génération de briefs, résumés enrichis, suivi d’actions post‑réunion. En se spécialisant, l’entreprise peut offrir une expérience fluide et intégrée, notamment lorsqu’elle se combine à des UI en temps réel (ex. : pendant la réunion). Un autre exemple partagé : un utilisateur en sales utilise Claude pour créer un microsite personnalisé pour chaque prospect, puis injecte les données de Granola via le MCP pour remplir automatiquement le site. Granola ne veut pas concurrencer les outils de création de site, mais fournir le **contexte** qui rend ces créations plus pertinentes. --- ### 11. Gestion des coûts et du token spend Au départ, Granola n’a pas suivi de près la dépense en tokens (coût des appels API). L’apparition de modèles comme **Fable** a déclenché une prise de conscience : certains utilisateurs pouvaient dépenser des milliers de dollars en crédits en une journée. Depuis, l’équipe a commencé à monitorer les dépenses, mais reste **optimiste** : les coûts devraient diminuer avec l’amélioration des modèles, et l’équipe pourra affiner les agents les plus coûteux une fois les expériences utilisateurs validées. --- ### 12. Adoption des workflows « agentic » Environ **50 %** des utilisateurs de Granola utilisent l’application de manière « agentic », c’est‑à‑dire en formulant des requêtes complexes qui déclenchent plusieurs étapes d’analyse (ex. : synthèse de plusieurs réunions, identification de tendances, suggestions d’actions). Cette proportion montre que même les utilisateurs non‑techniques commencent à exploiter le potentiel des agents, même s’ils ne le nomment pas explicitement. --- ### 13. Vision à six‑douze mois et défis UI Chris réfléchit à l’impact des prochains modèles (ex. : sortie de Fable) sur la roadmap. L’orientation stratégique reste centrée sur les **jobs‑to‑be‑done** des utilisateurs, tandis que les capacités du modèle influenceront la taille des équipes et le nombre de pods de développement. Un problème majeur identifié : **l’absence d’une UI adaptée** pour manipuler de grands volumes de contexte (toutes les réunions d’une semaine, les messages Slack, les emails). Les métaphores actuelles (chat thread, tableau de bord) ne permettent pas de naviguer efficacement entre plusieurs contextes simultanés. Chris estime que de nouvelles métaphores seront « découvertes » plutôt qu’inventées, et que Granola devra participer à cette évolution. --- ### 14. Conclusions clés - Les startups IA restent un combat constant, même lorsqu’elles semblent « tuer ». - Granola mise sur l’exécution, la spécialisation et la capacité à fournir du contexte riche plutôt que sur la simple copie de fonctionnalités. - Le modèle organisationnel « pirate / architecte » permet d’allier rapidité d’expérimentation et stabilité du produit. - La pré‑génération de contenus et la gestion du temps d’attente sont des leviers de productivité, mais leurs métriques restent à affiner. - L’intégration profonde avec des environnements comme Codeex, ainsi que la portabilité du contexte via API/MCP, sont essentielles pour créer des expériences réellement « agentic ». - Le futur du travail avec l’IA dépendra de nouvelles UI capables de gérer l’asynchronie, le « time‑travel » et la visualisation de la présence de l’agent. Granola continue d’avancer en se positionnant comme le meilleur outil de prise de notes et de contexte de réunion, tout en explorant de nouvelles interfaces et en affinant sa stratégie de coût. L’entreprise reste ouverte aux collaborations et encourage les utilisateurs à suivre ses évolutions via son compte Twitter **@meetGranola**. --- *Ce résumé se base exclusivement sur le transcript fourni, en conservant les idées majeures, les décisions et les perspectives évoquées par les intervenants.*