Veilleproduit
Se connecterS'inscrire

Les signaux de la semaine

Veille du 29 juin au 5 juillet 2026 · par ton agent de veille

32 contenus identifiés cette semaine

14 retenus pour leur pertinence, 18 écartés.

  • YouTube
  • Newsletters
  • Podcasts
1

Gusto a lancé une gamme produit en 10 semaines sans Figma, Jira ni doc

Le message clé

Quand l'IA fait le build, le process devient le goulot d'étranglement. Gusto a tout supprimé — specs, tickets, PRD — et remplacé le doc par la PR : tu écris la feature, tu la discutes, et si c'est non, tu la jettes.

Ce qui se passe en ce moment

Eddie Kim, CTO et cofondateur de Gusto (1 Md$ de revenus, 500 000 clients), s'est remis les mains dans le code. Avec 3 ingés et 1 designer, il a bâti Gusto Cofounder de zéro ligne à un lancement tier-one en 10 semaines — sans Figma, sans Jira, sans specs, sans standup, sans retro. La seule chose gardée : un perma-Zoom 24/7. Le stack ? Cloudflare Workers + Vercel AI SDK, rien d'autre. Et une méthode : la PR remplace le PRD. Tu ouvres une vraie pull request, prête pour une review humaine, tu discutes de la feature en live, et si la réponse est non… tu la fermes. Le code coûte désormais si peu que le supprimer ne fait plus mal.

  • Eddie Kim (Gusto) a mené le build avec 5 personnes seulement (lui + 3 ingés + 1 designer), de l'idée à un lancement tier-one en 10 semaines, sans une ligne de code au départ.
  • Katie Kavalchen (Gusto), designer sans background ingé, a fini au 94e percentile de throughput PR sur toute la R&D (plus de 1 000 personnes) — top des 20 de son équipe, entourée d'ingés qui prenaient le temps de relire son code.
  • Eddie Kim (Gusto) a réduit le stack agent à Cloudflare Workers + Vercel AI SDK : pas de framework d'orchestration, la mémoire est juste une colonne de base de données nommée « memory ».
  • L'équipe Cofounder (Gusto) tournait à 9 minutes de temps de review médian, parce qu'il y avait toujours quelqu'un dans le perma-Zoom pour dégainer une breakout room.
  • Eddie Kim (Gusto) fixe les bugs clients en eval-first : dans Claude Code, il fait d'abord écrire un eval qui échoue pour reproduire le bug, puis le fix, puis la preuve que l'eval passe — le tout dicté à la voix via Wispr Flow.

I call this the trashcan method of software engineering right now, where you can actually trash all the code, start like a slash V2 branch and rebuild it from scratch. And it's totally reasonable to do because the cost of the code is so low.

— Eddie Kim, CTO & cofondateur de Gusto (How I AI)

Ce que tu peux faire en tant que PM

Teste le workflow PR-as-PRD sur ta prochaine feature au lieu d'écrire un doc

  1. Prototype ton idée toi-même dans Claude Code avant d'en parler à l'équipe — comme Eddie l'a fait sur un layover de 5h — pour arriver avec une démo qui prouve que c'est faisable, pas un PRD.
  2. Remplace la spec par une vraie PR (pas un draft) : demande à l'ingé de coder la feature jusqu'à une pull request prête pour review humaine, puis décide en live si tu la merges ou la jettes.
  3. Installe un perma-Zoom partagé plutôt qu'un standup : une room ouverte en continu où on dégaine une review de PR en quelques minutes — vise le 9 min médian de l'équipe Gusto.
  4. Impose l'eval-first sur les bugs : dans Claude Code, fais écrire d'abord un eval qui échoue pour reproduire le problème client, puis le fix, puis la preuve que l'eval passe avant d'ouvrir la PR.
  5. Mesure ton throughput avec un outil comme DX après un cycle : compte les PR mergées et le temps de review médian, et décide si tu étends la méthode à une deuxième équipe ou si tu réintroduis du process.
2

Arrête de "chatter" avec l'IA : construis-toi un copilote produit qui bosse pour toi

Le message clé

Les PMs les plus avancés ne se contentent plus d'utiliser ChatGPT : ils se construisent un copilote IA sur mesure — rôle, base de connaissances, automatisations — qui abat 80 à 95 % du boulot pendant qu'ils gardent la décision.

Ce qui se passe en ce moment

Deux PMs, deux mondes, même bascule. Côté indé, une consultante a monté Bob : un agent Claude briefé comme un senior PM SaaS, adossé à une base Notion (personas, verbatims, vision produit) qui le nourrit en RAG. Elle le sollicite presque tous les jours pour prioriser, challenger ses personas et cadrer son go-to-market — 95 % de satisfaction, des jours de boulot gagnés. Côté OpenAI, Rohan Varma laisse Codex avaler des canaux Slack entiers, les recracher dans Linear, se programmer ses propres automatisations récurrentes et maquetter cinq écrans depuis un simple screenshot. Le fil rouge : tu ne discutes plus avec l'IA, tu la fais bosser.

  • Une consultante PM (Join Maestro) a construit "Bob", un agent Claude avec skills perso + base Notion, briefé en trois rôles : un CPO fictif qui la challenge, un expert PMM sur ses personas, et un stratège qui priorise par résultat.
  • Rohan Varma (OpenAI, via Peter Yang) fait 3 à 4x plus de boulot par jour : Codex synthétise les retours clients dispersés dans Slack, les pousse dans un board Linear, puis se programme lui-même l'automatisation pour recommencer chaque semaine.
  • Rohan Varma (OpenAI) prototype ses écrans avec le skill image gen : 4-5 maquettes d'UI générées depuis un seul screenshot, plus rapide que coder autant de prototypes React — son "moment AGI".
  • Une consultante PM (Join Maestro) nourrit son RAG de personas, verbatims génériques et hypothèses, puis fait trier 50 verbatims d'un coup pour repérer les personas hors cible et reformuler les insights en jobs-to-be-done.
  • Rohan Varma (OpenAI) pilote 5-6 threads Codex en parallèle via un thread orchestrateur, et laisse des sites auto-mis-à-jour toutes les deux heures devenir la source de vérité de chaque projet.

It's literally not a question of what is possible. It's just everything is possible. It's just what should we do.

— Rohan Varma, PM Codex chez OpenAI (Peter Yang)

Ce que tu peux faire en tant que PM

Construis ton copilote produit sur un seul use case, pas sur ton métier entier

  1. Choisis un seul use case douloureux et récurrent (ex : trier 50 verbatims, challenger une priorisation), pas ta fiche de poste complète — 30 min de cadrage.
  2. Rédige la carte d'identité de l'agent dans un fichier : rôle ("senior PM SaaS, 10 ans"), niveau de rigueur attendu, et surtout ses contraintes et limites explicites.
  3. Injecte ta base de connaissances en RAG (personas, vision, objectifs, verbatims volontairement génériques) via Notion ou des fichiers joints à ton agent Claude ou Codex.
  4. Exige qu'il te challenge et te pose des questions avant de trancher plutôt que de cracher une solution — c'est ton garde-fou contre le biais de confirmation du LLM.
  5. Mesure sur 2 semaines le temps gagné vs ta version manuelle : garde l'agent seulement si tu réutilises réellement son output, sinon rebrief-le ou repars de zéro.
3

Sonnet 5 est sorti : la grille pour décider si tu switches (ou pas)

Le message clé

Anthropic promet du Opus à prix Sonnet, mais quand Claire Vo l'a benchmarké sur 64 générations réelles, Sonnet 5 finit… en bas de son classement. Le bon modèle dépend de la tâche, pas du dernier drop.

Ce qui se passe en ce moment

Claire Vo en a eu marre des "vibe checks" à l'aveugle, alors elle a construit le How I AI Bench avec Claude Code en moins de 45 minutes, puis a lancé Sonnet 5 en blind test contre Sonnet 4.6, Opus 4.8, GPT-5.5 et Gemini 3 Pro : rédaction de PRD, génération de prototypes, tâche agentique multi-étapes et personnalité d'agent. Scoring 70% humain, 30% LLM-juge. Le twist : ce que le LLM notait bien, elle le trouvait mauvais, et inversement. Résultat par tâche, Sonnet 5 gagne surtout sur l'agentique/code — pour le reste, l'existant tient. Avant de tout basculer, teste sur ta tâche.

  • Claire Vo (Lenny) a fait tourner 64 générations en blind test sur 5 modèles frontière (Sonnet 5, Sonnet 4.6, Opus 4.8, GPT-5.5, Gemini 3 Pro), scoring 70% humain + 30% LLM-juge.
  • Anthropic (TLDR AI) positionne Sonnet 5 comme un modèle moins cher aux perfs "approchant Opus 4.8", meilleur que 4.6 sur le planning, le tool use, le coding et le knowledge work.
  • How I AI chiffre le prix de lancement à 2 $ par million de tokens en entrée et 10 $ en sortie, mais seulement jusqu'à fin d'été — ça remonte ensuite.
  • Claire Vo (How I AI) recommande par tâche : PRD → GPT-5.5, prototype → Sonnet 4.6, discuter au quotidien → Sonnet 4.6, taper dans une code base → Opus 4.8 ou Sonnet 5.
  • Claire Vo (How I AI) dans son index Claire-pondéré (70/30) : Sonnet 4.6 en tête, Sonnet 5 tout en bas — trop de prototypes cassés qui "ignoraient les contraintes".

This started out as a Sonnet 5 review. It ended up that Sonnet 5 is at the bottom of my personal preference list.

— Claire Vo, hôte de How I AI (Lenny's Newsletter)

Ce que tu peux faire en tant que PM

Benchmarke Sonnet 5 sur ta vraie tâche avant de switcher

  1. Récupère 3 tâches réelles de ta semaine (un PRD, un prototype, un run agentique) plutôt qu'un test générique.
  2. Génère la même sortie en blind avec Sonnet 5 ET ton modèle actuel (Sonnet 4.6, GPT-5.5 ou Opus 4.8) — masque les noms A/B.
  3. Note chaque sortie de 1 à 5 sur le critère qui compte pour toi : "est-ce que je shipperais ça ?", pas une note de LLM-juge seule.
  4. Surveille les prototypes cassés et les contraintes ignorées, le vrai point faible relevé sur Sonnet 5, avant de te fier au visuel.
  5. Décide par tâche : bascule vers Sonnet 5 uniquement là où il bat ton modèle actuel ET où l'écart de prix (2/10 $) justifie le switch.