¿Cuál es el costo de una idea? ¿Son valiosas, o no son nada antes de la implementación? La gestión del desarrollo de productos está construida sobre ideas y hipótesis. Un equipo de productos debe reaccionar rápidamente a cualquier demanda o fluctuación del mercado. Cualquier decisión debe tomarse para aumentar el valor del producto, los ingresos o la capitalización. Mientras tanto, el proceso de investigación debe hacerse con recursos mínimos. Las hipótesis en esta avalancha pueden estar conectadas con diferentes aspectos: Nuevas estrategias de marketing. Nuevas características . Adaptación a nuevos mercados o nichos. Investigación para crear un nuevo producto desde cero. Sin embargo, a pesar de la variedad de suposiciones, el análisis retrospectivo puede mostrar que todo el rebaño de ideas en un nicho de producto no es infinito. Las ideas pueden desarrollarse en notas personales o chats de la empresa sin un sistema, y después de la rotación de los miembros del equipo, el equipo proporcionará la misma investigación sin tener en cuenta la experiencia anterior. Estas ideas requieren un marco adecuado para almacenar, acumular y proporcionar información sobre el mercado, independientemente de los cambios en el crecimiento del equipo o de la empresa. Este sistema viable demuestra que las ideas cuestan mucho y pueden ayudar a los gerentes de productos a ahorrar tiempo y recursos de la empresa. IdeaOps para el desarrollo de productos El término “IdeaOps” como un marco de producto se introdujo por primera vez para mí en el programa “Rebellious Businesses” de Katherine R. Lieber en el episodio de podcast “Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations” (02.02.2025). Link: 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. En este artículo comparto mi experiencia personal de desarrollo de productos que complementa la idea del término original. El término “IdeaOps” como un marco de producto me fue introducido por primera vez en el programa “Rebellious Businesses” de Katherine R. Lieber en el episodio de 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 En este artículo comparto mi experiencia personal de desarrollo de productos que complementa la idea del término original. El núcleo del marco es la comprensión de que cada hipótesis es un activo de la empresa. Este activo debe tener un propietario, todo el contexto de la idea, artefactos que se crearon durante el proceso de investigación, enlaces a otros activos y el estado de la decisión.Las recomendaciones descritas a continuación revelarán la necesidad de un proceso en el que es muy importante no sólo fijarse en la adopción o rechazo de la hipótesis, sino mostrar todo el proceso de rastreo con la historia del pensamiento, el tiempo gastado y los resultados intermitentes. Como con cualquier otro marco, los aspectos principales se introducirán en el artículo: Cómo construir el proceso de reunificación de ideas. How to store the ideas. Cómo implementar el marco. Cómo medir el éxito y el valor de los cambios. How to build the process of idea gathering? El proceso sigue recomendaciones comunes y bien utilizadas para las próximas solicitudes de cambio. La creación . Context. a la izquierda. La evidencia . La estimación . La decisión . Creación Cada idea debe ser capturada dentro de la infraestructura de la empresa de acuerdo con las reglas: For every idea or request, a unique ticket should be created A veces una idea puede ser compleja y requiere una revisión del producto o el enfoque del mercado en sí. Es necesario enseñar al equipo cómo descomponer cada hipótesis en mejoras valiosas, pero separables. Esto puede crear alguna burocracia adicional y disminuir el número de ideas – si es difícil formalizar, algunos miembros del equipo pueden evitar la fijación de ideas. En cambio, ayuda a filtrar sugerencias crudas que son difíciles de comprender y estimar. Durante el proceso de establecer un marco, es necesario evaluar la compatibilidad del equipo para encontrar el equilibrio. En el ejemplo exagerado a continuación, proporciono un proceso de descomposición donde una idea como “Hagamos unos pocos millones de dólares adicionales” es grande en su núcleo, pero una sugerencia inútil para el proceso. sin embargo, es bueno crear un billete sobre un nuevo flujo de trabajo de pago porque hemos notado problemas con el viaje de los clientes. Ticket should be created in unified software and available for other team members Los gerentes de productos de diferentes equipos pueden mantener sus ideas bloqueadas en sus propios espacios locales o incluso en las aplicaciones de notas privadas.Es mejor que la ausencia de un bloqueo en absoluto, pero lleva a una miríada de formatos y la indisponibilidad para analizar la "gran imagen". Es mejor usar algún producto corporativo grande donde es más fácil vincular artefactos durante la investigación de ideas, como Microsoft Azure DevOps o Atlassian Jira (dependiendo de los procesos del equipo de desarrollo). El software unificado debe satisfacer los requisitos: Disponible para cualquier miembro del equipo por cuenta corporativa. También ayuda con la gestión de derechos y control durante la rotación del equipo. Para adaptar el marco a las necesidades de la empresa, es necesario tener la oportunidad de crear campos adicionales o estados personalizados. Supervisado por la empresa. Como se mencionó anteriormente, las ideas deben convertirse en los activos de la empresa. Esto significa el mantenimiento adecuado del almacenamiento principal. Ticket should be named properly Debido a que una idea/ticket es un activo de la empresa, el equipo tiene que aprender a clasificar y almacenar estos activos correctamente (y algunos consejos se proporcionarán a continuación). Durante la creación del billete, especialmente para los contribuyentes no técnicos, se puede omitir el nombre y se pueden crear billetes como "Mejorar el sitio web".El billete puede estar bien descrito en la parte de contexto, pero para los futuros registros es necesario proporcionar información adicional en el título. Ticket title should be unique and include the main suggestion. El billete no debe incluir frases de jargón o abreviaturas obscuras para ser comprensibles para diferentes equipos. El título del billete debe ser construido por estructura: Para hacer XXX en YYY para cambiar ZZZ; en otras palabras, contiene objeto, tema y resultado. Sin embargo, en la vida real, esta regla puede sonar utópica; es por eso que el flujo de trabajo del ticket debe incluir las correcciones de nombramiento durante la investigación. Ejemplo con la empresa ficticia "PaperGone": Mejorar el sitio web -> » ". Realizar el escenario de pago en el sitio web de 'PaperGone' para corregir la creación de cuenta obligatoria en el checkout Aquí nos centraremos en algunos aspectos desde el principio: Es necesario arreglar el sitio web "PaperGone" (porque podemos tener algunos sitios web y es bueno localizar el correcto desde el principio). The request is about improvement of the payment process. El título muestra el problema con la creación excesiva de cuenta durante el pago. Context El billete debe incluir una descripción de por qué el equipo de producto tiene que procesar la sugerencia. Dependiendo de los procesos de la empresa, los artefactos de contexto pueden ser necesarios o opcionales. List of possible context information: Descripción general: ¿de qué se trata? Puede contener información sobre cambios en el mercado, solicitudes de clientes u otros desencadenantes. Fuentes: copias de cartas de clientes, entrevistas, informes o noticias de fuentes públicas. Historias de usuarios (si procede): para revelar el público objetivo y los escenarios para mejorar. Cuanto más detallado sea el contexto, más probable es que el equipo de ideas proceda a una decisión positiva durante la investigación. Links Esa es una de las principales características del marco IdeaOps. Cada nueva hipótesis debe ser analizada basándose en la experiencia anterior. Antes del proceso de investigación, es necesario buscar entradas relativas o similares. 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. Tal vez el año pasado el equipo de ventas le preguntó la misma pregunta, pero tomamos una decisión de que la creación de cuenta durante el proceso de pago es obligatoria.O incluso tuvimos una solicitud completada “Añadir creación de cuenta para cada proceso de compra en el sitio web de “PaperGone”.Y es posible que no tengamos a ninguno de los miembros del equipo disponibles que sean responsables de la implementación, para preguntar por qué adoptamos tal decisión.O uno de los equipos intentó eliminar la creación de cuenta obligatoria y el equipo de producto notó la disminución de los datos de los usuarios para enviar correos electrónicos de marketing muy importantes y abortó los cambios. Estos enlaces no deben abortar la investigación para el billete, porque la situación del mercado puede haber cambiado; la sugerencia aún tiene que ser revisada. Por supuesto, es posible que el billete sea completamente único y no se refiere a nada antes.O el marco se estableció no hace mucho tiempo y no hay datos disponibles.En este caso, es necesario proporcionar anexos adecuados e información completa en las etapas posteriores del proceso del billete, para mejorar el trabajo en el futuro. Evidence Durante la fase de "evidencia", el equipo debe proporcionar una investigación basada en la información relacionada y las sugerencias actuales. Las ideas vinculadas y abortadas pueden parecer completamente diferentes con nuevas hipótesis y, juntos, traer una nueva imagen entera al foco. Esta etapa debe proporcionar artefactos como: Minutos de reuniones con discusiones sobre la implementación con las partes interesadas, clientes, clientes potenciales y desarrolladores. Market research. Interfaz de mock-ups Probación de Concepto (POC) o resultados de las pruebas A/B. Es importante establecer un proceso de evaluación y recopilar datos sobre el tiempo gastado trabajando en cada artefacto. Independientemente de la decisión sobre este billete en particular, tales datos pueden proporcionar información valiosa sobre los recursos que deben gastarse en investigaciones similares. 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. Tiempo y dinero ¿Cuántas horas de cada tipo de especialista debemos dedicar para implementar la sugerencia? The idea should go through an estimation process and the total has to be attached to the ticket. Riesgos ¿Cuáles son nuestros riesgos de implementar o omitir esta idea? Tal vez perderemos un cliente clave si decidimos no implementar esta característica. O tal vez estamos perdiendo dinero todos los días con un escenario de pago que no funciona en nuestro sitio web. Algunas ideas también pueden retroceder - el equipo podría implementar una nueva característica y recibir un ingreso adicional, pero tendrá problemas de rendimiento y estabilidad. Esta información también puede ser útil en el futuro durante la discusión de por qué una gran idea no se implementó en el producto. Prioridad ¿Cuán importante es esta idea para el producto o el negocio en absoluto?Este parámetro de estimación es un parámetro complicado y depende de la corrección de la estrategia del producto. Sin embargo, una etapa de “evidencia” bien provista puede ayudar a calcular la prioridad basada en reglas establecidas y datos investigados. Hay muchos enfoques para priorizar, pero lo más sencillo es mejor, por lo que el buen viejo RFC 2119 funciona bien. Las referencias: Clegg, D. (1994). Método de caso Fast-Track: Un enfoque RAD. Bradner, S. en el año 1997. (RFC 2119). Task Force de Ingeniería de Internet. Disponible en: . Palabras clave para usar en RFCs para indicar niveles de requisitos https://www.rfc-editor.org/rfc/rfc2119 References: Clegg, D. (1994). En Addison-Wesley Método de caso Fast-Track: un enfoque RAD Bradner, S. en el año 1997. (RFC 2119). Task Force de Ingeniería de Internet. Disponible en: . Palabras clave para usar en RFCs para indicar niveles de requisitos https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 Decision La fase de resultados, basada en los análisis y artefactos anteriores, es la etapa más importante para IdeaOps. Según el marco, el comentario de resultados proporciona una visión general para el futuro. There are a few options for how each request may end: Haremos esto – es necesario escribir por qué suena como una idea rentable y qué nos ayuda a tomar la decisión correcta.También, este comentario puede ser útil para análisis posterior si el resultado vale lo que se esperaba. It’s definitely not worth it – okay, but why? Maybe some data were collected incorrectly, or the result value is low. Nevertheless, the product manager has to write a detailed opinion about the rejection. In some future requests, it may be revealed that this particular request was redundant, but if we rethink it in the big picture, the concerns of product managers may be solved. 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? Es bueno si lo combinamos con otra solicitud – construyamos un plan para revisarlo con una solicitud adicional y la forma de este proceso. Por supuesto, hay más escenarios, pero en este artículo quiero mostrar un ejemplo de pensamiento: Cada solicitud debe ser procesada a través de todo el canal y debe tener un resultado adecuado para mostrar a otros miembros actuales o futuros del equipo la forma de adoptar la decisión. Cada solicitud debe ser procesada a través de todo el canal y debe tener un resultado adecuado para mostrar a otros miembros actuales o futuros del equipo la forma de adoptar la decisión. Las personas pueden cometer errores o adoptar la decisión equivocada según la situación y su conocimiento.Este proceso les obliga a documentar esta decisión y ayuda a la empresa a revisar y aprender sobre la base de estas solicitudes más adelante. Cómo almacenar ideas We have covered the basic steps of the framework, but for proper use of a general request backlog it’s necessary to build a storage system that helps any team member to find any active or archived idea in minimal time. The best way to achieve this is to slice data via a set of filters and parameters. It is highly important to store all ideas in a unified space, accessible for different teams. Technically, it’s possible to use any spreadsheet software as storage for requests/ideas and filter them using attributes in columns, but it is easier and more manageable to use a large product for teamwork such as Atlassian Jira or Microsoft Azure DevOps. These products can help to organise workflows, proper stage management and role-based access control. Every request may have different dimensions: El producto. Business domain. Business risk. Funcionalidad del producto. Solicitud de etapa. La fuente. Cuantos más filtros estén disponibles para el backlog de ideas, más miembros del equipo con una variedad de experiencias y maneras de pensar pueden navegar por él. La lista de dimensiones no es completa y proporciona sólo un ejemplo de formas de descomposición. Recomiendo organizar unas pocas sesiones de brainstorm para revelar todos los filtros adecuados para el backlog y refrescarlos de vez en cuando. Además, es necesario establecer reglas para añadir las opciones de filtros y asignar un rol de administrador. Cada opción debe consistir en una lista cerrada de elementos; de lo contrario, toda la estructura se desintegrará. Let’s skim through examples of dimensions. Every aspect may be disclosed as a group of filters; the complexity depends on a product and company's structure. Producto Las empresas pueden desarrollar pocos productos o generaciones de productos, por lo que cualquier ticket debe estar conectado al producto, o plataforma de generación de producto. Este bloque puede consistir en nombres de productos: Sitio web, Producto 1 para SaaS, Producto 2 para On-Prem, etc. O ayudar a localizar la plataforma: Frontend, Backend, iOS/iPadOS, Android. In an earlier example, we mentioned a fictional request, " En la empresa PaperGone, así que le daré los parámetros teóricamente posibles para la entrada correcta de esta solicitud. Realizar el escenario de pago en el sitio web de 'PaperGone' para corregir la creación de cuenta obligatoria en el 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. Riesgos de negocio Cada solicitud puede cubrir un riesgo de empresa diferente. Algunas de ellas pueden revelar defectos arquitectónicos en la infraestructura del producto, o algo relacionado con las ventas y los competidores. El autor de la solicitud debe darse cuenta de cuál es la opción más adecuada. Esta dimensión se refiere a posibles problemas en algo: ventas (no se puede vender sin ella), venta superior (no puede crecer cuentas actuales sin ella), seguridad (preocupación por el potencial de explotación), competidores (algo que no tenemos), legal (nuestros formularios de acuerdo no son tan buenos). Funcionalidad del producto Para crecer productos complejos, es necesario saber lo que está gestionando.Los productos de una empresa consisten en docenas de características, y las nuevas solicitudes pueden ser mejoras a algunas de ellas o relacionadas con algo existente. La forma de lograr esta descomposición se describe en el artículo - "https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition". La forma de lograr esta descomposición se describe en el artículo - "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. Ejemplo de la estructura de la etapa: New - nobody has processed the request. Para estimar - la solicitud pasa a través de las 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. Comprometido - la etapa de desarrollo, que requiere está en el proceso de realización. Cerrado - la etapa final para indicar la finalización de la solicitud. 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 The ideas may be created by different actors, and the processing time may vary depending on the source. For example: Stakeholders, Customers, Sales, Customer Support Engineers, Developers. Este sistema de parámetros ayuda a encontrar cualquier solicitud nueva o pasada con un tiempo mínimo; sin embargo, al mismo tiempo, puede ser un obstáculo para los miembros del equipo porque complica la forma en que se comparten las ideas.La complejidad del sistema debe reflejar la estructura de la empresa, por lo que mi recomendación es comenzar con los parámetros más fáciles y profundizar más según las respuestas del equipo. How to implement the framework Como con cualquier teoría, la parte más complicada es integrar el marco de IdeaOps en los procesos cotidianos de una empresa. Obviamente, los procesos deben ser adaptados, revisados o solo parcialmente utilizados según la estructura de la empresa, pero la idea general es ayudar a proporcionar un mejor procesamiento de billetes que antes, e incluso parte del marco lo hará bien. However, in any company, there’s a closed list of obstacles that have to be dealt with. Nadie sabe cómo y por qué crear boletos de la “manera correcta”. Hay muchas discusiones en reuniones o a través de mensajeros que no se reflejan en el elemento de trabajo de la idea. Some sources cannot provide structured data via a centralised backlog system. Vamos a cubrirlos paso a paso. Enseñar a los miembros del equipo cómo trabajar con un backlog general Create a template request ticket and provide an example. Templates could be described in company documentation or even developed in the software (Atlassian Jira or Microsoft Azure DevOps are perfectly fine with them). Los nuevos elementos de trabajo de solicitud deben consistir en los campos y parámetros necesarios con marcas necesarias y no necesarias, por lo que puede ser imposible omitir datos importantes. Los ejemplos deben establecer los estándares de denominación y estructura de contenido. Publicar el flujo de trabajo de la idea / solicitud, para que todos puedan entender lo que significa cada etapa. Transmite un mensaje de que este modelo es la única manera de enviar la solicitud. Opcionalmente, si la estructura del equipo no es complicada, puede justificarse a través de una reunión. 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 etapa de adopción revelará docenas de casos especiales, y después de unas pocas iteraciones, el equipo implementará el nuevo proceso. Fijar la comunicación fuera de la solicitud 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: Cada reunión o cadena de mensajes debe estar relacionada con el ID de billete de solicitud, por lo que más tarde será posible encontrar la actividad basada en el número de identificación único de la solicitud. Para cada reunión sobre la solicitud, se deben crear minutos de reunión.En la era de los asistentes de IA, no es tan complicado y ayuda mucho en el análisis adicional. 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 Siempre hay escenarios en los que un sistema centralizado de retroalimentación no funciona. Tal vez sea una solicitud de un accionista muy ocupado, o de los socios que no pueden tener acceso al sistema interno.Y eso está bien.El equipo sólo tiene que revelar todos estos escenarios y encontrar una manera de redirigirlos a los 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. Partners' requests should be processed by account managers or technical support, depending on the role of the partners. The team should choose the nearest starting point to begin the process. Como es habitual en el establecimiento de nuevos procesos, es importante documentar y declarar todos los pasos en la documentación pública para fijar acuerdos y pequeños detalles. Success metrics Implementation of the new process requires a lot of time and effort, so a few metrics could help to track its adoption. Tiempo de Insight Uno de los principales objetivos del marco IdeaOps es procesar ideas desde su inicio hasta una decisión analizada.Esta métrica muestra el número de días desde la creación hasta alcanzar uno de los estados de decisión y ayuda a revelar los siguientes objetivos organizativos: Speed of responses to customers or stakeholders across different teams. Número de respuestas atrapadas cuyo tiempo de procesamiento excede los límites establecidos. Shows the relationship between the completeness and quality of the initially provided data and the time it takes to process a request. That’s a great metric to justify additional fields or filters for the request. Indirectamente muestra cómo la presencia de solicitudes relacionadas con estimaciones previamente proporcionadas sobre ideas similares acelera la toma de decisiones. El tiempo gastado metálico 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. Coverage Level Es necesario elevar el nivel métrico con solicitudes nuevas y antiguas para lograr una base ideal de propuestas. Lo que hay que tratar con Durante la adopción, hay que superar algunos problemas: Los miembros del equipo deben saber que el uso de espacios personales para las notas es una mala práctica, lo que lleva a la pérdida de datos importantes de la empresa. Si se creó un artefacto Proof of Concept o se estimó una idea, todos los números relacionados con el trabajo completado y las actividades futuras deben incluirse en la solicitud. Una decisión sin una descripción no ayuda en el futuro.Una idea rechazada puede ser procesada y considerada desde todos los lados, pero sin una conclusión adecuada, es sólo una pérdida de tiempo.La próxima idea similar requerirá la misma cantidad de tiempo para el procesamiento, porque los resultados anteriores no muestran la verdadera razón para la rechazo, por lo que la empresa perderá constantemente dinero, especialmente si la estructura del equipo cambia con el tiempo. El gerente de adopción debe proporcionar revisiones regulares de solicitudes cerradas y atrapadas para mejorar el proceso. Conclusión El marco IdeaOps propuesto es una forma idealista de procesar una gran cantidad de datos diferentes y a veces incomprensibles en una estructura gestionable. Requiere un trabajo de equipo bien coordinado donde cada miembro entiende que cada pieza de datos y decisión es algo más grande, que un día puede ayudar a alcanzar nuevas alturas para el negocio y mejorar la situación general de la empresa. Una vez procesado correctamente, e incluso rechazado, una propuesta insignificante de uno de los clientes puede ser incluida en un cambio general en la estrategia del producto, porque contiene un análisis claro de la situación, estimaciones y algunas conclusiones inteligentes sobre por qué no era importante como una mejora independiente, pero parece completamente diferente en una nueva situación de mercado. Trabajar en el catálogo de ideas es tan importante como trabajar en los ingresos, y depende de cada empresa seguir el camino para mejorarlo.
