¿Cal é o custo dunha idea? son valiosas, ou non son nada antes da implementación? A xestión do desenvolvemento de produtos está construída sobre ideas e hipóteses. Un equipo de produtos debe reaccionar rapidamente a calquera demanda ou fluctuación do mercado. Calquera decisión debe ser tomada para aumentar o valor do produto, as receitas ou a capitalización. As hipóteses nesta avalancha poden estar relacionadas con diferentes aspectos: New marketing strategies. Novas características . Adaptation for new markets or niches. Investigación para crear un novo produto desde cero. Nevertheless, despite the variety of assumptions, retrospective analysis may show that the whole backlog of ideas in one product niche isn’t endless. Ideas may be developed in personal notes or company chats without a system, and after team member rotation, the team will provide the same investigation without taking previous experience into account. These ideas require a proper framework for storing, accumulating and providing insights about the market, regardless of changes in the team or company growth. This viable system proves that ideas cost a lot and may help product managers to save time and company resources. IdeaOps for product development O termo "IdeaOps" como un marco de produto foi introducido por primeira vez para min no programa "Empresas Rebeldes" de Katherine R. Lieber no episodio do podcast "Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations" (02.02.2025). Enlace: 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. Neste artigo comparto a miña experiencia persoal de desenvolvemento de produtos que complementa a idea do termo orixinal. O termo "IdeaOps" como un marco de produto foi introducido por primeira vez para min no programa "Businesses rebeldes" de Katherine R. Lieber no episodio do 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 Neste artigo comparto a miña experiencia persoal de desenvolvemento de produtos que complementa a idea do termo orixinal. O núcleo do marco é a comprensión de que cada hipótese é un activo da empresa. Este activo debe ter un propietario, todo o contexto da idea, os artefactos que se crearon durante o proceso de investigación, os enlaces a outros activos e o estado da decisión.As recomendacións descritas a continuación revelarán a necesidade dun proceso onde é moi importante non só fixarse na adopción ou rexeitamento da hipótese, senón que mostre todo o proceso de rastrexo coa historia do pensamento, o tempo gasto e os resultados intermitentes. Como con calquera outro marco, os aspectos principais serán introducidos no artigo: Como construír o proceso de recollida de ideas. How to store the ideas. Como aplicar o marco. Como medir o éxito e o valor dos cambios. Como construír o proceso de recollida de ideas? The process follows common and well-used recommendations for upcoming change requests. Every idea has to go through a pipeline: da creación. O contexto. á esquerda. Unha proba. Unha estimación. unha decisión. Creación Cada idea debe ser capturada dentro da infraestrutura da empresa segundo as regras: 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. In the exaggerated example below, I provide a decomposition process where an idea like “Let’s earn a few additional millions of dollars” is great at its core, but a useless suggestion for the process. However, it’s fine to create a ticket about a new payment workflow because we have noticed problems with the customers' journey. That’s our ticket. Ticket should be created in unified software and available for other team members Os xestores de produtos de diferentes equipos poden manter as súas ideas bloqueadas nos seus propios espazos locais ou mesmo nas aplicacións de notas privadas.É mellor que a ausencia dun bloqueo en absoluto, pero leva a unha miríade de formatos e á falta de dispoñibilidade para analizar a "grande imaxe". É mellor usar algún produto corporativo grande onde sexa máis doado vincular artefactos durante a investigación de ideas, como Microsoft Azure DevOps ou Atlassian Jira (dependendo dos procesos do equipo de desenvolvemento). Unified software should respond to the requirements: Available for any team member by corporate account. It also helps with rights management and control during team rotation. Suitable for customisation. For tailoring the framework to company needs, it’s necessary to have the opportunity to create additional fields or custom statuses. Supervised by company. As aforementioned, ideas should become the company's assets. It means proper maintenance of the main storage. Ticket should be named properly Debido a que unha idea / billete é un activo da empresa, o equipo ten que aprender a clasificar e almacenar estes activos correctamente (e algúns consellos serán proporcionados a continuación). Durante a creación do billete, especialmente para contribuíntes non técnicos, podería omitirse o nomeamento e poderían crearse billetes como "Mellorar o sitio web".O billete pode estar ben descrito na parte de contexto, pero para futuros rexistros é necesario proporcionar información adicional no título. Ticket title should be unique and include the main suggestion. Ticket shouldn’t include jargon phrases or obscure abbreviations to be understandable for different teams. Ticket title should be built by structure: To do XXX in YYY to change ZZZ; in other words, contain object, subject and result. Still, in real life, this rule may sound utopian; that's why ticket workflow should include naming corrections during investigation. Exemplo coa empresa ficticia "PaperGone": Improve the website -> " » Reescribe o escenario de pagamento no sitio web de "PaperGone" para solucionar a creación de conta obrigatoria no checkout Aquí imos dirixir algúns aspectos desde o principio: It’s necessary to fix the "PaperGone" website (because we may have a few websites and it’s nice to locate the correct one from the beginning). A petición é de mellorar o proceso de pagamento. O título mostra o problema coa creación excesiva de conta durante o pago. Context O billete debe incluír unha descrición de por que o equipo do produto ten que procesar a suxestión.En función dos procesos da empresa, os artefactos de contexto poden ser necesarios ou opcionais. List of possible context information: Descrición xeral: de que se trata? Why should we investigate it? May contain information about market changes, customer requests or other triggers. Fontes: copias de cartas de clientes, entrevistas, informes ou noticias de fontes públicas. Historias de usuarios (se é o caso): para revelar o público obxectivo e os escenarios para mellorar. Canto máis detallado sexa o contexto, máis probable é que o equipo de ideas proceda a unha decisión positiva durante a investigación. 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. For the ticket “Rework the payment scenario on the “PaperGone” website to fix mandatory account creation at checkout” the team should search for other requests about the PaperGone Website. Maybe last year the sales team asked the same question but we made a decision that account creation during the payment process is mandatory. Or even we had a completed request “Add account creation for every purchase process on “PaperGone” website”. And we may not have any of the team members available who are responsible for the implementation, to ask why we adopted such a decision. Or one of the teams tried to remove the mandatory account creation and the product team noticed the decrease of user data to send very important marketing emails and aborted the changes. In any case, relative tickets or changes should be added to the new one to start the hypothesis check. These links should not abort the investigation for the ticket, because the market situation may have changed; the suggestion still has to be revised. However, the quality of the research will be drastically improved with an understanding of the whole story. 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 Durante a fase de "evidencia", o equipo debe proporcionar unha investigación baseada na información relacionada e as suxestións actuais.Conectadas, as ideas abortadas poden parecer completamente diferentes con novas hipóteses e, xuntos, traer unha nova imaxe enteira ao foco. This stage should provide artefacts such as: Meeting minutes with discussions about implementation with stakeholders, customers, potential clients, and developers. Market research. Interface mock-ups. Proof of Concept (POC) or results of A/B testing. It’s important to establish a process of evaluation and to gather data on time spent working on every artefact. Regardless of the decision about this particular ticket, such data can provide valuable insights about the resources that have to be spent on similar investigations. Estimation Team should provide estimation based on evidence in a few 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. Time and money Cantas horas de cada tipo de especialista debemos gastar para implementar a suxestión? A idea debe pasar por un proceso de estimación e o total debe anexarse ao billete. 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. Prioridade Este parámetro de estimación é un parámetro complicado e depende da corrección da estratexia do produto. Con todo, unha fase de "evidencia" ben provista pode axudar a calcular a prioridade baseada en regras establecidas e datos investigados. There’re many approaches to priority, but simpler is better, so good old RFC 2119 works fine. As referencias: Clegg, D. (1994). Método de caso Fast-Track: Unha aproximación RAD. Bradner, S. (1997). (RFC 2119). Internet Engineering Task Force. Available at: . Key words for use in RFCs to Indicate Requirement Levels https://www.rfc-editor.org/rfc/rfc2119 References: Clegg, D. (1994). . Addison-Wesley Case Method Fast-Track: A RAD Approach Bradner, S. (1997). (RFC 2119). Internet Engineering Task Force. dispoñible en: . Key words for use in RFCs to Indicate Requirement Levels https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 Decisión The result stage, based on the previous analysis and artefacts, is the most important stage for IdeaOps. According to the framework, the result comment provides general insight for the future. There are a few options for how each request may end: Imos facer isto - é necesario escribir por que soa como unha idea rendible e o que nos axuda a tomar a decisión correcta. Tamén, este comentario pode ser útil para a análise posterior se o resultado valeu o que se esperaba. Quizais algúns datos foron recollidos incorrectamente, ou o valor do resultado é baixo. Con todo, o xestor de produto ten que escribir unha opinión detallada sobre a rexeitamento. nalgunhas solicitudes futuras, pode revelarse que esta solicitude particular era redundante, pero se o repensamos na imaxe xeral, as preocupacións dos xestores de produtos poden ser resoltas. É bo, e hai algún interese para a nosa empresa, pero non agora - cando debemos volver a esta solicitude para non abandonalo nun retroceso xigante? It’s good if we combine it with another request – let’s build a plan to revise it with an additional request and the form of this process. Por suposto, hai máis escenarios, pero neste artigo quero mostrar un exemplo de pensamento: 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. Cada solicitude debe ser procesada a través de todo o gasoduto e debe ter un resultado axeitado para mostrar aos outros membros actuais ou futuros do equipo a forma de adoptar a decisión. People can make mistakes or adopt the wrong decision according to the situation and their knowledge. This process obliges them to document this decision and helps the company to revise and learn based on these requests later. Como crear ideas Cubrimos os pasos básicos do marco, pero para o correcto uso dun bloqueo de solicitudes xerais é necesario construír un sistema de almacenamento que axude a calquera membro do equipo a atopar calquera idea activa ou arquivada nun tempo mínimo. A mellor forma de lograr isto é cortar datos a través dun conxunto de filtros e parámetros. É moi importante almacenar todas as ideas nun espazo unificado, accesible para diferentes equipos. Tecnicamente, é posible usar calquera software de follas de cálculo como almacenamento para solicitudes/ideas e filtralos usando atributos en columnas, pero é máis fácil e máis manexable usar un gran produto para o traballo en equipo como Atlassian Jira ou Microsoft Azure DevOps. Estes produtos poden axudar a organizar fluxos de traballo, a xestión de fase correcta e o control de acceso baseado en funcións. Every request may have different dimensions: Product. Dominio de negocios. Riscos de negocio. Funcionalidade do produto. Fase de solicitude. Unha fonte. The more filters are available for the idea backlog, the more team members with a variety of experience and ways of thinking may navigate through it. The list of dimensions isn’t complete and provides just an example of ways of decomposition. I recommend organising a few brainstorm sessions to reveal all suitable filters for the backlog and refresh them from time to time. Also, it’s necessary to establish rules for adding the filter options and assign an administrator role. Every option has to consist of a closed list of items; otherwise, the whole structure will fall apart. Cada aspecto pode ser revelado como un grupo de filtros; a complexidade depende dun produto e da estrutura da empresa. Product Companies may develop few products or generations of products, so any ticket should be connected to the product, or platform of product generation. This block may consist of product names: Website, Product 1 for SaaS, Product 2 for On-Prem, etc. Or help to locate the platform: Frontend, Backend, iOS/iPadOS, Android. In an earlier example, we mentioned a fictional request, " " na empresa PaperGone, así que vou proporcionar teoricamente posibles parámetros para a entrada correcta desta solicitude. Reescribe o escenario de pagamento no sitio web de "PaperGone" para solucionar a creación de conta obrigatoria no checkout Dominio de negocios This attribute should help to locate the responsible person to process the request. Is this idea about marketing improvements, or is it connected to our issues in onboarding? Or is it about additional product functionality that helps us to upsell current customers? The business domain is a core attribute to route requests through different departments and managers. Examples: Sales, Marketing, Customer Support, Accounting, Development, QA, etc. Business risk Every request may cover a different company risk. Some of them may reveal architectural flaws in product infrastructure, or something connected with sales and competitors. The author of the request should realise what the most suitable option is. This dimension is about possible problems in something: sales (cannot sell without it), upselling (cannot grow current accounts without it), security (potential exploit concern), competitors (something that we don’t have), legal (our agreement forms are not so good). Funcionalidade do produto Para cultivar produtos complexos, é necesario saber o que está a xestionar.Os produtos dunha empresa consisten en decenas de características, e as novas solicitudes poden ser melloras a algunhas delas ou relacionadas con algo existente. The way to achieve this decomposition is described in the article - “ ”. https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition O xeito de lograr esta descomposición descríbese no artigo - " ”. https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition Request stage Helps to locate the current status of a request according to the IdeaOps workflow. Un exemplo da estrutura do escenario: New - nobody has processed the request. Para estimar - a solicitude pasa polas etapas de Enlaces, Evidencia, Estimación. 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. Closed - the final stage to indicate the completion of the request. Sure, depending on the process, it’s possible to expand the stages structure to reflect the process in a more detailed way, but it’s always necessary to find a balance between transparency and excessive bureaucracy. Source As ideas poden ser creadas por diferentes actores, e o tempo de procesamento pode variar dependendo da fonte. Por exemplo: partes interesadas, clientes, vendas, enxeñeiros de soporte ao cliente, desenvolvedores. This system of parameters helps to find any new or past request with minimal time; however, at the same time, it may be an obstacle for the team members because it complicates the way ideas are shared. The intricacy of the system should reflect the company structure, so my recommendation is to start with the easiest parameters and delve deeper according to the team's responses. How to implement the framework Como con calquera teoría, a parte máis complicada é a integración do marco IdeaOps nos procesos cotiáns dunha empresa. Obviamente, os procesos deben ser adaptados, revisados ou só parcialmente utilizados segundo a estrutura da empresa, pero a idea xeral é axudar a proporcionar un mellor procesamento de billetes que antes, e mesmo parte do marco fará isto ben. Con todo, en calquera empresa, hai unha lista pechada de obstáculos que hai que afrontar. Nobody knows how and why to create tickets in the “right way”. Hai moitas discusións en reunións ou a través de mensaxeiros que non se reflicten no elemento de traballo da idea. Some sources cannot provide structured data via a centralised backlog system. Let’s cover them step by step. Teach team members how to work with a general backlog Create a template request ticket and provide an example. Os modelos poderían ser descritos na documentación da empresa ou mesmo desenvolvidos no software (Atlassian Jira ou Microsoft Azure DevOps están perfectamente ben con eles). Os novos elementos de traballo de solicitude deben consistir en campos e parámetros necesarios con marcados necesarios e non necesarios, para que poida ser imposible omitir datos importantes. Os exemplos deben establecer os estándares de denominación e estrutura de contido. Publica a idea / solicitude de fluxo de traballo para que todos poidan entender o que significa cada etapa. 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. A fase de adopción revelará decenas de casos especiais, e despois de algunhas iteracións, o equipo implementará o novo proceso. Fix communication outside the request É natural discutir temas en mensaxeiros, por correo electrónico ou en reunións, porque é rápido e prolífico. Con todo, a idea dunha estrutura para almacenar todos os datos nun só lugar, para poder acceder aos datos unha e outra vez, para aprendelo e analizalo, é importante. Every meeting or chain of messages has to be related to the request ticket ID, so later it will be possible to find the activity based on the unique identification number of the request. 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. Every request at every stage has to be assigned to a team member who will be responsible for fixating all significant artefacts. Yes, some negotiations still may be lost in private discussions, but the existence of a general facilitator for every request helps to route the data into storage. Solución de escenarios borderline Sempre hai escenarios onde un sistema centralizado de retroceso non funciona. Quizais sexa unha solicitude dun accionista moi ocupado, ou dos socios que non poden ter acceso ao sistema interno. E iso está ben. O equipo só ten que revelar todos estes escenarios e atopar un xeito de dirixilos aos estándar. 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. As solicitudes dos socios deben ser procesadas por xestores de contas ou soporte técnico, dependendo do papel dos socios. As usual in establishing new processes, it is important to document and declare all steps in public documentation to fix agreements and small details. Métodos de éxito A implementación do novo proceso require moito tempo e esforzo, polo que algunhas métricas poderían axudar a rastrexar a súa adopción. Introdución ao tempo Un dos principais obxectivos do marco IdeaOps é procesar ideas desde a súa creación ata unha decisión analizada.Esta métrica mostra o número de días desde a creación ata alcanzar un dos estados de decisión e axuda a revelar os seguintes obxectivos organizacionais: Speed of responses to customers or stakeholders across different teams. Número de respostas atrapadas cuxo tempo de procesamento exceda os límites establecidos. Mostra a relación entre a integridade e calidade dos datos proporcionados inicialmente e o tempo que leva procesar unha solicitude. Indirectly shows how the presence of related requests with previously provided estimates on similar ideas speeds up decision making. Time spent metric Understandable and correct requests should minimise the time a manager takes to process them. A “time-to-insight” metric is proposed to measure the overall processing time, which is related to the process itself. However, it's also important to measure the working time of the responsible manager who participated in this process. Of course, some ideas require weeks of investigation, while some are just about the colour of a button. But the average value per quarter or per year could still help to reveal improvements in time spent. If more and more requests have linked estimations and detailed decisions, it will affect the overall processing time per manager. Nivel de cobertura Shows the completeness of the request backlog. It’s necessary to raise the metric level with new and old requests to achieve an ideal base of proposals. O que hai que tratar Durante a adopción, hai que superar algúns problemas: Os membros do equipo deben saber que o uso de espazos persoais para anotacións é unha mala práctica, o que leva á perda de datos importantes da empresa. Se se creou algún artefacto de Proba de Concepto ou se estimou unha idea, todos os números relacionados co traballo rematado e as actividades futuras deben incluírse na solicitude. Unha decisión sen descrición non axuda no futuro.Unha idea rexeitada pode ser procesada e considerada de todos os lados, pero sen unha conclusión adecuada, é só unha perda de tempo.A próxima idea similar requirirá a mesma cantidade de tempo para procesar, porque os resultados anteriores non mostran a verdadeira razón para a rexeitamento, polo que a empresa perderá constantemente diñeiro, especialmente se a estrutura do equipo cambia co tempo. The adoption manager has to provide regular reviews of closed and stuck requests to improve the process. Conclusion The proposed IdeaOps framework is an idealistic way to process a large amount of different and sometimes incomprehensible data into a manageable structure. It requires well-coordinated teamwork where every member understands that every piece of data and decision is something bigger, that one day may help to reach new heights for the business and improve the overall company situation. Once properly processed, and even rejected, a insignificant proposal from one of the customers may be included in a general change in product strategy, because it contains a clear analysis of the situation, estimates and some clever conclusions as to why it wasn’t important as a standalone improvement, but looks completely different in a new market situation. And if this decision was properly documented and reused, that means that any tiny idea is a real asset of the company and deserves to be processed and stored for the best times. Traballar no catálogo de ideas é tan importante como traballar nos ingresos, e depende de cada empresa seguir o camiño para melloralo.
