Acerca de esta publicación
¿Cómo se pasa de una organización alineada con componentes y tecnología a una organización centrada en el producto? Muchas organizaciones encuentran que esto es un desafío, ya que aspiran a ir más allá de lo ágil. Para tener éxito, toda la organización debe alinear sus equipos para el descubrimiento y la entrega centrados en el producto.
1. INTRODUCCION
Una empresa de servicios financieros grande, mundial ( vamos a llamarlo FinTechBizz), empleó tres años en su viaje para adoptar formas ágiles de trabajo. Para acelerar las mejoras en la experiencia del cliente que ya se habían logrado, la división de infraestructura tecnológica decidió alinear su estructura y entrega para centrarse en el producto. La atención se centró principalmente en los productos utilizados internamente por sus empleados.
Toni Santos, coach interno del equipo de estrategia y transformación, trajo a Elena García para llenar los vacíos en el conocimiento y la experiencia de gestión de productos del equipo. Con la experiencia en coaching de productos de Elena, tanto Toni como Elena tocaron casi todas las partes de la organización. Cambió la forma en que la empresa veía lo que era valioso para sus clientes (empleados) y cómo organizarse para ofrecer este valor.
En el camino, se descubrieron los siguientes impedimentos, amplificados por la escala de la organización, que incluyen:
- Cómo el cambio de centrado en la tecnología a centrado en el producto es contrario a la intuición para muchos tecnólogos
- Cómo pasar a estar centrado en el producto desafía el modelo mental de las personas de lo que es un producto
- Qué tan difícil es cambiar las métricas de las actividades y las fechas de vencimiento a los resultados del cliente
- Cómo las estructuras organizacionales pueden volverse complejas y desafiantes a medida que los líderes aprenden las implicaciones del pensamiento del producto para los roles existentes.
Este informe de experiencia se centra en el primer año (la transformación aún está en curso) y los esfuerzos iniciales en torno a la definición de productos, estructura organizativa y formas de trabajo.
2. Antecedentes
En 2017, el ejecutivo de una organización de infraestructura de 8.000 personas en una gran institución financiera decidió acelerar y amplificar su actual transformación ágil. Buscaban mejorar el valor del cliente y acelerar la entrega. Basándose en una recomendación de una consultora, la organización consideró necesaria la centralización del producto. Esta recomendación se validó después de visitas de campo a empresas de gran prestigio centradas en productos (por ejemplo: Facebook, Apple, Netflix y Google).
El equipo de transformación comenzó definiendo los productos de las organizaciones de infraestructura y entendiendo cómo su extensa lista de servicios, aplicaciones, plataformas y componentes existentes respaldaban esos productos.
La transición a una organización centrada en el producto se complicó aún más debido a lo siguiente:
- Escala: la cantidad de personas (8.000) potencialmente afectadas fue bastante grande.
- Tipo de producto: los productos son una infraestructura que, a su vez, respalda los productos orientados al cliente de FinTechBizz.
- Cultura: la organización era jerárquica y estaba enfocada en proyectos (no en productos) con estructuras de informes reducidas y profundas.
- WIP: había una gran cantidad de trabajo en progreso dentro de la organización, incluida una serie de iniciativas de cambio que impulsaban la reestructuración de la organización.
3. Nuestra historia
3.1 Modelo mental compartido de producto
¿Qué es un producto? Esta pregunta fue la pregunta más frecuente a lo largo del viaje para convertirse en una organización centrada en el producto. Las terminologías como propietario de producto, cartera de productos, producto mínimo viable (MVP), equipo de producto y producto se utilizan a menudo en marcos ágiles. Cuando le preguntas al personal de su organización: “¿Qué es un producto?” y obtendrás muchas respuestas diferentes. Esta diferencia radica en diferentes modelos mentales:
“Los modelos mentales son marcos conceptuales que consisten en generalizaciones y suposiciones a partir de las cuales entendemos el mundo y actuamos en él”. — Peter Senge
Para convertirse en una organización centrada en productos, FinTechBizz necesitaba desarrollar un modelo mental compartido sobre productos que todos entendieran. Debía ser fundamental para la forma en que FinTechBizz organizaba, descubría y entregaba soluciones a las necesidades de los clientes. Este fue el desafío más importante que Elena y Toni tuvieron que afrontar desde el principio.
3.2 Definición de productos más amplios
La mejora del valor para el cliente y la entrega acelerada se identificaron como los dos objetivos principales de FinTechBizz. Para lograr estos objetivos, Elena animó a FinTechBizz a pensar en definir sus productos de una manera que optimizara su capacidad para lograr estos objetivos. Elena sugirió que una definición de producto más amplia ayudaría con esta optimización. Los productos más amplios generan muchos beneficios, que incluyen pocos trabajos pendientes y roles de productos, una priorización más centrada en el cliente, dependencias reducidas, menos duplicación de funciones y estructuras organizativas que alinean a los equipos de desarrollo con el valor del cliente de un extremo a otro.
Elena compartió esta definición para la discusión: “Un producto es algo que brinda valor a los clientes y socios comerciales. Un producto es un conjunto integrado de elementos técnicos y no técnicos. Puede ser en forma de aplicación de software, sistema, dispositivo, servicio y proceso, o una combinación. Un producto puede ser en sí mismo un servicio o incluir servicios“.
Después de examinar los productos existentes en FinTechBizz, muchos productos ya estaban alineados con esta definición. Sin embargo, cuando se revisaron en el contexto de los objetivos de optimización, las definiciones de productos no fueron óptimas. En cambio, se necesitarían varios productos ensamblados para ofrecer valor al cliente. Había muchas dependencias entre los productos, lo que se sumaba al tiempo de entrega. Con la competencia interna entre los equipos de productos, hubo una excesiva duplicación de esfuerzos. Cada producto se optimizó localmente, no globalmente, para ofrecer valor y acelerar la entrega.
3.3 Pensar de adentro hacia afuera: centrado en la tecnología
Era típico que muchos líderes de FinTechBizz tomaran decisiones clave sobre productos desde una perspectiva tecnológica. Cuando se les pregunta, la mayoría se refiere a una aplicación (por ejemplo, un producto de un proveedor como Skype, Oracle u Office) o componente (un elemento de hardware como un servidor de rango medio o un panel de visualización) como el producto. Esto no es ninguna sorpresa dado que el sistema de registro estaba centrado en las aplicaciones y en los componentes. (El sistema de registro consta de documentos, herramientas y mecanismos que se utilizan para monitorear y administrar la organización). Para FinTechBizz, el sistema de registro era un catálogo maestro de más de 600 aplicaciones y componentes que comprenden la infraestructura de toda la empresa para todos los servicios externos e internos. clientes.
Dentro de una gran organización como FinTechBizz, el sistema de registro (System of Registry) juega un papel dominante en la definición de lo que importa. El sistema de registro guía cómo se asignan y aprueban los fondos, qué se informa y se cuestiona, y cómo la organización valora el título y los roles. Cuando comenzamos este viaje, la organización de infraestructura de FinTechBizz consideró cada elemento del catálogo como un producto único.
Para reforzar el pensamiento centrado en las aplicaciones, el sistema de registro impuso restricciones a los equipos de productos. Por ejemplo, las herramientas para realizar un seguimiento del trabajo se asociaron con aplicaciones. Como resultado, esto significaba que la mayoría de los trabajos pendientes se referían a componentes, más que a productos pendientes.
En última instancia, el sistema de registro fue considerado como el “árbitro tácito de la verdad”. El pensamiento de adentro hacia afuera contribuyó a la definición subóptima de los productos. De hecho, había numerosos denominados “productos” (o variaciones de productos) similares en la línea de productos. Muchos de ellos tenían poca o ninguna interoperabilidad. Lo más importante es que un solo producto no proporcionó valor al cliente de extremo a extremo, lo que le restó valor a una experiencia satisfactoria para el cliente.
3,4 pensamiento fuera-in-convertirse en producto centrada
Elena y Toni creían que para que FinTechBizz logre su objetivo de estar más orientado al cliente, se requería un enfoque en el cliente. Como el pensamiento actual era de adentro hacia afuera (“inside-out thinking” o de la tecnología al cliente), era imperativo un enfoque más de afuera hacia adentro (“outside-in approach” o del cliente a la tecnología).
Los clientes de infraestructura de FinTechBizz se pueden clasificar en dos grupos:
- B2C (empresa a consumidor): los empleados de FinTechBizz necesitaban productos y servicios para ser productivos en el lugar de trabajo. “Employee Collaboration” fue un buen ejemplo de un producto B2C ampliamente definido . Considere la colaboración de empleados como un ejemplo de un producto B2C ampliamente definido en FinTechBizz. Aplicaciones como Zoom, Skype y Teams proporcionaron los componentes básicos que permitieron la colaboración.
- B2B (empresa a empresa): la organización de la infraestructura proporcionó productos y servicios de infraestructura compartida para permitir productos orientados al consumidor, como hipotecas. A diferencia de los productos B2C, los clientes de la organización de infraestructura no eran el consumidor final. En cambio, los desarrolladores de aplicaciones y los administradores de bases de datos de las áreas comerciales de FinTechBizz participaron directamente en una compleja cadena de valor B2B.
Nuestra intención era ayudar a FinTechBizz a dar un paso atrás para explorar la necesidad subyacente del cliente.
Por ejemplo, al considerar al administrador de la base de datos de FinTechBizz como el cliente, era importante que la tecnología de base de datos adecuada se adaptara a sus necesidades. Nuestro mensaje fue coherente y sencillo. Había que identificar las necesidades del cliente en lugar de ofrecer soluciones tecnológicas para encontrar clientes.
3.5 Cambio del modelo mental a través de definiciones de productos
Para generar estos avances y cambiar al pensamiento de afuera hacia adentro, facilitamos talleres de definición de productos colaborativos de varios días. Estos talleres alentaron a los líderes a descubrir colectivamente la respuesta a la pregunta “¿Cuáles son nuestros productos?” Era esencial hacer esto en colaboración con representantes de todo el flujo de valor para obtener un modelo mental compartido.
Los participantes del taller se prepararon revisando un glosario de términos y los criterios para definir un producto. En el taller, el equipo de liderazgo participó en ejercicios divertidos y provocativos para probar su comprensión con un cuestionario interactivo utilizando Kahoot, una plataforma de aprendizaje en línea basada en juegos. Esta actividad de taller generó conciencia de que era una forma más óptima de definir productos. Destacaron tres actividades:
- Lienzo del Producto (Product Canvas) – dos páginas de lienzo que explora diferentes aspectos de un producto, como la visión, los socios de producto, el valor, los factores de costo, y las siete dimensiones del producto. El lienzo del producto se convirtió en una herramienta para cambiar la perspectiva de todos al pensamiento de afuera hacia adentro [ Gottesdiener ].
- Lista de verificación del producto: una lista de verificación de los criterios para una definición de producto saludable que incluye lo siguiente:
- Un producto se describe desde la perspectiva del cliente
- Un producto es de larga duración y evoluciona a medida que cambian las necesidades y las tecnologías
- Un producto abarca todo el recorrido del cliente
- Es / No es: un sencillo y divertido ejercicio de clasificación de cartas. Les pedimos a todos que escribieran lo que creían que era el producto. En varias rondas, los participantes usarían la lista de verificación de productos para determinar cuáles eran productos. (Este ejercicio eliminó aquellos que se determinó que no eran un producto).
3.6 Definición de un producto más amplio
Una vez que los líderes examinaron cuidadosamente las necesidades de los clientes, comenzaron a comprender cuán interconectado estaba todo. Quedó claro que los productos integrales brindan una mejor experiencia al cliente. Al mismo tiempo, optimizar las soluciones para los clientes desafiaría la estructura de la organización existente.
Un líder determinó que el lugar de trabajo era el producto. Al definir un producto más amplio, los activos físicos (escritorios) y los bienes raíces (salas de reuniones) eran componentes clave del producto del lugar de trabajo. Exploró cómo integrar tecnología y componentes físicos para brindar una excelente experiencia en el lugar de trabajo. Debido a que la tecnología y los bienes raíces eran departamentos separados, debían estar más alineados como parte de un solo producto.
Una perspectiva más amplia, de afuera hacia adentro, requiere pensar fuera de las capacidades tecnológicas. Cuando un producto tiene una definición amplia, la estructura sigue al producto, no al revés. Por ejemplo, cuando Elena entrenó al equipo de liderazgo de la base de datos, determinaron que los servicios de asesoría de bases de datos serían valiosos para sus clientes internos.
FinTechBizz aprendió que sus definiciones de productos evolucionarían con el tiempo a medida que se comprendieran los beneficios de productos más amplios. La siguiente figura (ver Figura 1) ilustra el viaje:
3.7 Conseguir que la definición del producto se mantenga
Cambiar los modelos mentales de una sola persona puede ser todo un desafío, especialmente para una organización de 8.000 personas. Para los tecnólogos que tradicionalmente piensan de adentro hacia afuera, definir los productos de manera más amplia desde el punto de vista del cliente puede parecer contradictorio.
Avanzamos mejor con departamentos de entre 100 y 200 personas. El tamaño de una organización también influye. Trabajar con organizaciones más pequeñas nos permitió profundizar al crear tiempo, espacio y seguridad para explorar varios modelos mentales.
4. La importancia de los roles
4.1 Alineación de la estructura organizativa con las definiciones de productos
FinTechBizz quería una estructura organizativa sencilla alineada con sus productos. Un Product Owner se asignaría a un producto y a un solo producto atrasado. Los equipos de funciones estarían alineados con esta acumulación y trabajarían en estrecha colaboración con el propietario del producto para ofrecer valor al cliente.
Resultó ser todo un desafío pasar a esta estructura organizativa simplificada, ya que había mucha confusión sobre las funciones de los productos. Toni dedicó varios días a educar a los ejecutivos para que comprendieran mejor la importancia de tener una buena estructura organizativa de gestión de productos. Toni y Elena aclararon los conceptos erróneos comunes sobre el rol del propietario del producto en ágil. La Guía Scrum no dice nada sobre la importancia de una buena gestión del producto y el papel de la propiedad del producto [ Schwaber y Sutherland].
Para superar esto, Elena utilizó un ejercicio llamado “Gestión ágil de productos: haga lo correcto, no todo” [Gottesdiener-2]. Este ejercicio destacó las actividades y decisiones que son importantes en la gestión del producto, el papel de la propiedad del producto y el trabajo de desarrollo del producto. En FinTechBizz, quedó claro que la gestión de productos era una mezcla de trabajo estratégico y táctico. Los líderes ya estaban familiarizados con los aspectos tácticos (gestión de la Pila del Producto o Product Backlog) en Scrum. A través del coaching, se hizo evidente una nueva apreciación de los aspectos estratégicos (finanzas, investigación de mercado y análisis de la competencia). Por ejemplo, la competencia interna condujo a la duplicación de productos cuando los Product Owners realizaron un análisis competitivo de su producto.
4.2 Propiedad del producto
A medida que los líderes comenzaron a comprender que un Product Owner tenía responsabilidades de gestión de productos, se percibió que el rol era similar al de un CEO. Esta nueva perspectiva amplificó la importancia del papel. Para muchas organizaciones, el propietario del producto era un rol secundario con poca o ninguna capacidad para tomar decisiones más allá de los detalles de la historia del usuario.
Sin embargo, el deseo de una estructura organizativa simple llevó a los líderes (y Talent, Personas o RR.HH.) a cambiar su pensamiento en la dirección opuesta. Sobrecargaron el rol de Product Owner con responsabilidad, estrategia, finanzas, desarrollo de productos y diseño técnico. En algunas partes de la organización, se agregaron funciones de gestión de personas. Con varios cientos de empleados a su cargo, el enfoque en la gestión de productos se diluyó.
Para aliviar la presión y los malentendidos sobre el rol de Product Owner, enfatizamos la necesidad de una separación saludable entre la gestión de productos y el desarrollo de productos. Los Product Owners no deberían tener equipos de ingeniería que les reporten.
El liderazgo intentó aliviar a los Dueños de Producto (Product Owners) sobrecargados agregando un rol de Analista de Negocios (Business Analyst o Proxy Product Owner). Estos “gerentes de producto” crearían historias y representarían al propietario del producto en ceremonias ágiles. El Product Owner subdividiría la acumulación del producto entre varios Product Managers. Desafortunadamente, este esfuerzo de coordinación aumentó y agregó más estrés al propietario del producto.
Para liberar a los Product Owners, el liderazgo propuso eliminar la responsabilidad de la gestión de personas y hacer que los desarrolladores realicen análisis de requisitos de productos con los clientes. Como puede imaginar, los desarrolladores solo querían codificar. Más importante aún, la confusión de roles puso de relieve el malentendido sistémico de la gestión de productos.
4.3 Propietarios de productos que son técnicos
Muchos de los propietarios de productos de FinTechBizz fueron anteriormente gerentes de tecnología (Technology Managers). En lugar de aprender más sobre el cliente, los Product Owners no pudieron evitar sumergirse en los detalles técnicos de una solución. Era común que los propietarios de productos minimizaran su falta de habilidades de gestión de productos. Encontrar el equilibrio adecuado siguió siendo un desafío.
Un Product Owner no debe asumir que los desarrolladores y los clientes técnicos tienen las mismas necesidades y expectativas. En cambio, Elena enfatizó la importancia de explorar las necesidades del cliente con ojos frescos y una mente abierta.
La trampa técnica también encerró a los Product Owners en la especialización de dominios. Un Product Owner que trabaja en un producto de base de datos rara vez trabajaría en un producto fuera de ese dominio. Esta especialización a menudo conducía a puntos ciegos. Como resultado, los Product Owners lucharon para liderar sesiones de descubrimiento de clientes, realizar investigaciones de usuarios o desarrollar planes de marketing. Elena capacitó a los Product Owners en estas nuevas habilidades y varios cambiaron radicalmente su forma de trabajar. A otros, sin embargo, les resultó más difícil adoptar estas nuevas habilidades. Toni observó que a menudo eran los Product Owners más técnicos los que tenían más dificultades para desarrollar habilidades de gestión de productos.
4.4 Definición de producto limitada = cantidad pesonas de producto grande
El sesgo de alta tecnología fue una fuerza fuerte en FinTechBizz. Después de definir inicialmente productos más amplios, los productos de infraestructura se definieron de manera más reducida, ampliando la cantidad de productos. A medida que aumentaba el número de productos, también lo hacía el número de propietarios de productos. Cada producto tenía su propio Product Owner
A medida que aumentó el número de Product Owners, la estructura organizativa se volvió muy compleja. En consecuencia, los propietarios de productos eran responsables de una parte del rompecabezas y no podían tomar decisiones de productos independientes. Los clientes y las partes interesadas a menudo se confundían con el propietario del producto con el que deberían interactuar.
La solución sistémica habría sido abordar la definición limitada de producto. En su lugar, se creó una nueva función de “Propietario de la cartera de productos“. Esta función consistía en gestionar una cartera de productos definidos de forma restringida y ayudar a gestionar las dependencias entre ellos. Desafortunadamente, esta complejidad agregó y no abordó la causa raíz en absoluto.
Esta profunda jerarquía de propietarios de productos, propietarios de carteras de productos y gerentes de productos resultó en atrasos desconectados y mala gestión organizacional.
5. Qué aprendimos
5.1 La mayoría de los tecnólogos definirán el producto de manera subóptima
FinTechBizz tenía dos objetivos distintos: 1) reducir el tiempo de entrega y 2) aumentar el valor para el cliente. Para alinearse con los objetivos de la organización, los productos debían definirse de manera óptima. Encontramos todo lo contrario. Había dos “trampas de pensamiento” que conducían a una definición de producto subóptima: el reduccionismo y el sesgo tecnológico.
Existía una tendencia natural a descomponer el producto en productos definidos de forma estricta. Existía la percepción de que las partes más pequeñas hacían que la organización fuera más manejable y eficiente. En cambio, esto condujo a productos subóptimos que resultaron en tiempos de entrega más largos y menor valor para el cliente. Eso iba en contra de los objetivos de FinTechBizz. El reduccionismo conduce a la optimización local a expensas de la optimización global.
Los tecnólogos naturalmente se lanzaron a soluciones que a menudo estaban relacionadas con la tecnología. Como dijo Maslow, “si todo lo que tienes es un martillo, todo parece un clavo“. En FinTechBizz, todos los productos se definieron en términos de tecnología. Pocos líderes definirían (o describirían) productos a los ojos del cliente.
Nos pareció un desafío continuo ayudar a los líderes a definir productos más amplios. Hubo varias prácticas clave que ayudaron a influir en el éxito. Para comprender los desafíos diarios de los clientes, los Product Owners dedicaron un tiempo considerable a interactuar con los clientes. Fue beneficioso involucrar al cliente en la definición de sus problemas y ayudar en el diseño de soluciones efectivas. Cuanto más aumentara el conocimiento del producto un Product Owner, menos se lanzaría a ciegas a una solución tecnológica. Finalmente, los líderes con alta seguridad psicológica y confianza en sí mismos pudieron mirar más allá de los límites organizacionales.
5.2 Utilice el pensamiento sistémico para influir en sus productos y organización
FinTechBizz comenzó con la intención de una estructura organizativa simple. Sin embargo, escalar rápidamente se convirtió en un desafío. Se definieron más productos a medida que las definiciones se volvían más limitadas y más fáciles de administrar desde una perspectiva tecnológica. A medida que se agregaron más roles para manejar la complejidad, todo lo que hizo fue agravar el problema. En retrospectiva, podríamos haber dedicado más tiempo a educar a los altos directivos sobre estas dinámicas organizativas.
Una técnica que comenzó a ayudar a los líderes a ver el impacto de sus decisiones fue el pensamiento sistémico. El uso de “diagramas de bucle causal” (Causal Loop Diagramming) fue una técnica que Toni descubrió que condujo a grandes avances. Cuando los líderes utilizaron esta técnica para visualizar el sistema, pudieron ver el impacto de sus decisiones en contra de sus objetivos. Toni ayudó a los líderes a adquirir conocimientos de esta técnica a través de un entrenamiento Scrum a gran escala que incorpora diagramas de bucle causal como herramienta de aprendizaje. Los líderes fueron testigos de los beneficios después de participar en estos talleres que incluyeron una organización más plana, menos atrasos, aparición del rol del producto y alineación de la organización con el producto. El modelado de sistemas ofreció importantes beneficios para ayudar a los líderes a comprender su organización como un sistema, cómo las variables impactaban el comportamiento y cómo, sin saberlo, causaban el efecto opuesto de su intención declarada.
Para preparar este informe, creamos un diagrama de bucle causal para resaltar en retrospectiva la dinámica que influyó en la transformación (ver Figura 2).
Es probable que estas dinámicas estén presentes en muchos otros sistemas organizativos. Antes de lanzarse a rediseñar la organización, eduque a los líderes sobre cómo ver su sistema organizacional. Este enfoque evita soluciones rápidas y efectos secundarios no deseados.
5.3 Profundo, no ancho y poco profundo
En lugar de trabajar con una cartera de productos completa, habría sido una mejor estrategia haber definido un pequeño conjunto de productos de infraestructura amplia. Luego, profundice en solo uno de esos productos para hacer lo siguiente:
- Rehacer el sistema de registro para ese producto
- Alinear los equipos con las áreas de características del producto
- Establecer métricas basadas en los resultados del cliente
- Abordar las definiciones de roles
- Involucrar a los líderes financieros y de recursos humanos
- Capacitar y preparar al personal de productos
5.4 Modelar una buena gestión de productos
Antes de escribir este informe, realizamos una retrospectiva de nuestro trabajo de transformación. Producimos una línea de tiempo de eventos con un sismógrafo emocional y extraemos la línea de tiempo de los temas. Luego creamos un conjunto de protopersonas para los roles en la organización, un análisis de campo de fuerza y múltiples versiones de diagramas de bucle causal. Esto nos ayudó a identificar lo que sucedió durante la transición para convertirnos realmente en productos centrados en el producto. Reconocimos que nuestro trabajo se basaba en el uso de métricas de actividad frente a las de los clientes y no profundizamos lo suficiente en el descubrimiento de clientes. Nos recordábamos continuamente lo lento y doloroso que es el cambio, especialmente para organizaciones grandes como FinTechBizz.
Reconocimos que siempre es mejor modelar el comportamiento que se busca. Para llevar a cabo una transformación orientada al producto, siempre debe actuar como un buen gerente de producto. Tenga en cuenta que la organización es el producto y comience siempre por el cliente.
Hicimos un progreso importante cambiando los modelos mentales. Podríamos haber dedicado menos esfuerzo a actividades como la educación y la formación. Y en cambio, podríamos haber realizado una investigación del cliente, identificando métricas de resultados del cliente y trabajando hacia pequeños cambios que movieran la aguja hacia mejores resultados para el cliente.
REFERENCIAS
[ Gottesdiener ] Ellen Gottesdiener , 2019. “Uso del lienzo del producto:“ Introducción ”| “Defina los requisitos básicos de su producto” [EN LÍNEA] Disponible en: https://www.ebgconsulting.com/blog/using-product-canvas-define-product-getting-started/ y https://www.ebgconsulting.com/ blog / uso-del-lienzo-del-producto-para-definir-los-requisitos-principales-de-sus-productos /
[ Schwaber y Sutherland] Ken Schwaber y Jeff Sutherland, 2017. The Scrum Guide ™ . [EN LÍNEA] Disponible en: https://www.scrumguides.org/scrum-guide.html
[Gottesdiener-2] Ellen Gottesdiener , 2018. “Haz lo correcto, no todo”. [EN LÍNEA] Disponible en: https://www.ebgconsulting.com/blog/right-things-not-everything-product-management-ownership/
Share this content: