← Back

ProcessFlow

SaaS B2B de gestion interactive de processus, Co-fondateur

ProcessFlow overview

Contexte

C'était notre premier vrai produit. Nous étions une équipe de 3 co-fondateurs : un Design Engineer, un développeur full-stack et moi-même en tant que Product Manager. Nous avons lancé ProcessFlow en décembre 2024 et y avons travaillé pendant environ un an, incubés à Station F à Paris. Nous ciblions les équipes ops des PME qui avaient besoin de standardiser leurs opérations.

En tant que PM, j'étais responsable de la stratégie produit, je menais les discovery calls, définissais l'ICP, faisais le scoping des fonctionnalités et pilotais le go-to-market, avec notamment un voyage à San Francisco pour observer les opérations d'un client potentiel sur place.

Le problème

Nous avons constaté que les équipes étaient coincées entre deux extrêmes. D'un côté, des documents statiques et très textuels (Notion, Confluence) incapables de retranscrire une logique conditionnelle. De l'autre, des tableaux visuels infinis (Miro) qui se transforment rapidement en diagrammes spaghettis illisibles. La documentation était toujours obsolète, l'onboarding était lent et toute la connaissance restait dans la tête des employés.

La solution

Nous avons conçu un builder interactif basé sur des nœuds, pensé pour être clair et facile à utiliser. Il était possible d'ajouter une logique conditionnelle et d'intégrer les workflows directement dans Slack ou Notion. Les équipes pouvaient ainsi standardiser leurs opérations en quelques minutes au lieu d'écrire des documents de 10 pages que personne ne lit.

Un builder visuel structuré. En utilisant React Flow, nous avons créé une interface permettant aux utilisateurs de cartographier intuitivement les différentes étapes. Au lieu d'un canvas infini sans contraintes, nous avons implémenté des menus déroulants explicites et guidés pour ajouter des étapes, des délais et de la logique conditionnelle. L'objectif a toujours été de permettre des workflows complexes sans aucun chaos visuel.

Résultats

Nous avons acquis 70 utilisateurs et avons été acceptés dans le programme d'incubation de 42 à Station F. Cependant, nous n'avons jamais généré de revenus.

En juillet 2025, alors que je menais des discovery calls, un CEO m'a invité à visiter son entreprise à San Francisco pour observer leurs opérations sur place. Lors de cette visite, j'ai découvert que leur véritable problème n'était pas du tout la documentation des process, mais la formation de l'équipe de vente. Nous avons immédiatement mis ProcessFlow en pause et leur avons construit un pilote d'AI Sales Training sur mesure en seulement 10 jours.

Après deux mois de négociations sur le pilote, l'entreprise de San Francisco a repoussé l'implémentation de six mois pour des raisons de calendrier interne. C'est là que nous avons eu un déclic. Les cycles de vente B2B sont épuisants et, en tant que jeunes fondateurs sans réseau d'entreprise établi, conclure des contrats grands comptes était presque impossible. Nous avons décidé d'arrêter nos efforts en B2B et de pivoter vers le B2C, ce qui a fini par devenir Lume.

Rétrospective

En tant qu'équipe, nous sommes tombés dans le piège classique des startups. Nous avons construit un outil complexe basé sur nos propres hypothèses plutôt que sur une demande confirmée du marché. Nous pensions comprendre le problème car il semblait évident, mais nous ne l'avons jamais correctement validé avec de vrais utilisateurs avant de développer. Nous avons sur-développé le builder interactif avant même de vérifier si les entreprises étaient prêtes à payer pour l'utiliser.

J'ai aussi réalisé que le SaaS B2B est particulièrement hostile aux jeunes primo-fondateurs qui n'ont pas de réseau d'entreprise existant. Les grandes entreprises sont par nature averses au risque. Elles ne veulent pas servir de cobaye pour une startup qui n'a pas fait ses preuves. Le cold outreach fonctionne à peine. Il faut des warm intros.

Apprentissages

  • Valider avant de construire. Peu importe la propreté de l'architecture, il faut d'abord valider le problème avec le public cible. Nous aurions dû faire plus de 50 discovery calls avant d'écrire la moindre ligne de code.
  • Monétiser le problème, pas le code. Vendre la solution avant de construire le produit. Si c'était à refaire, je me concentrerais d'abord sur la distribution (avoir accès aux bonnes personnes) et seulement ensuite sur ce qu'il faut construire pour eux.
  • Les cycles de vente B2B tuent les startups sans runway. Les contrats grands comptes nécessitent des mois de négociations, et un seul retard d'implémentation peut vous achever.

Durée

Dec 2024 - Nov 2025

Stack technique

ReactNext.jsTypeScriptTailwindReact FlowNode.jsSupabasePrismaStripePostHog

Responsabilités

  • Product management & stratégie
  • Discovery calls & go-to-market
  • Scoping des fonctionnalités & roadmap
  • Recherche utilisateur & définition de l'ICP
  • Ventes B2B (pilote à San Francisco)
Voir le projet