Le Framing Agile pour lancer sa startup

Le framing agile est un framework applicable pour lancer sa startup. J’ai d’ailleurs déjà formé des entrepreneurs pour mettre ce framework en place pour lancer de nouveaux produits sur le marché. Et même si le canvas peut paraitre complexe à première vue, le cadre du framing aide beaucoup ces entrepreneurs à les guider dans la création de leur startup.

Quels éléments du framing agile pour lancer une startup ?

Voici les éléments que la startup devrait mettre en place dans son framing agile :

• la framing agile -> oui
• le framing master (facilitateur) -> oui
• le decision committee -> oui
• les interviews utilisateurs -> fortement recommandé
• le ministry -> non (Le Ministry est dédiée à une mise à l’échelle)
• l’overall framing agile -> non (sur-couche pour les gros projets)
• durée du framing agile -> 2 semaines

Le Framing Master

Quand nous lançons une startup, les moyens des personnes qui s’investissent ne sont pas illimités. Nous conseillons fortement d’avoir un framing master mais ce rôle pourra pris en charge par l’un des participants.

Si cette personne n’est pas formée, elle aura peut-être des lacunes sur certaines facilitations. Cependant, ce n’est pas grave ! La personne qui prendra ce rôle permettra malgré tout de dynamiser le groupe. Nous conseillons cependant à cette personne de lire le livre du framing agile également disponible en version numérique pour 16€. Il permet d’aider dans la facilitation et propose de nombreux conseils.

Lancer sa startup pour créer un MVP

Le framing agile est 100% adapté aux startups qui veulent suivre tous les concepts du Lean Startup. Il permet de créer rapidement une première vision du produit que nous désirons proposer sur le marché tout en gardant en tête que nous sommes sur la phase de « tester une hypothèse« . D’ailleurs, le framing agile dans ce cadre peut se faire seul ou à 2 avant même d’investir sur des des coûts importants : « salaires », « stockage »…

L’objectif de ce framing agile dans ce contexte est de faire maturer une idée afin de pouvoir tester cette idée sur le marché avant même d’investir massivement sur une hypothèse non vérifiée.

La partie « refinement » proposée par le framing agile (voir le canvas ci-dessous) aura beaucoup de chance de se transformer en :

• création d’un prototype
• (ou) création du support permettant de tester une hypothèse

En effet, tester une idée n’est pas systématiquement sous la forme d’un « prototype ». Comme l’explique Eric Ries dans son livre « Lean Startup » que je vous recommande fortement de lire, il est possible de tester une hypothèse sous forme de vidéo. Le créateur de Dropbox a d’ailleurs validé son MVP (Minimum Viable Product) en proposant une vidéo claire de son concept afin de tester l’envie des utilisateurs a prendre son produit quand il sera disponible. Le nombre impressionnant de personne voulant avoir la « Beta » du produit a amené le créateur de Dropbox à valider que son hypothèse était bonne.

Regardons le dernier canvas du framework pour mieux comprendre.

Le pré-framing

L’équipe même restreinte qui désire lancer sa startup va en semble réaliser un pré-framing pour définir des éléments clés :

• lieu où travailler notre framing agile :
  • un simple salon
  • une salle prêté par une entreprise généreuse ou un incubateur
  • un espace de travail louable sur une durée de deux semaines
• l’engagement et la disponibilité des quelques personnes sur ce lapse de temps court
• définir les 2 semaines pour lancer son framing agile (si au bout d’une semaine tout est fini, le framing agile pourra se terminer avant)
• définition du Decision Committee
  • ceux qui pourraient financer le produit : love monnaie potentielle, les participants au framing, des membres proches qui pourraient conseiller
• le framing master
  • un des membres de l’équipe le plus voué à faciliter le framing agile

Ce pré-framing peut se faire au café, dans le salon de l’un des participants, par skype… Il n’est pas nécessaire de trop formaliser sa mise en place. Quand un petit groupe décide de se lancer dans une nouvelle aventure, il ne doit pas s’embarrasser dès le début avec des processus restrictifs. Imposer des processus trop cadrés dès le démarrage peut rapidement amener un début de motivation.

Les notions de contrat de framing agile ne doivent pas être appliqué pour un lancement de startup. La bureaucratie peut-être démotivante alors que cette équipe d’entrepreneur doit au contraire maximiser sa motivation pour se diriger vers le succès.

La mission

L’équipe va ensuite s’aligner sur la mission (enjeux, motivation de chacun, définition de là où on ira ensemble).

Le framing starter board permettra :

• au framing master de rapidement présenter le concept du framing agile sans trop le formaliser
• de parler en équipe du sujet
• de définir les compétences du groupe et les compétences qui seront nécessaires

Bien que l’atelier sera beaucoup plus rapide que dans dans un projet d’entreprise, il est intéressant de voir nos forces et nos faiblesses. Cela permettra au groupe d’entreprendre les choses différemment ou de trouver des solutions rapides pour combler les éventuelles faiblesses.

L’équipe pourra utiliser les OKR pour se définir les différents objectifs qu’ils aimeraient atteindre :

