Quel est le coût d’une idée ? sont-elles précieuses, ou ne sont-elles rien avant la mise en œuvre ? La gestion du développement de produits est construite sur des idées et des hypothèses. Une équipe de produits doit réagir rapidement à toute demande ou fluctuation du marché. Toute décision doit être prise pour augmenter la valeur du produit, les revenus ou la capitalisation. Pendant ce temps, le processus d'enquête doit être fait avec des ressources minimales. Cela signifie une avalanche d'idées à des moments ou des déficits budgétaires. Hypotheses in this avalanche may be connected with different aspects: Nouvelles stratégies de marketing. nouvelles caractéristiques . Adaptation à de nouveaux marchés ou niches. Création d’un nouveau produit à partir de zéro. Cependant, malgré la variété des hypothèses, l'analyse rétrospective peut montrer que l'ensemble des idées dans une niche de produit n'est pas infini. Les idées peuvent être développées dans des notes personnelles ou des chats d'entreprise sans système, et après la rotation des membres de l'équipe, l'équipe fournira la même enquête sans prendre en compte l'expérience précédente. Ces idées nécessitent un cadre approprié pour stocker, accumuler et fournir des informations sur le marché, indépendamment des changements dans la croissance de l'équipe ou de l'entreprise. Ce système viable prouve que les idées coûtent beaucoup et peuvent aider les gestionnaires de produits à économiser du temps et des ressources de l'entreprise. IdeaOps pour le développement de produits Le terme "IdeaOps" en tant que cadre de produit m'a été présenté pour la première fois dans le spectacle "Rebellious Businesses" de Katherine R. Lieber dans l'épisode podcast "Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations" (02.02.2025). Liens: https://creators.spotify.com/pod/profile/katya052/episodes/Stop-Bleeding-Out-Your-Competitive-Edge-Use-IdeaOps-To-Start-Capturing-And-Acting-On-Essential-Innovations-e2u9jrk. Dans cet article, je partage mon expérience personnelle de développement de produit qui complète l’idée du terme d’origine. Le terme “IdeaOps” en tant que cadre de produit m’a été présenté pour la première fois dans l’émission “Rebellious Businesses” de Katherine R. Lieber dans l’épisode podcast “Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations” (02.02.2025). . https://creators.spotify.com/pod/profile/katya052/episodes/Stop-Bleeding-Out-Your-Competitive-Edge-Use-IdeaOps-To-Start-Capturing-And-Acting-On-Essential-Innovations-e2u9jrk Dans cet article, je partage mon expérience personnelle de développement de produit qui complète l’idée du terme d’origine. Le noyau du cadre est la réalisation que chaque hypothèse est un actif de l’entreprise. This asset should have an owner, the whole context of the idea, artefacts that were created during the investigation process, links to other assets and the state of the decision. The recommendations described below will reveal the necessity of a process where it is highly important not only to fixate on the adoption or rejection of the hypothesis, but to show the whole tracing process with the history of thinking, time spent and intermittent results. Comme avec tout autre cadre, les principaux aspects seront introduits dans l'article: Comment construire le processus de collecte d'idées. Comment stocker les idées. Comment mettre en œuvre le cadre. Comment mesurer le succès et la valeur des changements. Comment construire le processus de collecte d’idées ? Le processus suit des recommandations communes et bien utilisées pour les demandes de changement à venir. Chaque idée doit passer par un pipeline: La Création . du contexte. à gauche. Les preuves. une estimation. La décision . Creation Chaque idée doit être capturée à l’intérieur de l’infrastructure de l’entreprise selon les règles : For every idea or request, a unique ticket should be created Sometimes an idea may be complex and require an overhaul of the product or market approach itself. It is necessary to teach the team how to decompose every hypothesis into valuable, but separable, improvements. This may create some additional bureaucracy and decrease the number of ideas – if it is hard to formalise, some team members may avoid idea fixation. In contrast, it helps to filter out raw suggestions that are hard to comprehend and estimate. During the process of establishing a framework, it is necessary to assess team compatibility to find the balance. Dans l’exemple exagéré ci-dessous, je fournis un processus de décomposition dans lequel une idée comme « gagnons quelques millions de dollars supplémentaires » est grande au cœur, mais une suggestion inutile pour le processus. Ticket should be created in unified software and available for other team members Les gestionnaires de produits de différentes équipes peuvent garder leurs idées en réserve dans leurs propres espaces locaux ou même dans des applications de notes privées.C’est mieux que l’absence d’une réserve, mais cela conduit à une myriade de formats et à l’indisponibilité pour analyser le « grand tableau ». Il est préférable d'utiliser des produits d'entreprise de grande taille où il est plus facile de lier des artefacts lors de l'enquête d'idées, tels que Microsoft Azure DevOps ou Atlassian Jira (selon les processus de l'équipe de développement). Le logiciel doit répondre aux exigences suivantes : Available for any team member by corporate account. It also helps with rights management and control during team rotation. Pour adapter le cadre aux besoins de l'entreprise, il est nécessaire d'avoir la possibilité de créer des champs supplémentaires ou des états personnalisés. Supervisé par l'entreprise.Comme mentionné ci-dessus, les idées devraient devenir les actifs de l'entreprise.Cela signifie une maintenance appropriée du stockage principal. Ticket should be named properly Because an idea/ticket is an asset of the company, the team have to learn how to classify and store these assets properly (and some advice will be provided below). One of the most important parameters is the name. Pendant la création du billet, en particulier pour les contributeurs non techniques, le nom peut être omis et des billets comme « Améliorer le site » peuvent être créés. Le billet peut être bien décrit dans la partie contextuelle, mais pour les futurs journaux il est nécessaire de fournir des informations supplémentaires dans le titre. Le titre du billet doit être unique et inclure la suggestion principale. Le billet ne devrait pas inclure des phrases de jargon ou des abréviations obscures pour être compréhensible pour les différentes équipes. Le titre du billet doit être construit par structure: Pour faire XXX en YYY pour changer ZZZ; en d'autres termes, contenir l'objet, le sujet et le résultat. Néanmoins, dans la vie réelle, cette règle peut sembler utopique; c'est pourquoi le flux de travail du billet devrait inclure des corrections de dénomination pendant l'enquête. Exemple avec la société fictive "PaperGone": Améliorer le site -> » » Redémarrez le scénario de paiement sur le site Web de "PaperGone" pour résoudre la création d'un compte obligatoire au moment du paiement Nous nous penchons sur quelques points dès le début : Il est nécessaire de réparer le site Web "PaperGone" (parce que nous pouvons avoir quelques sites Web et il est agréable de localiser le bon depuis le début). L’objectif est d’améliorer le processus de paiement. Le titre montre le problème de la création excessive de compte lors du paiement. Context The ticket should include a description of why the product team has to process the suggestion. Depending on company processes, context artefacts may be required or optional. Liste des informations contextuelles possibles : Description générale : de quoi s’agit-il ? Peut contenir des informations sur les changements du marché, les demandes des clients ou d'autres déclencheurs. Sources: copies of customer letters, interviews, reports or news from public sources. Histoires d’utilisateurs (le cas échéant): pour révéler le public cible et les scénarios à améliorer. The more detailed the context, the more likely the idea team will proceed to a positive decision during the investigation. Links That's one of the main features of the IdeaOps framework. Every new hypothesis should be analysed based on previous experience. Before the investigation process, it’s necessary to look for relative or similar tickets. Pour le billet "Réaliser le scénario de paiement sur le site "PaperGone" pour résoudre la création d'un compte obligatoire à l'achat", l'équipe devrait rechercher d'autres demandes sur le site PaperGone. Peut-être que l’année dernière, l’équipe de vente a posé la même question, mais nous avons pris la décision que la création d’un compte pendant le processus de paiement est obligatoire.Ou même nous avons eu une demande complétée « Ajouter la création d’un compte pour chaque processus d’achat sur le site Web de «PaperGone».Et nous ne pouvons pas avoir aucun des membres de l’équipe qui sont responsables de la mise en œuvre, pour demander pourquoi nous avons adopté une telle décision.Ou l’une des équipes a essayé de supprimer la création d’un compte obligatoire et l’équipe de produit a remarqué la diminution des données utilisateur pour envoyer des e-mails de marketing très importants et a annulé les changements. Ces liens ne devraient pas abortir l'enquête pour le billet, car la situation du marché peut avoir changé; la suggestion doit encore être révisée. cependant, la qualité de la recherche sera considérablement améliorée avec une compréhension de l'histoire entière. Of course, it’s possible that the ticket is completely unique and doesn't relate to anything before. Or the framework was established not so long ago and there’s no available data. In this case, it’s necessary to provide proper attachments and full information at the later stages of the process of the ticket, to improve work in future. Evidence Au cours de la phase "Evidence", l'équipe devrait fournir une enquête basée sur des informations connexes et des suggestions actuelles.Idées liées, abortées peuvent ressembler complètement différentes avec de nouvelles hypothèses et, ensemble, apporter un tout nouveau tableau à l'accent. Cette étape devrait fournir des artefacts tels que: Des minutes de réunion avec des discussions sur la mise en œuvre avec les parties prenantes, les clients, les clients potentiels et les développeurs. Recherche de marché. Interface des mock-ups Proof of Concept (POC) or results of A/B testing. Il est important d’établir un processus d’évaluation et de recueillir des données sur le temps passé à travailler sur chaque artefact. Indépendamment de la décision concernant ce billet particulier, de telles données peuvent fournir des informations précieuses sur les ressources qui doivent être dépensées pour des enquêtes similaires. Estimation L'équipe devrait fournir une estimation basée sur des preuves dans plusieurs aspects: Aspect Description Time and money How many hours of every kind of specialist should we spend to implement the suggestion? The idea should go through an estimation process and the total has to be attached to the ticket. Risks What are our risks to implement or omit this idea? Maybe we will lose a key client if we decide not to implement this feature. Or maybe we are losing money every day with a malfunctioning payment scenario on our website. Some ideas also may backfire - the team could implement a new feature and receive an additional revenue, but will have performance and stability issues. That’s why it’s necessary to investigate and document suggestions from different perspectives. This information also may be useful in the future during the discussion of why such a great idea wasn’t implemented in the product. Priority How important is this idea for the product or business at all? This estimation parameter is a tricky one and depends on the correctness of the product strategy. However, a well-provided “Evidence” stage may help to calculate the priority based on established rules and investigated data. There’re many approaches to priority, but simpler is better, so good old RFC 2119 works fine. Temps et argent Combien d’heures de chaque type de spécialiste devrions-nous consacrer à la mise en œuvre de la suggestion? L’idée doit passer par un processus d’estimation et le total doit être joint au billet. Risks Quels sont nos risques pour mettre en œuvre ou omettre cette idée? Peut-être que nous allons perdre un client clé si nous décidons de ne pas mettre en œuvre cette fonctionnalité.Ou peut-être que nous perdons de l'argent chaque jour avec un scénario de paiement qui ne fonctionne pas sur notre site Web.Certaines idées peuvent également reculer - l'équipe pourrait mettre en œuvre une nouvelle fonctionnalité et recevoir un revenu supplémentaire, mais aura des problèmes de performance et de stabilité.C'est pourquoi il est nécessaire d'enquêter et de documenter des suggestions de différentes perspectives. Ces informations peuvent également être utiles à l’avenir lors de la discussion sur la raison pour laquelle une telle grande idée n’a pas été mise en œuvre dans le produit. Priorité Ce paramètre d’estimation est un paramètre compliqué et dépend de l’exactitude de la stratégie du produit. Cependant, une étape « Evidence » bien fournie peut aider à calculer la priorité en fonction des règles établies et des données examinées. Il existe de nombreuses approches à la priorité, mais plus simple est mieux, donc le bon vieux RFC 2119 fonctionne bien. Les références : Clegg, D. (1994). méthode de cas Fast-Track: une approche RAD. Bradner, S. (1997). Mots clés pour l'utilisation dans les RFCs pour indiquer les niveaux d'exigences (RFC 2119). Internet Engineering Task Force. Disponible à: https://www.rfc-editor.org/rfc/rfc2119. References: Clegg, D. (1994). méthode de cas Fast-Track: une approche RAD. Gérard S. (1997 ) (RFC 2119). Internet Engineering Task Force. disponible à l'adresse suivante: . Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigences https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 décision La phase de résultat, basée sur les analyses et les artefacts précédents, est la phase la plus importante pour IdeaOps. There are a few options for how each request may end: Nous le ferons - il est nécessaire d'écrire pourquoi cela ressemble à une idée rentable et ce qui nous aide à prendre la bonne décision.En outre, ce commentaire peut être utile pour une analyse ultérieure si le résultat valait ce qui était attendu. Peut-être que certaines données ont été recueillies incorrectement, ou que la valeur du résultat est faible. Néanmoins, le responsable du produit doit écrire un avis détaillé sur le rejet. Dans certaines demandes futures, il peut être révélé que cette demande particulière était redondante, mais si nous réfléchissons au tableau général, les préoccupations des responsables du produit peuvent être résolues. It’s nice, and there is some interest for our company, but not right now – when should we come back to this request so as not to abandon it in a gigantic backlog? What is wrong right now that makes it impossible to make a positive decision? Il est bon de le combiner avec une autre demande – construisons un plan pour le réviser avec une demande supplémentaire et la forme de ce processus. Sure, there are more scenarios, but in this article I want to show an example of thinking: Chaque demande doit être traitée à travers l'ensemble du pipeline et doit avoir un résultat approprié pour montrer aux autres membres actuels ou futurs de l'équipe la manière d'adopter la décision. Every request has to be processed through the whole pipeline and shall have a proper result to show other current or future team members the way of adopting the decision. Les gens peuvent faire des erreurs ou adopter la mauvaise décision en fonction de la situation et de leurs connaissances.Ce processus les oblige à documenter cette décision et aide l'entreprise à réviser et à apprendre sur la base de ces demandes ultérieurement. Comment récolter des idées Nous avons couvert les étapes de base du cadre, mais pour une bonne utilisation d'un backlog de demande générale, il est nécessaire de construire un système de stockage qui aide tout membre de l'équipe à trouver toute idée active ou archivée en un temps minimal. La meilleure façon d'y parvenir est de trancher les données via un ensemble de filtres et de paramètres. Il est très important de stocker toutes les idées dans un espace unifié, accessible aux différentes équipes. Techniquement, il est possible d'utiliser n'importe quel logiciel de feuille de calcul comme stockage pour les demandes/idées et de les filtrer en utilisant des attributs en colonnes, mais il est plus facile et plus géré d'utiliser un grand produit pour le travail d'équipe comme Atlassian Jira ou Microsoft Azure DevOps. Chaque demande peut avoir des dimensions différentes : Le produit. Domaine des affaires. risques d’affaires. fonctionnalité du produit. Demande de phase. à la source. Plus de filtres sont disponibles pour le backlog d’idée, plus les membres de l’équipe possédant une variété d’expériences et de modes de pensée peuvent y naviguer. La liste des dimensions n’est pas complète et ne fournit qu’un exemple de modes de décomposition. Je recommande d’organiser quelques séances de brainstorming pour révéler tous les filtres appropriés pour le backlog et les rafraîchir de temps à autre. En outre, il est nécessaire d’établir des règles pour ajouter les options de filtre et attribuer un rôle d’administrateur. Chaque option doit consister en une liste fermée d’éléments; sinon, toute la structure va tomber en panne. Chaque aspect peut être révélé comme un groupe de filtres ; la complexité dépend d’un produit et de la structure de l’entreprise. produit Les entreprises peuvent développer peu de produits ou de générations de produits, de sorte que tout ticket doit être connecté au produit, ou à la plate-forme de génération de produits. Ce bloc peut consister en des noms de produits: Site Web, Produit 1 pour SaaS, Produit 2 pour On-Prem, etc. Ou aider à localiser la plate-forme: Frontend, Backend, iOS / iPadOS, Android. Dans un exemple précédent, nous avons mentionné une demande fictive, " dans la société PaperGone, donc je vais fournir des paramètres théoriquement possibles pour l'entrée correcte de cette demande. Rework the payment scenario on the 'PaperGone' website to fix mandatory account creation at checkout Domaine d’entreprise Cet attribut devrait aider à localiser la personne responsable pour traiter la demande. Est-ce une idée d'amélioration du marketing, ou est-ce lié à nos problèmes d'insertion? Ou est-ce une fonctionnalité de produit supplémentaire qui nous aide à promouvoir les clients actuels? Le domaine d'entreprise est un attribut de base pour l'itinérance des demandes à travers différents départements et gestionnaires. Exemples: Ventes, Marketing, Support client, Comptabilité, Développement, QA, etc. Business risk Chaque demande peut couvrir un risque d'entreprise différent. Certaines d'entre elles peuvent révéler des défauts architecturaux dans l'infrastructure de produit, ou quelque chose de lié aux ventes et aux concurrents. L'auteur de la demande devrait comprendre quelle est l'option la plus appropriée. Cette dimension concerne des problèmes possibles dans quelque chose: ventes (ne peut pas vendre sans elle), upselling (ne peut pas développer des comptes courants sans elle), sécurité (préoccupation d'exploit potentiel), concurrents (ce que nous n'avons pas), légal (nos formulaires d'accord ne sont pas si bons). Fonctionnalité du produit Pour développer des produits complexes, il est nécessaire de savoir ce que vous gérez. Les produits d'une entreprise se composent de dizaines de fonctionnalités, et de nouvelles demandes peuvent être des améliorations à certaines d'entre elles ou liées à quelque chose existant. La façon d'atteindre cette décomposition est décrite dans l'article - "https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition". La façon d'atteindre cette décomposition est décrite dans l'article - "https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition". Demande de phase Aide à localiser l'état actuel d'une demande en fonction du flux de travail IdeaOps. Exemple de la structure de l’étape : Nouveau - Personne n'a traité la demande. Pour estimer - la demande passe par les étapes de liens, de preuves, d'estimation. Decision stages: Approved - the team has decided to implement the request. Rejected - the team declined the request and provided an explanation of why the idea was rejected. Postponed - the team decided that it’s impossible to process the request in the current situation. Committed - the development stage, that requires is in the process of realisation. Fermé - la dernière étape pour indiquer l'achèvement de la demande. Bien sûr, selon le processus, il est possible d’élargir la structure des étapes pour refléter le processus de manière plus détaillée, mais il est toujours nécessaire de trouver un équilibre entre la transparence et la bureaucratie excessive. Source Les idées peuvent être créées par différents acteurs, et le temps de traitement peut varier en fonction de la source. Par exemple: parties prenantes, clients, ventes, ingénieurs de support client, développeurs. Ce système de paramètres aide à trouver toute demande nouvelle ou passée avec un minimum de temps; cependant, en même temps, il peut être un obstacle pour les membres de l'équipe car il complique la façon dont les idées sont partagées. Comment mettre en œuvre le cadre Comme avec toute théorie, la partie la plus compliquée est d'intégrer le cadre IdeaOps dans les processus quotidiens d'une entreprise. Évidemment, les processus devraient être adaptés, révisés, ou seulement partiellement utilisés selon la structure de l'entreprise, mais l'idée générale est d'aider à fournir un meilleur traitement des billets qu'il n'y en avait auparavant, et même une partie du cadre le fera bien. Cependant, dans n’importe quelle entreprise, il y a une liste fermée d’obstacles à surmonter. Personne ne sait comment et pourquoi créer des billets de la « bonne façon ». Il y a beaucoup de discussions dans les réunions ou via les messagers qui ne sont pas reflétées dans l'élément de travail de l'idée. Certaines sources ne peuvent pas fournir des données structurées via un système de backlog centralisé. Let’s cover them step by step. Teach team members how to work with a general backlog Créez un ticket de demande de modèle et fournissez un exemple. Les modèles pourraient être décrits dans la documentation de l'entreprise ou même développés dans le logiciel (Atlassian Jira ou Microsoft Azure DevOps sont parfaitement bien avec eux). Les nouveaux éléments de travail de demande devraient consister en champs et paramètres nécessaires avec des marquages nécessaires et non nécessaires, de sorte qu'il puisse être impossible d'omettre des données importantes. The examples should establish the standards of naming and content structure. Publier le flux de travail de l'idée / de la demande, afin que tout le monde puisse comprendre ce que chaque étape signifie. Broadcast a message that this template is the only way to submit the request. Optionally, if the team structure is not complicated, it can be justified via a meeting. Reject the requests that are not in line with the new process. Definitely, the most complicated stage of new process adoption, because it needs balance not to disrupt the company’s operations. For highly important and prompt requests, it’s fine to fix them yourself, showing them as examples. La phase d’adoption révélera des dizaines de cas spéciaux, et après quelques itérations, l’équipe mettra en œuvre le nouveau processus. Communiquer en dehors de la demande It’s natural to discuss topics in messengers, via email or in meetings, because it’s fast and prolific. Nevertheless, the idea of a framework to store all data in one place, to be able to access data again and again, to learn and analyse it, is important. Still, there are a few ways to fix the process: Chaque réunion ou chaîne de messages doit être liée à l'ID de billet de demande, de sorte que plus tard il sera possible de trouver l'activité en fonction du numéro d'identification unique de la demande. For every meeting about the request, meeting minutes have to be created. In the era of AI assistants, it’s not so complicated and helps a lot in further analysis. Oui, certaines négociations peuvent encore être perdues dans les discussions privées, mais l'existence d'un facilitateur général pour chaque demande aide à diriger les données vers le stockage. Résoudre les scénarios borderline Il y a toujours des scénarios où un système de backlog centralisé ne fonctionne pas. Peut-être que c'est une demande d'un actionnaire très occupé, ou des partenaires qui ne peuvent pas avoir accès au système interne. Et c'est bien. The requests from a stock owner should be processed by one of the product leads in X time. This role has to create the request and collect the necessary data by themselves. Les demandes de partenaires doivent être traitées par les gestionnaires de compte ou le support technique, en fonction du rôle des partenaires. As usual in establishing new processes, it is important to document and declare all steps in public documentation to fix agreements and small details. Success metrics La mise en œuvre du nouveau processus nécessite beaucoup de temps et d’efforts, de sorte que quelques mesures pourraient aider à suivre son adoption. Temps d’insight L’un des principaux objectifs du cadre IdeaOps est de traiter les idées depuis leur naissance jusqu’à une décision analysée. Cette métrique montre le nombre de jours entre la création et l’atteinte de l’un des états de décision et aide à révéler les objectifs organisationnels suivants : La rapidité des réponses aux clients ou aux parties prenantes dans différentes équipes. Nombre de réponses bloquées dont le temps de traitement dépasse les limites établies. Affiche la relation entre la complétude et la qualité des données initialement fournies et le temps nécessaire pour traiter une demande. Indirectement montre comment la présence de demandes connexes avec des estimations précédemment fournies sur des idées similaires accélère la prise de décision. Time spent metric Les demandes compréhensibles et correctes devraient réduire au minimum le temps qu'un gestionnaire prend pour les traiter. Une mesure «temps-à-conscience» est proposée pour mesurer le temps de traitement global, qui est lié au processus lui-même. Cependant, il est également important de mesurer le temps de travail du gestionnaire responsable qui a participé à ce processus. Bien sûr, certaines idées nécessitent des semaines d'enquête, tandis que certaines sont à peu près de la couleur d'un bouton. Mais la valeur moyenne par trimestre ou par an pourrait encore aider à révéler des améliorations dans le temps passé. Si de plus en plus de demandes ont des estimations liées et des décisions détaillées, cela affectera le temps de traitement global par gestionnaire. Niveau de couverture Il est nécessaire de relever le niveau métrique avec de nouvelles et de vieilles demandes pour atteindre une base idéale de propositions. What has to be dealt with Lors de l’adoption, plusieurs problèmes doivent être surmontés : Team members should know that using personal spaces for notes is a bad practice, which leads to the loss of important company data. If anything has to be documented, it should be done in the request. The same applies to meeting summaries. If any Proof of Concept artefact was created or an idea was estimated, all numbers related to completed work and future activities should be included in the request. Otherwise, this time may be lost and spent without reusability. Une idée rejetée peut être traitée et considérée de tous les côtés, mais sans une conclusion appropriée, c'est juste une perte de temps.La prochaine idée similaire nécessitera le même temps de traitement, car les résultats précédents ne montrent pas la vraie raison du rejet, de sorte que l'entreprise perdra constamment de l'argent, surtout si la structure de l'équipe change au fil du temps. The adoption manager has to provide regular reviews of closed and stuck requests to improve the process. Conclusion Le cadre IdeaOps proposé est un moyen idéaliste de traiter une grande quantité de données différentes et parfois incompréhensibles dans une structure gérable. Il nécessite un travail d'équipe bien coordonné où chaque membre comprend que chaque morceau de données et de décision est quelque chose de plus grand, qu'un jour peut aider à atteindre de nouveaux sommets pour l'entreprise et améliorer la situation globale de l'entreprise. Une fois traitées correctement, et même rejetées, une proposition insignifiante de l'un des clients peut être incluse dans un changement général de la stratégie de produit, car elle contient une analyse claire de la situation, des estimations et des conclusions intelligentes sur la raison pour laquelle elle n'était pas importante en tant qu'amélioration indépendante, mais semble complètement différente dans une nouvelle Working on the idea catalogue is just as important as working on revenue, and it’s up to each company to follow the path to improving it.
