Un point central dans cette stratégie est aussi que, aussi doué soient les product managers, ou utile soient les session d'user testing, absolument rien ne remplace le feed-back de vrais utilisateurs qui utilisent vraiment le produit pour de vrai.
Plutôt que de tergiverser pendant des heures pour savoir si #feature doit marcher comme ci ou comme ca, tu fait un proto rapide qui te donne une réponse (ou un bout), et tu corriges le tir.
Tout l'art tient dans la créativité de faire des protos qui tiennent la route (faut pas prendre les gens que pour des cons), et pour les ingénieurs de branler le tout pour que ca soit maintenable et évolutif (parce que, ouais, lean ne veut pas forcément dire travail de gougnafier).
L'elevator pitch ressemble en général à:
- la pire chose que tu puisses faire, c'est construire le mauvais produit
- le meilleur moyen de construire qq chose vite, c'est de trouver rapidement ce qu'il ne faut pas construire
- on pas la moindre foutue idée d'où on va ni comment on y va, alors on improvise et on se demerde (celle la, elle est de moi. Elle vend pas des masses, mais elle fait marrer les gens du milieu).
C'est une philosophie foutrement utile quand t'as une grosse part d'incertitude/exploration/créativité sur le produit, que t'as pas mal d'utilisateurs et que tu peux te permettre des écarts de conduite pour une portion d'entre eux.
D'où le fait que toute startup ayant du succès est rompue à ces techniques, vu qu'une startup à vachement tendance à tester de nouvelles idées de produit.
il se trouve que dans le logiciel, en général, ya vachement d'incertitude, mais pas forcément. Si ton boulot, c'est les logiciels de gestion de feuilles de payes, ya vachement moins d'incertitude quand même (ca veut pas dire que tu gagneras pas à ce genre de technique, mais c'est vachement plus risqué, et t'as beaucoup moins du retour sur investissement).
[^] # Re: Pas évident
Posté par groumly . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 4.
Un point central dans cette stratégie est aussi que, aussi doué soient les product managers, ou utile soient les session d'user testing, absolument rien ne remplace le feed-back de vrais utilisateurs qui utilisent vraiment le produit pour de vrai.
Plutôt que de tergiverser pendant des heures pour savoir si #feature doit marcher comme ci ou comme ca, tu fait un proto rapide qui te donne une réponse (ou un bout), et tu corriges le tir.
Tout l'art tient dans la créativité de faire des protos qui tiennent la route (faut pas prendre les gens que pour des cons), et pour les ingénieurs de branler le tout pour que ca soit maintenable et évolutif (parce que, ouais, lean ne veut pas forcément dire travail de gougnafier).
L'elevator pitch ressemble en général à:
- la pire chose que tu puisses faire, c'est construire le mauvais produit
- le meilleur moyen de construire qq chose vite, c'est de trouver rapidement ce qu'il ne faut pas construire
- on pas la moindre foutue idée d'où on va ni comment on y va, alors on improvise et on se demerde (celle la, elle est de moi. Elle vend pas des masses, mais elle fait marrer les gens du milieu).
C'est une philosophie foutrement utile quand t'as une grosse part d'incertitude/exploration/créativité sur le produit, que t'as pas mal d'utilisateurs et que tu peux te permettre des écarts de conduite pour une portion d'entre eux.
D'où le fait que toute startup ayant du succès est rompue à ces techniques, vu qu'une startup à vachement tendance à tester de nouvelles idées de produit.
il se trouve que dans le logiciel, en général, ya vachement d'incertitude, mais pas forcément. Si ton boulot, c'est les logiciels de gestion de feuilles de payes, ya vachement moins d'incertitude quand même (ca veut pas dire que tu gagneras pas à ce genre de technique, mais c'est vachement plus risqué, et t'as beaucoup moins du retour sur investissement).