• Objectif : répondre à la problématique X
• Résultats clés : comment on va mesurer que notre hypothèse est valide ou non

La vision

L’équipe va à présent travailler la vision du produit qu’elle mettrait en place pour répondre à la problématique. Cette vision permettra d’aligner l’ensemble des participants autour de celle-là et d’avoir les éléments visuels nécessaires pour se faire rechallenger par les utilisateurs potentiels.

Je recommande fortement de faire l’ensemble des ateliers qui permettront d’affiner la vision du produit. L’équipe doit penser « produit », puis imaginer le MVP (Minimum Viable Product) qui pourrait émerger. Quand nous créons une startup, nous n’avons pas d’image de marque à défendre. Il ne faut donc pas partir sur la définition d’un MMP (Minimum Marketable Product) mais vraiment sur un MVP.

Les risques

L’équipe pourra maintenant grâce à sa vision, analyser les risques qu’elle pourrait rencontrer. D’ailleurs, si les risques identifiés sont trop gros, elle peut à ce moment là décider de ne pas aller plus loin. Elle pourra également décider de « pivoter » pour limiter les risques encourus si bien sûr ce pivot permet toujours de créer un futur produit prometteur.

La roadmap

Définir la roadmap va permettre de mettre en avant deux facteurs essentiels :

• combien couterait la mise en place du MVP ?
• quelles seraient les ressources nécessaires pour réaliser ce MVP ?
• quand pourrions-nous imaginer mettre notre MVP à disposition pour le tester en réel ?

Attention, la notion du MVP est très variable. Un MVP peut se mettre en place en quelques heures (exemple, la vidéo créée par Dropbox) comme en plusieurs mois. Dire que tous les MVP sont réalisables en 1 semaine est une utopie ; tout dépend de la complexité pour répondre au besoin.

L’équipe pourra alors confirmer qu’il est intéressant de mettre ce MVP en place, d’abandonner cette idée pas si intéressante (par rapport à sa capacité de s’engager en temps et/ou financièrement) ou d’envisager un pivot.

L’organisation

Si l’équipe valide qu’elle va investir dans la création de ce MVP, elle devra définir le cadre de sa mise en place :

• gouvernance au sein de l’équipe (voire des éléments extérieurs indispensables)
• fonctionnement de l’équipe (en faisant attention de rester flexible et de pas se créer des processus compliqués)
• l’identité de l’équipe
  • nom du produit, une petite icône…

Bien que l’identité de l’équipe peut paraitre est un surplus à ce moment là, il peut aussi amener l’équipe à augmenter sa motivation.

L’affinage

A ce moment là, l’équipe va lancer concrètement :

• le développement de son MVP si nous voyons qu’il est très simple à mettre en place
• (ou) utiliser le processus plus complet pour les produits où les spécifications sont indispensables (produits très complexes)

Créer des user-stories quand l’équipe est constituée de deux personnes peut être un processus lourd et inutile (pour ne pas dire démotivant) ; cela ne se justifiera que sur des produits très complexes. En effet, si l’équipe pense que les user-stories permettront d’ordonner le travail complexe à réaliser (donc de l’aider) alors elle pourra sans soucis les utiliser ; cependant, c’est un choix qu’elle fera d’elle même.

Si l’équipe lance son MVP, le travail réalisé sera probablement jetable : « faire au plus vite pour mettre un MVP fonctionnel à disposition afin de tester les hypothèses ». L’équipe pensera à la qualité après avoir validé son hypothèse.

Pour les MVP qui peuvent mettre plusieurs mois à émerger, l’équipe devra savoir mettre le curseur qualité/effort (coût) au bon endroit pour que les évolutions du produit puissent aller jusqu’à la phase d’accélération (étape 3 d’une startup). Un MVP permet de tester une hypothèse mais ensuite il est indispensable de pouvoir améliorer le produit pour trouver la meilleure formule (étape 2) ; et ce n’est pas à ce moment là que l’équipe va tout refaire surtout si il y a plusieurs mois d’effort dans ce travail.

Interview utilisateurs

Il est indispensable de ne pas cacher son idée et de présenter l’avancement de vos travaux à des utilisateurs potentiels. Cela permettra à l’équipe de pivoter en cas de besoin et de connaitre déjà les tendances du marché lors de la mise en production de votre MVP.

Le framing agile est aussi un framework de lancement de startup

Si vous désirez lancer votre startup, utilisez le framing agile dans sa forme la plus simple pour faire émerger votre hypothèse. Si ce framework est adapté aux grands groupes avec ses possibilités de mise à l’échelle, il est également adapté aux entrepreneurs qui veulent lancer un nouveau produit. Dans ses principes fondateurs, le framing agile est 100% dans la même approche que l’approche du Lean Startup.

Par contre, le cadre à appliquer doit être moins stricte. Une équipe doit faire de son mieux pour garder sa motivation dans le lancement d’une startup et ne pas se fatiguer dès le démarrage avec un cadre trop stricte non adapté.

 

[AGILE FRAMING V2 – les certifications v1.x seront valides v2.x]