Cadrage et collaboration pour construire un produit - 2
Précédemment dans notre quête du graal..
Après notre prise de conscience et un travail acharné pour trouver l’équilibre entre les enjeux techniques, business et les besoins utilisateurs, la sentence tombe : sur les deux sujets sur lesquels on a travaillé, on se retrouve avec un go pour le sujet mineur et un no-go sur le majeur. C'est le drame. Que faire maintenant ?
Deuxième étape : embarquer la technique, jusqu’à arracher les développeurs de leur code pour co-concevoir avec nous 🧑🏻🎨
Nous voilà repartis pour une deuxième édition ! Cette fois un peu plus light : en effet, on avait déjà la majorité des infos qu'il nous fallait : le parcours cible, les retours utilisateurs et une première version des écrans.
On se met d’accord sur un nouveau challenge : répondre au besoin utilisateur en 5 sprints. On redéfinit l’équipe cœur : UX/UI, PO, PM, représentants opérationnels, sans oublier cette fois le Tech Lead (ou a minima un développeur).
On est parties sur une nouvelle série d’ateliers :
On re-sketch avec une vision tech : plusieurs développeurs de l’équipe se sont libérés pour “dessiner” avec nous.
On prend le temps de faire un MoSCoW (Must have Should have Could have Won't) : on priorise les user stories et on définit notre MVP (Ou plutôt Minimum Viable Feature en l'occurrence).
C’est enfin le moment pour l’équipe technique de passer en extreme quotation puis de nous partager les différents scénarios envisageables : du plus rapide au plus coûteux. 🤑
Enfin, arrive le moment fatidique, on se réunit avec : l’UX designer qui porte la voix des utilisateurs à travers les tests effectués, le directeur produit qui porte la vision stratégique et les enjeux business et le Product owner qui a en tête les scénarios techniques et peut donc imaginer comment répondre à l’objectif sur le planning envisagé.
Et PAF ! On en sort avec un go sur un incrément produit à forte valeur business, qui répond aux besoins des utilisateurs et qui est réalisable sur une période de 5 semaines : on tient notre méthode, que l’on a appelé PIF (Product Increment Framing).
On en sort avec une méthode ou en tout cas un ensemble d’outils et d’ateliers mis à jour et qui s’articulent de la manière suivante. 🥳
TAKE AWAY 🧳
SURTOUT INCLURE L’ÉQUIPE TECHNIQUE DÈS LE DÉPART
Anticiper un éventuel NO GO : prévoir le temps de réitérer
Considérer les enjeux tech, au même niveau que les utilisateurs et le business.
À suivre : la troisième et dernière étape de notre épopée, nous nous attaquerons à la mise en place du changement avec les enchanteurs de l'accompagnement au changement.