11 private links
Une façon intéressante de définir un produit selon le marché auquel on s'adresse
Le déclin d'Opera est consommé : ils développent des applications de crédit à taux très élevés dans des marchés émergents, n'ont aucune culture produit, sont maintenant à la traîne sur tout. C'est triste.
Je trouve cet article inspirant à de multiples niveaux.
Le découpage de roadmap en différentes parties, le calculateur de confiance, la méthode de construction d'un produit. Tout ça est très chouette.
Je ne suis pas surpris par cette manoeuvre absolument ignoble de revente de handles. Et c'est bien pour ça que je vais garder mon compte. Mais franchement, quel gestion produit désastreuse.
Un article déprimant, mais utile.
Si vous bossez dans "la tech", lisez-le, et essayez de ne pas faire ces choses
Trouver le product-market-fit, le graal de tous les produits web, c'est pas si facile ... (je suis d'ailleurs étonné de voir que Slack a mis plusieurs années avant de sortir IRC ...)
Je n'ai que rarement vu ou lu quoi que ce soit articulant aussi bien les cartes de Wardley, le DDD, les team topologies dans le but de livrer vite et bien. C'est un présentation incroyablement instructive.
C'est vrai que le logiciel conçu par des gens qui n'ont pas été data-driven est souvent différent, et conçu avec des objectifs de qualité différents.
Pour une fois, ce sont des critiques de Windows que j'approuve, parce qu'elles se concentrent sur l'expérience utilisateur. C'est aussi une belle réflexion sur les erreurs d'une stratégie produit.
Des éléments vous permettant de mettre en oeuvre différents outils alignant les évolutions de votre produit avec la vision que vous construisez pour celui-ci
Si vous voulez avoir un CV avec de jolies icônes raisonnablement à jour (parce que certains produits changent de logo). Ce site est une chouette solution (je me dis que ce serait cool aussi dans Structurizr).
Très chouette façon de parler des features applicatives
Une belle critique du concept de roadmap
Pour quelqu'un comme moi qui préfère l'asciidoc et PlantUML, je ferais vraiment mieux d'utiliser Gitlab, non ?
La progression des équipes agiles vers plus d'intégration en amont : designers, product managers, peuvent aussi être des membres de l'équipe.
Très bel argument contre le data-driven development et la gestion de produit confié aux représentants de la majorité (les hommes blancs comme moi)
Une belle méthode d'estimation (parce que c'est en fait nécessaire) qui tient compte des limites humaines.
J'avais vu passer les tweets. Et découvrir maintenant que tout ça est une pure astuce me paraît intéressant.
Quand je dis aux gens que tous les POCs vont en prod, c'est aussi ce que je veux dire : les gens n'itèrent pas, ils ajoutent de la fonctionnalité à un soft déjà mal conçu.
Ca semble antinomique, et pourtant c'est vrai : c'est le succès d'un produit qui crée la complexité.