L’un des aspects les plus importants de la conception et de la gestion des produits est la priorisation. Il n'y a qu'un nombre limité de ressources à la disposition d'une entreprise à un moment donné, de sorte que les efforts en matière de produits doivent être priorisés avec vigilance, de peur qu'une équipe ne finisse par passer un temps considérable à produire un travail sous-optimal ou pire, malavisé. Cela est particulièrement vrai dans une startup où les ressources sont extrêmement limitées et où les efforts en matière de produits peuvent souffrir ou bénéficier grandement d'une dépendance aiguë au chemin.

J'ai découvert que l'outil le plus simple mais le plus efficace pour prioriser les développements de produits est le [kanban](http://en.wikipedia.org/wiki/Kanban), ou du moins mon interprétation de celui-ci. Un tableau Kanban bien organisé peut aider une équipe à visualiser quelles idées de produits retiennent ou non l'attention actuellement, par quels membres de l'équipe et pourquoi. Il encourage une mentalité « lean » en plaçant les idées dans une séquence de conception, de développement et de validation uniquement lorsqu'il existe une capacité actuelle de le faire. Et pourtant, il constitue également une zone de préparation pour les idées de plus longue date qui attendent leur tour pour être produites.

Vous pouvez utiliser un logiciel numérique pour créer un kanban, tel que [Trello](http://trello.com), mais je préfère en fait les cartes de correspondance, le ruban adhésif et les marqueurs à l'ancienne. Pour en créer un, vous avez simplement besoin de ces matériaux et d’un espace mural décent. Vous écrirez des idées de produits sur les cartes, puis vous les collerez au mur sous des colonnes et des sections prédéfinies en fonction de leur appartenance. Un gros avantage de faire cela sur le mur est que vous pouvez très facilement utiliser le tableau pendant les réunions pour communiquer l'orientation du produit sans que tout le monde ne fouille dans son ordinateur portable. Un système Kanban mural est également plus personnalisable à la volée.

Les idées de produits, correspondant aux fiches qui affichent principalement leur étiquette (par exemple, « E-mail de résumé quotidien »), commencent dans la colonne « Glacière » la plus à gauche et se déplacent vers la droite dans les colonnes « Conception », « Développer » et « Valider » au fur et à mesure qu'elles progressent tout au long du processus de production. Les idées commencent dans la glacière, car toutes les idées méritent d'être justifiées avant d'attirer l'attention de l'équipe. Comme son nom l'indique, la glacière est l'endroit où les idées restent figées (c'est-à-dire que personne n'y travaille). Chaque fois que vous ou un autre membre de l'équipe pensez à une nouvelle idée de produit intelligente, elle doit être affichée sur le tableau dans la glacière, car elle peut alors être prise en compte pour la production.

J'aime diviser la glacière en sous-colonnes pour organiser les idées selon leurs objectifs principaux. Un objectif principal doit être déterminé pour chaque idée, même si cette idée sert plusieurs objectifs, car sinon il est difficile de justifier sa mise en œuvre et de valider plus tard son succès. Vous constaterez peut-être que les objectifs que vous décrivez sur le tableau varient d'un produit à l'autre, mais pour de nombreux produits, vous pouvez les résumer principalement à « l'acquisition », « l'activation » et « l'engagement » de l'utilisateur/client. Par exemple, l'exemple d'e-mail de résumé quotidien ci-dessus devrait probablement être placé sous « Engagement », car l'hypothèse principale derrière un tel e-mail serait qu'il pourrait augmenter la fréquence d'engagement et la rétention à long terme des utilisateurs. Une idée différente, telle que « Envoyer une page d'invitations », pourrait être placée sous « Acquisition », car elle est destinée à faciliter la distribution virale.

You can order product ideas under each column based on your current sense of their appropriate prioritization, but any such prioritization should be tentative since ideas ought to be pulled from the icebox as the result of iterative assessments about what's worth resources (perhaps as frequently as on a weekly or biweekly basis). It's also ideal to identify what measurable impact on the product will indicate success for an idea before it's taken out of the icebox and put into production (i.e. you could hypothesize that long-term user retention will increase 5% with the introduction of daily digest emails). Kanban is intended to help you prioritize by product ideas by potential impact, but this shouldn't be interpreted as creating a "waterfall" situation where ideas are prioritized concretely and deeply into the icebox. Otherwise, you'll find that you aren't properly making incremental product decisions based on the most up-to-date information at your disposal, and you could get yourself locked into unproductive product directions for months or more at a time.

Once it's determined that an idea should go into production – because it contains the greatest potential for addressing the most-pressing business needs (such as user engagement or acquisition) – its card gets moved from the icebox and into the "Design" column. This column in divided into two rows: "In Progress" on the top and "Done" below. An idea first goes into the "In Progress" row, which indicates that designers have begun actively working on its design. Once the designers have finished all anticipated design work for the idea, it moves to "Done", which is where it ought to stay, however briefly as possible, before moving into the "Develop" column.

Similarly to the "Design" column, the "Develop" column indicates when ideas are getting attention from developers, or engineers. The "Develop" column has two rows: "In Tracker" on top, and "In Progress" on bottom. Because I've used kanban to visualize product prioritization in conjunction with [Pivotal Tracker](http://pivotaltracker.com) for engineering prioritization, the "In Tracker" row indicates when a given product idea has been picked up by the engineering team and added to their own pivotal tracker projects, which allows them to break it down into specific engineering tasks. The presence of an idea in the "In Tracker" section of "Develop" rather than the "Done" section of "Design" indicates that its aims and designs have been explained and delivered to developers, and the idea is therefore in their court to proceed with execution. When they do start working on an idea (which should be quickly in a well-regulated kanban system), it moves to "In Progress" until complete.

Since kanban is best used with continuous deployment, there is no "Done" row for the "Develop" column; cards simply move to the "Validate" column, which indicates that their ideas have gotten deployed to actual users and are awaiting validation. The "Validate" column can be split into two rows if you have both a beta and live environment (i.e. when ideas get pushed into beta testing, they should go under a "Beta" row, and when they go fully live, a "Live" row). Notice that cards aren't simply taken off the board once they've been deployed, since the validation column is intended to remind a team that they need to follow up on whether the idea they built actually had its intended effect.

Les idées déployées restent dans la colonne de validation jusqu'à ce qu'il soit déterminé qu'elles ont réussi conformément au plan, auquel cas elles sont supprimées du tableau. Mais s'ils (peut-être plus probablement) échouent ou échouent, ils sont déplacés vers l'arrière du tableau jusqu'à l'étape jugée nécessaire (« Glacière » si l'équipe abandonne l'idée pour le moment, « Conception » si son échec est considéré comme un défaut de conception, ou « Développer » si elle est trouvée boguée ou mal implémentée). Parce qu'il est facile de proposer des normes peu élevées pour valider les idées après la production, vous feriez mieux d'utiliser l'hypothèse exacte que vous avez formulée à l'origine pour une idée pour déterminer si elle a été validée avec succès, même si cela signifie laisser une carte dans la colonne « Valider » pendant une période prolongée pour évaluer son effet.

Lorsque vous commencez à utiliser un tableau Kanban pour suivre l'exécution des idées de produits, vous remarquerez les goulots d'étranglement dans votre processus de production global. Les cartes peuvent commencer à s'accumuler dans les colonnes de conception, de développement ou de validation, indiquant que vous avez besoin de plus de ressources dans ces domaines si vous souhaitez produire autant à un moment donné. Et si vous ne parvenez pas à ajouter les ressources requises, vous saurez que vous devez réduire votre capacité ou diviser vos idées en morceaux plus petits, dans le but de maintenir chacune de vos ressources à pleine capacité (mais pas plus).

Si vous commencez à utiliser un tel tableau Kanban – dans l'espoir de discuter de l'orientation du produit lors de réunions régulières – vous trouverez inévitablement des moyens de le personnaliser en fonction des besoins de votre équipe et de votre produit. Et ces personnalisations doivent être effectuées dans le but d'augmenter la capacité du conseil d'administration à prioriser les idées de produits à plus fort impact et à accélérer le processus par lequel elles passent de la conception à la validation. Si vous y parvenez, vous aurez l'esprit tranquille en sachant que vous faites les meilleurs choix de produits possibles et que vous les appliquez efficacement.