Working Backwards
Rédigez le communiqué de presse avant de coder. La méthode d'Amazon pour partir de l'expérience client idéale et remonter vers la solution.
Description
Working Backwards est une méthodologie de développement produit créée chez Amazon au début des années 2000, formalisée par Colin Bryar et Bill Carr dans leur livre Working Backwards: Insights, Stories, and Secrets from Inside Amazon (2021), qui inverse le processus classique de conception en partant de l'expérience client idéale (matérialisée par un communiqué de presse fictif et une FAQ) avant de définir le produit à construire. Sa finalité : garantir que chaque produit résout un vrai problème client avant qu'une seule ligne de code ne soit écrite. Le principe est radical : au lieu de partir d'une technologie ou d'une idée et de chercher un marché, vous commencez par écrire le press release du produit fini. Ce document d'une page décrit le problème client, la solution proposée, les bénéfices clés et une citation fictive d'un client satisfait. Si le press release ne fait pas dire "je le veux" à un lecteur, le produit ne mérite pas d'être construit. Werner Vogels (CTO d'Amazon) a résumé la philosophie : "Start with the customer and work backwards." Working Backwards fonctionne comme un architecte qui dessine la maison terminée avant de calculer les fondations : vous définissez l'expérience de vie (le PR/FAQ), puis vous remontez vers les plans techniques. La FAQ interne qui accompagne le press release anticipe les questions des stakeholders : "Pourquoi maintenant ?", "En quoi c'est différent de la concurrence ?", "Quel est le business model ?". Ce tandem PR/FAQ force une clarté de pensée que les spécifications techniques classiques n'exigent pas. Amazon a utilisé cette méthode pour lancer Kindle, AWS, Prime et Alexa. Contrairement au Lean Canvas (qui modélise le business model) ou au Product Vision Board (qui synthétise la vision), Working Backwards se concentre sur une seule question : "Le client sera-t-il enthousiasmé par ce produit ?" Si la réponse est floue, le press release le révèle immédiatement.
Objectifs
- Définir la vision
- Comprendre les utilisateurs
- Assurer l'alignement stratégique
Utilisé par
- -Amazon (créateur de la méthode Working Backwards, utilisée pour lancer Kindle, AWS, Prime et Alexa)
- -Intuit (a adopté le processus PR/FAQ d'Amazon pour cadrer ses innovations produit)
Avantages
- Force la clarté de la proposition de valeur avant tout investissement. Si le press release n'enthousiasme personne, vous économisez des mois de développement sur un produit que personne ne veut.
- Aligne toutes les parties prenantes sur une vision commune. Un PR/FAQ de 3 à 6 pages est lisible par l'ingénieur, le marketeur, le CFO et le CEO, ce qui élimine les interprétations divergentes.
- Anticipe les objections dès le départ. La FAQ interne force à répondre aux questions difficiles (business model, concurrence, coûts) avant qu'elles ne surgissent en plein développement.
- Testable auprès de vrais clients. Vous pouvez montrer le press release à des utilisateurs potentiels et mesurer leur réaction avant d'écrire une ligne de code.
Limites
- Processus d'écriture exigeant. Rédiger un PR/FAQ convaincant demande une compétence de storytelling et de synthèse que toutes les équipes n'ont pas. Les 5 à 10 itérations chez Amazon ne sont pas une exagération.
- Moins adapté aux améliorations incrémentales. Écrire un press release pour un bug fix ou une optimisation UX mineure est disproportionné. Working Backwards est conçu pour les nouveaux produits ou les innovations majeures.
- Risque de "beau press release, mauvais produit". Un PR/FAQ bien écrit peut masquer des failles techniques ou business si la FAQ interne n'est pas assez rigoureuse. La qualité des questions détermine la qualité du processus.
- Nécessite une culture de l'écrit. Chez Amazon, la culture des "six-page memos" soutient Working Backwards. Dans les organisations qui privilégient les slides et les meetings, l'adoption demande un changement culturel.
Comment appliquer Working Backwards
- 1
Identifier le problème client à résoudre
Avant d'écrire quoi que ce soit, clarifiez le problème. Qui est le client ? Quel est son pain point principal ? Comment le résout-il aujourd'hui (et pourquoi cette solution est insuffisante) ? Si vous ne pouvez pas articuler le problème en 2 phrases, vous n'êtes pas prêt à écrire le press release. Output : problème client formulé clairement avec segment cible identifié.
- 2
Rédiger le Press Release fictif (1 page)
Écrivez un communiqué de presse d'une page comme si le produit était lancé aujourd'hui. Structure : titre accrocheur (le bénéfice client, pas le nom de la feature), sous-titre (une phrase sur le problème résolu), paragraphe d'ouverture (le quoi et le pourquoi), paragraphe de contexte (le problème actuel), paragraphe de solution (comment ça marche pour l'utilisateur), citation fictive d'un dirigeant ("Nous avons créé X parce que..."), citation fictive d'un client ("Grâce à X, je peux maintenant..."), call-to-action. Output : press release d'une page, rédigé en langage client.
- 3
Rédiger la FAQ interne (2-5 pages)
La FAQ anticipe les questions que les stakeholders, les ingénieurs et les clients poseront. Divisez-la en deux parties : FAQ externe (questions clients) et FAQ interne (questions business et techniques). Exemples de questions internes : "Quelle est la taille du marché ?", "Quelles sont les dépendances techniques ?", "Quel est le coût de développement estimé ?", "Comment mesurons-nous le succès ?". Soyez honnête dans les réponses. Si vous ne savez pas, écrivez "à valider". Output : FAQ de 2 à 5 pages couvrant les questions clients et internes.
- 4
Faire circuler le PR/FAQ pour feedback
Envoyez le PR/FAQ aux parties prenantes clés : engineering, design, marketing, finance, leadership. Demandez des retours écrits avant toute réunion. Le document doit se suffire à lui-même : si un lecteur a besoin d'explications orales pour comprendre, le PR/FAQ n'est pas assez clair. Comptez 1 à 2 semaines de feedback asynchrone. Output : PR/FAQ annoté avec les retours des parties prenantes.
- 5
Itérer sur le PR/FAQ jusqu'à convergence
Le premier draft est rarement le bon. Amazon fait souvent 5 à 10 itérations avant d'atteindre un PR/FAQ qui satisfait tout le monde. Chaque itération affine le problème, précise la solution, anticipe de nouvelles objections. Si le PR/FAQ ne converge pas après plusieurs itérations, c'est peut-être que le problème n'est pas assez clair ou que la solution n'est pas assez différenciante. Output : PR/FAQ final validé par le leadership.
- 6
Créer les maquettes visuelles (optionnel mais recommandé)
Chez Amazon, le PR/FAQ est souvent accompagné de maquettes visuelles (mockups) qui illustrent l'expérience utilisateur décrite dans le press release. Ces visuels ne sont pas des wireframes techniques mais des représentations de ce que le client verra. Ils rendent le PR/FAQ tangible et testable auprès de vrais utilisateurs. Output : 3 à 5 écrans clés illustrant l'expérience décrite dans le PR.
- 7
Définir les métriques de succès
Avant de lancer le développement, définissez comment vous saurez que le produit a réussi. Quelles métriques valideront que le problème client est résolu ? Quel est le seuil de succès à 6 mois, 12 mois ? Chez Amazon, ces métriques sont intégrées dans la FAQ interne. Sans métriques de succès, vous ne pourrez pas évaluer si le produit a tenu la promesse du press release. Output : 3 à 5 métriques de succès avec seuils définis.
- 8
Lancer le développement en gardant le PR/FAQ comme boussole
Le PR/FAQ devient le document de référence pendant tout le développement. Quand une décision technique ou produit se présente, revenez au press release : "Est-ce que cette décision rapproche ou éloigne de l'expérience client décrite ?". Si une feature ne contribue pas à la promesse du PR, elle ne mérite pas d'être dans le MVP. Output : développement lancé avec le PR/FAQ comme critère de décision permanent.