Conversis Consulting – Marketing orientado a resultados para mercados tecnológicos

Posts from the ‘desarrollo ágil’ category

Una gestión ágil de producto no debe significar que no tengamos un plan. Debemos aplicar un plan que sea flexible para acomodar cambios en las asunciones subyacentes y mantenga un equilibrio entre el largo y el corto plazo. Eso se consigue con el enfoque conocido como Cebolla de la Planificación.

Agile y planificación de producto no son incompatibles. La planificación multicapa o “Cebolla de la Planificación” (por motivos obvios, ver figura)  ayuda a los equipos de producto a elegir el nivel adecuado de detalle dependiendo del alcance temporal en el que están planificando. Estos niveles son:

  • Visión
  • Roadmap
  • Release
  • Iteración
  • Diario

Cebolla de planificación

Visión

En lo más alto del modelo tenemos el nivel de la Visión. Como sabemos, la visión define el futuro del producto a largo plazo (que según el producto de que se trate puede ser un período típicamente de entre uno y varios años): qué problemas va a resolver y para quién los va a resolver. La visión debe expresar y ayudarnos a entender el valor que nuestro producto aporta a los clientes y cómo podría diferenciarse de otras soluciones que intentan resolver los mismos problemas.

Una forma de conseguirlo es elaborar de forma colaborativa con los implicados en la organización un lienzo de visión de producto o un artefacto similar que podamos contrastar con el mercado.

Aunque la visión debe tener una vocación de estabilidad y de referencia a largo plazo esto no quiere decir que no tenga que revisarse periódicamente (sobre todo en mercados muy dinámicos) digamos en plazos de 6 meses a un año, para adaptarla a las nuevas condiciones de clientes, competidores, tecnologías, entorno, etc.

Roadmap

El roadmap es uno de los artefactos principales de la estrategia de producto y define cómo se van a alcanzar los objetivos plasmados en la visión a lo largo del tiempo (próximos meses-años). El roadmap despliega y expande la visión en una sucesión de versiones de producto (o, como veremos a continuación, de backlogs de release).

Especialmente el roadmap interno (dirigido a departamentos y stakeholders de nuestra empresa) suele ser muy detallado -incluyendo calendarios, proyectos, tecnologías- y constituye una potente herramienta de planificación y desarrollo. El roadmap no habla (sólo) de features, sino principalmente de mercados, aplicaciones, personas, problemas, escenarios, valor, capacidades y diferenciadores clave y objetivos de negocio.

Por el contrario, el roadmap externo va dirigido al mercado, es menos detallado y constituye esencialmente una herramienta de comunicación y marketing. En cualquier caso, tanto los roadmaps internos como los externos transmiten una información de prioridades y de disponibilidad.

El roadmap debe centrarse en temas

Desde el punto de vista de planificación de producto, es útil que cada release gire alrededor de un tema que define un objetivo de negocio, una persona o un problema de cliente.

¿Y por qué es importante? Porque sólo enfocándonos en un tema vamos a poder resolverlo al 100%. De lo contrario nuestro producto siempre va a quedarse resolviendo el 40% del problema de mucha gente pero no va a ser excelente para nadie. Y, como sabemos, la gente no tiene “medios problemas”, sino problemas enteros

Las técnicas de integración y despliegue continuos típicas de los productos digitales nos permiten ir liberando un flujo continuo de funciones y características. Pero que algo se “pueda hacer” no quiere decir que sea lo mejor que “debamos hacer”. Enfocar una release en todas las funciones y características que satisfacen un objetivo de negocio, una persona o un problema de cliente tienen ventajas no sólo a la hora de implementar una solución más integrada y consistente, sino a la hora de comunicarla y venderla. Empaquetando nuestras entregas alrededor de temas estamos insuflando a nuestro producto una vocación de propósito y foco muy valiosa.

El roadmap no debe ser muy detallado en la descripción de cada release (especialmente las más alejadas en el tiempo del momento actual) y específicamente en cuanto a la UX, funciones y características que cada una debe poseer. Todo eso se irá concretando -incluyendo las necesarias actividades de descubrimiento y validación de producto– cuando se vaya acercando el momento de entregar cada una de ellas. Lo que sí es importante es que explicite cualquier precedencia y dependencia entre funciones y características del producto en sus diferentes releases.

El roadmap debe revisarse y actualizarse con mayor frecuencia que la misión (y obviamente, siempre cuando ésta ha sido modificada). Períodos entre dos y seis meses (incluso menores) son habituales.

Release

En este nivel el objetivo es especificar las funciones y características que poseerá cada release definida en el roadmap. El backlog de release es un artefacto táctico que lista los trabajos necesarios para cumplir el plan estratégico de producto y su audiencia la constituyen principalmente los equipos de proyecto y desarrollo.

Al contrario que en el roadmap, que no debería entrar en excesivo detalle sobre funciones y características, el backlog de release se compone de épicas e historias de usuario, diagramas de flujo, bocetos de diseño y mockups de experiencia de usuario.

En general, el backlog de release se deriva del roadmap. Pero la influencia contraria también es posible: el feedback sobre la release que recibimos de los clientes puede servir para reajustar el roadmap. En conclusión, roadmap y backlog deben estar sincronizados.

El backlog de release se debe actualizar con cada actualización del roadmap y con cada liberación de release.

El problema con el ”backlog de producto”

A veces se usa un artefacto que está a caballo entre el roadmap y el backlog de release, llamado “backlog de producto”, y que puede recoger un backlog que abarca varias releases. Este concepto está heredado del mundo de los proyectos de desarrollo a medida, donde no existe una estrategia de producto con diferentes releases. A mi modo de ver éste es un artefacto confuso porque mezcla el enfoque multirelease del roadmap con la concreción del backlog y hace que la idea de propósito de cada release de producto se diluya y se pierda en una mezcla sin orden ni concierto de funciones y características. En muchas ocasiones, ese backlog de producto no es más que un aluvión de desarrollos, impuestos por diversos stakeholders, pero sin una integridad y consistencia. Personalmente prefiero enfocar el backlog de producto en la próxima release. Esto crea un backlog conciso, con un propósito y un significado claros, y más fácil de gestionar.

De modo que si lo más cercano a la planificación que tienes es un backlog de producto siento decirte que no tienes un roadmap (y probablemente, tampoco una estrategia de producto).

Iteración/Sprint

En una filosofía de desarrollo ágil, en el nivel de iteración el equipo selecciona los elementos individuales del backlog que comprende el siguiente ciclo y crean un plan para entregar cada historia.

Si la metodología que se sigue es  en concreto Scrum (donde las iteraciones se conocen como sprints) probablemente se reconozca este nivel como la sesión de planificación del sprint. En cualquier caso, incluso los equipos que no aplican una metodología Scrum tienden a realizar una forma de planificación de nivel de iteración al seleccionar y planificar sus próximos trabajos en pequeños lotes.

La planificación de iteración se realiza al principio de cada ciclo, en períodos típicamente de entre dos y seis semanas.

Diario

En este nivel de planificación el equipo evalúa el status al principio del día actual y colabora para elaborar un plan para avanzar hasta el siguiente día.

Muchos equipos consiguen esto mediante un “standup” diario, una reunión en la que discuten:

  • El progreso conseguido en el día anterior
  • El progreso que esperan conseguir en el día actual
  • Los obstáculos que pueden impedir dicho progreso y qué se puede hacer para contrarrestarlos.

Si bien este ritual matutino comienza con lo que se ha conseguido en el día anterior, los equipos más eficaces reconocen que el standup es una reunión de planificación, no de status. Por lo tanto, debería centrarse en crear un plan para avanzar al nivel diario.


En conjunto, estos niveles de planificación proporcionan el compromiso entre flexibilidad y detalle necesario para gestionar productos en este mundo Agile.

El post “Niveles de planificación de producto en Agile” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

La construcción ágil de productos necesita un “cerebro” que le dé una dirección y un propósito. La planificación de producto puede contribuir a ello, pero en escenarios ágiles la planificación tradicional (fija, predictiva) no sirve. Es necesaria una planificación más ágil, que incorpore componentes de flexibilidad, aprendizaje y adaptación.

“Nosotros somos ágiles. No planificamos.” ¿Os suena esta excusa? Vamos a hablar de algunas consecuencias indeseables de esta absurda interpretación en el campo de la planificación de producto y de cómo evitarlas.

Importante: en este post nos vamos a referir al uso de Agile en el desarrollo de productos para un mercado, no proyectos de desarrollo a medida de un cliente (donde se suele denominar “producto” al resultado del proyecto).

Agile necesita un cerebro

En muchos equipos Agile hay una gran frustración. Tienen la sensación de que lo único que hacen es entregar funciones y características a toda velocidad y sin orden ni concierto, sin que los responsables de producto tengan claro hacia dónde van o qué quieren conseguir realmente. Unas características que al final no añaden valor al cliente. Estos equipos han desplegado un “Agile sin cerebro”.

Agile necesita cerebroAgile proporciona un método optimizado e iterativo de implementar, pero seguimos alimentándolo con productos que están destinados al fracaso porque no han pasado por las fases críticas de eliminación de riesgos del proceso: comprobar la deseabilidad de los clientes y la viabilidad del negocio. Como dicen los americanos, hay una diferencia entre “build the features right” y “build the right features”.

Agile es una manera de construir, pero no nos va a servir para averiguar qué construir y cómo capturar valor de nuestras iniciativas de innovación. Nos da velocidad y cumplimiento pero si lo que le suministramos son malas ideas vamos a conseguir peores resultados… con la máxima velocidad y eficacia.  Por poner una analogía, si queremos cocinar un pato laqueado estilo Pekín, más vale que utilicemos  una buena receta con sus ingredientes y proceso en lugar de algo como «cada diez minutos abre la cazuela y pruébalo. Si está soso, añade sal. Si no sabe a nada, añade más comida».

Uno de los problemas de Agile es que -si no se refuerzan los mecanismos que animan a los equipos a considerar si las características que están incluyendo son las más adecuadas- esos comportamientos perversos van a proliferar. Por eso en Agile es importante, al igual que en el personaje del Espantapájaros del Mago de Oz, darle un cerebro.

Un cerebro para Agile

¿Y cómo podemos darle un cerebro a Agile? Hay varias herramientas para este objetivo:

  • Feedback de los clientes: tenemos que priorizarlo y operacionalizarlo, de modo que no sea un trámite. La esencia de Agile no es entregar lo más rápidamente posible desarrollos sin errores, sino aportar valor al cliente. Las revisiones del sprint no deben servir sólo para comprobar si se han implementado los elementos del backlog comprometidos, sino si estos son valiosos. No cambiemos velocidad por resultados.
  • Diseño de producto (y de modelo de negocio): Agile nos puede hacer olvidar que la experiencia del usuario debe tener sentido para ese usuario en cada release. Si renunciamos a descubrir y validar con antelación lo que se va a implementar podemos acabar con un producto fiable y bien construido pero que carezca de un significado, un valor y una interacción coherente. Es necesario combinar Agile con un diseño holístico y deliberado, enfocado en conseguir la mejor experiencia de cliente.
  • Planificación: Agile no es contrario a la planificación. Agile necesita planificación, pero de otro tipo. A este punto dedicaremos éste y el siguiente post.

Agile y planificación

La estrategia de producto ha podido ser una “baja colateral” en la transición a métodos ágiles. Muchos responsables de Agile se apegan a la noción errónea de que la idea de esta filosofía es mantenerse flexibles y que no hay que preocuparse o atarse a una dirección a largo plazo.

Siguiendo esta “no planificación” y respondiendo a las demandas instantáneas de cualquier stakeholder se pueden crear productos momentáneamente valiosos para alguien. Y se puede seguir así durante cierto tiempo, hasta que nos damos cuenta de que en realidad hemos ido “como pollos sin cabeza” y que alrededor del producto ha crecido toda una organización y esta falta de planificación ha provocado impactos que se extienden a varios grupos.

Los equipos ágiles necesitan un enfoque disciplinado para la planificación. Las organizaciones que invierten en una planificación adecuada tienen una mejor comprensión de los objetivos a largo plazo para el producto, y estrategias más realistas para alcanzar esos objetivos. Pero en escenarios cambiantes eso no se consigue con una planificación “tradicional”.

El problema con la planificación tradicional

Para entender mejor las ventajas de la planificación ágil, recordemos cómo funciona la planificación tradicional. Ésta sigue una serie de ciclos fijos y es esencialmente predictiva. Por ejemplo, en una sesión de planificación a principios de año se pueden fijar los objetivos para ese año, una estrategia y un plan detallado para alcanzarlos. Y, habitualmente, este plan tiene el mismo nivel de detalle para todos los períodos del año.

Pero -a pesar de las mejores intenciones y la confianza en esos planes- tarde o temprano la realidad golpea. Circunstancias imprevistas tales como las demandas de los clientes, los movimientos competitivos o desarrollos en el mercado global van a hacer que algunas partes de esos planes sean inalcanzables o incluso irrelevantes.

Pero, en lugar de intentar reconciliar el plan con esa nueva realidad, el equipo redobla sus esfuerzos para alcanzar sus aspiraciones anteriores. Finalmente esto da como resultado que el equipo tiene permanentes dificultades para alcanzar las expectativas de un plan inalcanzable y la organización está permanentemente decepcionada con su incapacidad para conseguirlo. En muchos casos, ésta es la realidad de la planificación tradicional.

¿Qué es la planificación ágil?

Una de las características de los enfoques de planificación ágil es que el equipo puede planificar con diferentes niveles de detalle dependiendo del alcance temporal para el cual están planificando. Por ejemplo, puede planificar sus objetivos para el año a alto nivel, su estrategia para alcanzar esos objetivos durante los próximos meses con un poco más de detalle y los pasos necesarios para implementar esa estrategia durante las próximas semanas con el máximo detalle. Este enfoque evita la necesidad de predecir en detalle el futuro lejano (con los riesgos que apareja) y proporciona al equipo claridad en cuanto a sus responsabilidades en el corto plazo, a la vez que les ayuda a entender cómo esa responsabilidad contribuye a los objetivos a largo plazo.

Pero la principal característica de los planes ágiles es que a medida que avanzamos en el tiempo, es posible que el equipo adapte y reelabore sus planes basándose en lo que ha ido aprendiendo durante el período. Los planes ágiles no son sólo planes para ejecutar sino también planes para aprender. Por tanto, Agile no significa que no tengamos un plan. Significa que tenemos un plan que es suficientemente flexible como para acomodar cambios valiosos e importantes en las asunciones subyacentes a dicho plan.

En lugar de operar al nivel de funcionalidad o característica, la planificación ágil necesita funcionar al nivel de visión o temática: establecer objetivos basados en áreas de mercado, necesidades de clientes o temas funcionales, y no en entregables funcionales o características definidos específicamente. Esto proporciona al negocio una base para saber hacia dónde ir pero mantiene la flexibilidad para cambiar el plan, bien en cuanto al entregable específico dentro del tema o bien cambiando el propio objetivo temático.

¿Y cómo alcanzamos ese equilibrio entre planificación a corto y largo plazo? Muchos equipos ágiles utilizan un enfoque de planificación multicapa, también conocido como la “Cebolla de la Planificación”, y que describiremos en el siguiente post.

El post “Planificación de producto y Agile: ¿son incompatibles?” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

Deja un comentario

Para reinventar el Marketing y ayudarle a liderar la transformación digital de la empresa es imprescindible adoptar unos procesos más ágiles, basados en la experimentación y la iteración, y  transformar las capacidades, roles y estructura de la organización.

En esta tercera y última parte del post (ver la primera y la segunda) terminamos de pasar revista a las ideas que Mohanbir Sawhney propone en su artículo “Re-imagining Marketing: A Roadmap For Transformation” para reimaginar y transformar la función de marketing de modo que pueda liderar la transformación digital de la empresa.

Procesos y ejecución

El proceso seguido tradicionalmente en marketing ha sido de planificación predictiva, análogo al proceso de desarrollo “en cascada”, con un flujo secuencial y centrado alrededor de grandes campañas con grandes presupuestos y largos plazos (marketing de “big-bang”).

Nueva manera de hacer negociosEn este enfoque el equipo empieza definiendo una gran estrategia de marketing, que se prueba y evalúa, se ajusta en función de estos resultados, se ejecuta en forma de creatividad y campañas y se miden sus efectos. Sin embargo, el marketing de “big-bang” es caro, lento e inflexible. Pone al personal de marketing en riesgo de cometer grandes fallos y, puesto que los planes se cierran al principio, hace difícil corregir una estrategia a mitad de camino.

El proceso de marketing ágil contrarresta estos problemas. Toma todas las etapas involucradas en el marketing “en cascada” — planificación, diseño, lanzamiento y medida — y las condensa en “porciones” que se llevan a cabo durante sprints en períodos de tiempo predefinidos. Equipos multidisciplinares colaboran para desarrollar múltiples microestrategias (en lugar de una gran estrategia). Las ideas se someten a ciclos rápidos de prueba y refinamiento para maximizar el aprendizaje en unos plazos de tiempo más cortos.

Hay cinco prácticas que definen el proceso de marketing ágil:

  • Las estrategias se dividen “porciones”. Una idea grande se segmenta en un backlog de cosas para hacer.
  • Los plazos se condensan. Se trabaja en sprints de duración predefinida para entregar un resultado.
  • Los equipos actúan como hackers y experimentan como científicos. Diseñan, prueban e iteran conceptos e una forma rápida y barata, buscando descubrir las palancas que influyen en las métricas clave para la experiencia del cliente.
  • La colaboración sustituye a la jerarquía. Gente de diversas funciones, departamentos y competencias cooperan en las actividades.
  • Los datos —no las opiniones— informan la estrategia. Los datos se consideran una herramienta de gestión de riesgos que evita cometer errores, a la vez que informa el desarrollo del trabajo creativo.

A la vez que esta transformación tiene lugar, también tiene que cambiar la ejecución de nuestro marketing. En particular tenemos que sustituir las campañas de “lanzar y olvidar” por conversaciones “siempre activas”. Así, en lugar de ejecutar una campaña sobre el lanzamiento de un producto o servicio tenemos que entablar una conversación permanente con nuestros clientes sobre un tema que sea relevante, útil o atractivo para ellos.

Personas y organización

Para sustentar las nuevas funciones del marketing también hay que transformar las capacidades, roles y estructura de la organización de marketing. Los CMOs deben hacer tres cosas para acometer este cambio: en primer lugar, deben reestructurar la organización y cubrir un nuevo conjunto de funciones; en segundo, deben gestionar los problemas relacionados con las personas y los procesos que inevitablemente se suscitarán cuando las distinciones entre funciones se hagan más difusas; y, finalmente, tienen que mejorar sus propias capacidades y prepararse para asumir  un papel mayor: responsable del front office.

La nueva organización de marketing requiere la creación de diversas funciones nuevas: gestión de contenidos, analítica, automatización, etc. Antes de desarrollar estas funciones tenemos que comunicar nuestros planes de reestructuración con los departamentos y equipos involucrados (incluyendo el propio de marketing). Entre ellos, hay que plantear una visión clara a Recursos Humanos para que pueda establecer un plan para contratar nuevos empleados, transformar las habilidades de los empleados existentes, reposicionar empleados dentro de la organización y aconsejar a otros su salida. Preparémonos para tomar decisiones difíciles sobre personas, presupuestos y puestos, puesto que habrá que dejar marchar a empleados con capacidades obsoletas para hacer sitio a otros nuevos.

Tengamos en cuenta que esta transformación también tiene implicaciones directas sobre nosotros como CMOs. Una, el alcance de nuestro trabajo de comunicación de marketing convencional se estrechará a medida que emerge la nueva organización.  Dos, en la empresa se desarrollará una necesidad para un ejecutivo de primer nivel que dirija  las funciones de interacción con los clientes. Por lo tanto, hay una necesidad y una oportunidad para extender nuestro papel. Analicemos nuestras capacidades en datos, automatización y analítica y busquemos oportunidades para desarrollar nuestra experiencia en tecnología. Si afrontamos el desafío seremos un gran aspirante a liderar el front office.

El camino por delante

El viaje hacia la nueva organización de marketing no es fácil, pero esta transformación es inevitable. Como CMOs, tenemos que dar un paso adelante para liderar el cambio. Si no, alguien lo hará y en ausencia de nuestro liderazgo es probable que los tres pilares de la nueva organización —datos, automatización y analítica— acaben repartidos entre otros departamentos.

Y si eso no resulta suficientemente convincente tengamos en cuenta esto: nn muchas empresas  la transformación digital es uno de los puntos más importantes en la agenda del CEO, nuestros competidores lo están haciendo y nuestra compañía no puede esperar más tiempo. Ha llegado el momento de tomar la iniciativa.

El post “Reinventando el Marketing (3)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Marketing estratégico para empresas tecnológicas y El nuevo marketing digital en mercados tecnológicos te pueden ayudar.]

Deja un comentario

En entornos cambiantes, la ejecución rápida e iterativa y la adaptación que caracterizan al marketing ágil proporcionan una mayor velocidad, capacidad de respuesta y resultados centrados en el mercado.

Cuando el negocio se pone difícil muchos ejecutivos se sienten validados para recortar presupuestos y personal de Marketing porque este departamento suele tener dificultades para demostrar su contribución al negocio. Marketing sufre una tendencia a intentar hacer muchas cosas, con un nivel obsesivo de perfección, de manera a veces demasiado opaca y desconectada de otros departamentos y habitualmente siguiendo un plan anual que fue definido varios meses atrás y que no tiene relación con la situación actual.

Como vimos en el post anterior, un enfoque ágil para el marketing puede contribuir a resolver estos problemas. El Agile Marketing está especialmente orientado a afrontar los retos de unas condiciones de mercado que se mueven a gran velocidad y de una adaptación rápida de las campañas y programas de marketing.

Basado –a menudo vagamente– en las metodologías de desarrollo ágil de software tales como Scrum, el Agile Marketing permite a los marketers ejecutar sus programas en ciclos de planificación más cortos, de semanas en lugar de meses o años. Esto promueve un enfoque mucho más iterativo que permite una entrega de valor más rápida y una respuesta más veloz al feedback del mercado.

Agile Benefits

Fuente: Forbes

Este post (continuación de uno anterior en el que enunciábamos los elementos básicos del marketing ágil) se centra en sus pilares fundamentales y los beneficios que aporta, y está también basado en las ideas de Scott Brinker.

Los pilares del Agile Marketing

Es posible adaptar las metodologías ágiles para que se ajusten mejor a tu organización. En cualquier caso, para que tenga éxito el Agile Marketing debe estar basado en los siguientes principios fundamentales:

  • Ejecución incremental e iterativa. Descomponer las campañas, programas y actividades en elementos de pequeño tamaño que se van refinando y ampliando con una rápida cadencia en sprints sucesivos.
  • Priorización. Cuando todo tiene prioridad máxima, nada la tiene. Dar a todo el equipo los mecanismos para ponerse de acuerdo en lo que es importante y tomar decisiones intencionadamente, no accidentalmente.
  • Transparencia. Construir confianza mediante la visibilidad. Utilizar una comunicación abierta para permitir que todo el mundo sepa cuáles son los resultados buscados y qué se está haciendo para alcanzarlos.
  • Empoderamiento. Dar a los equipos la responsabilidad de marcar la diferencia, de dar forma a su trabajo y de ser reconocidos por su contribución. Habilitarles para tomar decisiones y responsabilizarse de sus resultados.
  • Experimentación. Habilitar la manera en que los equipos puedan probar innovaciones rápidamente, frecuentemente y a una escala pequeña. Asumir que el único experimento fallido no es aquel que no produce los resultados deseados, sino el que no permite aprender nada.
  • Aprendizaje. Utilizar el feedback del mercado y las revisiones y las evaluaciones retrospectivas de cada sprint para medir el impacto y obtener evidencias basadas en datos sobre lo que funciona y lo que no.
  • Adaptabilidad. Lo único permanente es el cambio, así que hay que aceptarlo y aprovecharlo, en lugar de oponerse a él. La adaptabilidad es una forma de pensar: hay que crear la flexibilidad para que aquello que funciona salga adelante y prescindir de lo que no sirve. Y estar dispuestos a aprovechar el aprendizaje obtenido en cada sprint para cambiar el rumbo y moverse en una dirección diferente.

Los beneficios de un marketing más ágil

Tanto si aplicas un enfoque basado en Scrum como si creas tu propia metodología es previsible que la aplicación del Agile Marketing redunde en las siguientes mejoras:

  • Velocidad. A menudo se alaba al Agile Marketing por su velocidad: su cadencia más rápida facilita a los equipos de marketing poner ideas en el mercado más rápidamente. Pero aunque esto pueda resultar frecuentemente un valioso beneficio lateral, mal entendido puede llevar a las iniciativas de marketing ágil al fracaso. Como veremos más adelante, un énfasis excesivo en la velocidad puede ser en detrimento de la calidad del trabajo y de la misión del marketing. La verdadera velocidad de Agile viene por la entrega de resultados valiosos al final de cada sprint -no sólo al final del proyecto- y no significa entregar más rápidamente cualquier cosa, sino más valor para el mercado.
  • Capacidad de respuesta. El corazón del Agile Marketing está realmente en su capacidad de respuesta. Un enfoque con ciclos de planificación cortos y frecuentes y aprovechar los bucles de realimentación del mundo digital permite responder rápidamente al entorno y reaccionar ante nuevas amenazas y oportunidades.
  • Enfoque. La priorización previa del backlog, el timeboxing y la prohibición de incorporar nuevas demandas a mitad de desarrollo fomentan que durante el sprint el equipo esté concentrado en los contenidos de dicha iteración y estos sean consistentes con los objetivos a largo plazo.
  • Coordinación. La transparencia y las reuniones de planificación, revisión, retrospectiva y stand-ups diarios fomentan la coordinación, la colaboración y la identificación y eliminación de impedimentos.
  • Entregables y resultados centrados en el mercado. La incorporación continua de feedback del mercado fomenta que campañas, canales y contenidos estén especialmente adaptados a las necesidades de los clientes y las oportunidades de los mercados.
  • Mejora continua. La experimentación, la adaptación y el aprendizaje permiten ir depurando nuestras estrategias, técnicas y herramientas de marketing.

Desmontando algunos mitos del Agile Marketing

Como todas las filosofías que tratan de renovar una disciplina, el marketing ágil se enfrenta a cierta incomprensión y resistencia.  En este apartado vamos a discutir alguno de los mitos más asociados con este enfoque:

  • El Agile Marketing es un eufemismo para decir “trabajar más rápido”. En realidad el marketing ágil produce resultados más rápidamente porque habilita una entrega incremental e iterativa. No se trata de trabajar más o más rápido, sino de asignar el tiempo y el esfuerzo a actividades que proporcionan valor.
  • El Agile Marketing es sinónimo de “rápido y sucio” o de baja calidad. Nada más lejos de la realidad porque cada incremento o iteración puede ser producido con la máxima calidad y cuidado. Llevar rápidamente al mercado un trabajo deficiente no es ágil: sólo es deficiente. Además, reducir las demandas que aparecen a mitad de sprint también ayudan a aumentar la calidad y la consistencia.
  • El Agile Marketing es «corto de vista», no hay planes a largo plazo. En realidad el marketing ágil no trata de eliminar los planes a largo plazo, sino de implementar una planificación a largo plazo que sea más adaptativa y con mayor capacidad de respuesta. Como veíamos en el anterior post, una visión a largo plazo fuerte y clara es lo que alimenta el proceso ágil. Esa visión se conecta con el sprint actual mediante la priorización del backlog. El sprint actual se conecta con la visión a largo plazo durante la revisión de la iteración. Asimismo, minimizar las demandas ad-hoc mientras el sprint está en progreso ayuda a mantener el foco estratégico.

Al “plan de marketing” no le queda más remedio que volverse adaptativo y tener la capacidad de autocorregirse. El marketing ágil consiste en equilibrar una dirección clara con la adaptabilidad y la respuesta rápida, y así poder sustentar una estrategia emergente.

El post “Beneficios y mitos del Marketing Ágil” se publicó primero en “Marketing & Innovación”.

[¿Interesado en un Marketing más ágil? Contáctanos y te ayudaremos a implantarlo.]

Deja un comentario

El Marketing necesita evolucionar y la filosofía Agile, proveniente del mundo del software, puede ser de gran ayuda. Pero para implantar un marketing más ágil no es imprescindible adoptar ninguna de las metodologías de Agile, sino empezar a pensar y actuar en clave de velocidad, adaptabilidad, experimentación, transparencia y empoderamiento del equipo.

Las nuevas condiciones de alta incertidumbre y cambio rápido que afectan a todas las organizaciones están obligando a redefinir las actividades y funciones de la empresa. Sin embargo, en ninguna de ellas se percibe tanta presión como en el marketing, donde unos clientes más conectados y exigentes y un nuevo equilibrio informativo a favor de los compradores están forzando a una verdadera reinvención de esta función. El marketing está pasando de ser una actividad más o menos complicada a algo realmente complejo.

Y un catalizador para esos cambios que el marketing necesita puede estar en las filosofías ágiles, originarias del mundo del software. En este blog hemos hablado repetidamente sobre el uso de Agile para el desarrollo de proyectos a medida, y también para el desarrollo y la gestión de productos para un mercado.

Marketing Ágil

Manifiesto para un Marketing Ágil

Lo cierto es que en los últimos años se ha despertado el interés por unos enfoques más flexibles e iterativos para la planificación, la ejecución y el control del marketing. Tanto es así que en 2012 -y siguiendo los pasos de sus colegas en la industria del software once años antes- un conjunto de marketers se reunieron en San Francisco y consensuaron un Agile Marketing Manifesto que describe los valores y principios de esta filosofía:

“Estamos descubriendo maneras mejores de crear valor para nuestros clientes y para nuestras organizaciones mediante nuevos enfoques de marketing. A través de este trabajo, hemos llegado a valorar…

  • Aprendizaje validado, más que opiniones y convenciones
  • Colaboración centrada en el cliente, más que silos y jerarquía
  • Campañas adaptativas e iterativas, más que tipo “big bang”
  • Proceso de descubrimiento de los clientes, más que predicción estática
  • Planificación flexible, más que rígida
  • Responder al cambio, más que seguir un plan
  • Muchos experimentos pequeños, más que unas pocas apuestas grandes.”

Esos valores son bastante autoexplicativos (especialmente para los lectores de este blog), aunque iremos profundizando en ellos en éste y siguientes posts. Y personalmente me gusta añadir al manifiesto “oficial” una apostilla de Scott Brinker (una de mis referencias en marlketing ágil) que propone este punto adicional:

  • Calidad de marca consistente, más que velocidad y cantidad en la ejecución (esencialmente, la idea de Scott es evitar producir trabajo de baja calidad para no incurrir en “deuda de marca”).

Implantando un marketing ágil

Al igual que ocurre con las implementaciones de Agile para desarrollo de proyectos, para implantarlo en marketing es posible optar por alguna de las múltiples metodologías ágiles existentes, entre las cuales Scrum, Kanban o una combinación de ambas son las más populares.

Nunca he sido un “talibán” de las metodologías ágiles ni un partidario de su ceremonia, por eso mi consejo -si quieres empezar a evaluar Agile y tu equipo de marketing es reducido- es que prescindas de las metodologías formales y apliques simplemente los principios básicos de la filosofía y unos procesos más ad-hoc e informales, con unos artefactos mínimos. Desde mi punto de vista estos elementos (que resultarán bastante familiares a los lectores que conozcan Scrum) son:

  • Partir de una “visión de marketing”, que podemos identificar con unos objetivos comerciales y una estrategia que define cómo vamos a alcanzar dichos objetivos en lo que se refiere a segmentos, propuestas de valor, productos, precios, canales y proceso de generación de ingresos (“fábrica de clientes”). Esta visión debe ser clara pero también revisable y adaptable. El marketing ágil consiste principalmente en conjugar y compensar una dirección definida con una adaptabilidad y capacidad de respuesta.
  • Organizar el personal en uno o varios equipos pequeños (típicamente de menos de 10 personas) enfocados en el trabajo práctico. Estos equipos están autogestionados y poseen una alta comunicación y transparencia interna y externa, y en ellos los perfiles profesionales “en forma de T” son la norma general.
  • Estructurar el trabajo como una sucesión de ciclos o “sprints de unas pocas semanas (2-4) de duración, durante los cuales se desarrolla un conjunto predeterminado de tareas. Como veremos, estos ciclos cortos imponen una entrega rápida de resultados y un feedback frecuente por parte de involucrados y clientes.
  • Las tareas a ejecutar en cada ciclo se eligen previamente en una reunión de planificación del sprint de entre los elementos de una pila o backlog. El backlog se mantiene permanentemente priorizado y actualizado, con la incorporación y eliminación constante de elementos. Los elementos que en cada momento tienen una mayor prioridad -susceptibles de incorporarse al siguiente sprint- se detallan de forma que definan agregaciones significativas de trabajo y en caso necesario se descomponen en tareas más pequeñas, cada una de las cuales se pueda desarrollar en un solo ciclo.
  • Durante cada sprint el equipo se concentra en la ejecución de los elementos del backlog asignados, minimizando los cambios de prioridad y la inclusión de nuevas tareas. Estos elementos deben tener un alcance y concreción adecuados para ser desarrollados en el plazo de un sprint. Ejemplos de elementos o tareas pueden ser: escribir un caso de cliente, configurar una campaña de cultivo de leads en la plataforma de automatización de marketing, conectar con influenciadores sociales en nuestro sector, etc.
    • Las tareas de mayor tamaño que inicialmente figuraban en el backlog (que requieren mucho tiempo y recursos) han sido descompuestas antes del sprint en partes o elementos más pequeños, de modo que uno o varios de ellas tengan cabida en un ciclo: este enfoque incremental permite une entrega rápida de resultados.
    • Por el contrario, las tareas más arriesgadas o nuevas para la organización se desarrollan mediante refinamientos sucesivos a través de varios sprints: este enfoque iterativo favorece la experimentación con nuevos tipos de actividades.
  • Durante el desarrollo de un sprint la comunicación y colaboración entre los miembros del equipo es máxima. A esta colaboración contribuyen las reuniones stand-up diarias (con una duración máxima de 15 minutos y realizadas de pie), donde cada miembro del equipo expone los siguientes puntos y en equipo se buscan soluciones a posibles problemas en las siguientes áreas:
    • ¿Qué conseguí ayer?
    • ¿Qué voy a hacer hoy?
    • ¿Qué obstáculos están impidiendo mi avance?
  • Una vez concluidos los desarrollos de un sprint hay un proceso de revisión durante el cual se obtiene feedback sobre los resultados desde el punto de vista del “cliente”, que para un cierto elemento del sprint puede ser interno o externo. Unos buenos KPIs que midan en qué medida estamos alcanzando nuestros objetivos resultan primordiales para que este feedback permita evaluar los resultados del sprint.
  • Además, después de cada sprint hay una reunión retrospectiva que sirve para analizar qué se ha hecho bien o mal desde el punto de vista de proceso (no de tareas o resultados) para identificar las prácticas en las que deberíamos insistir y aquellas otras que deberíamos abandonar.

Estos son los elementos básicos para construir un marketing ágil, según mi opinión. En el próximo post hablaremos de los beneficios que se pueden obtener con estos enfoques. Mientras tanto ¿cuál es vuestra experiencia implantando un marketing más ágil?

El post “Fundamentos de un Marketing más ágil” se publicó primero en “Marketing & Innovación”.

[¿Interesado en un Marketing más ágil? Contáctanos y te ayudaremos a implantarlo.]

Deja un comentario

Las nuevas filosofías de desarrollo de productos y negocios tienen muchos puntos en común pero también algunas contradicciones. En realidad, cada una de ellas representa una visión parcial de un nuevo proceso de innovación que está emergiendo y cuyas piezas todavía tienen que acabar que encajar.

Una de las primeras cosas que vienen a la cabeza cuando uno intenta profundizar y aplicar las diversas filosofías de la “nueva innovación” (Agile, Diseño, Customer Development, Lean Startup…) es una curiosa sensación de déjà vu. Cuando se ha familiarizado con las iteraciones y los experimentos de Customer Development (o de Diseño, o de Agile) y empieza a estudiar los otros enfoques es difícil evitar un pensamiento de “todo esto me suena mucho” y “una vez que dominas una, las dominas todas”.

Pero ¿realmente esto es así? ¿Cuánto hay de similar y de diferente en estas filosofías? Vamos a estudiarlo para el caso de empresas orientadas a producto (repetible, para un mercado, no proyectos a medida de un cliente).

Customer Development, Diseño y Agile

Si no son lo mismo al menos lo parecen…

La realidad es que por diversas razones (entre ellas la contemporaneidad) todas ellas comparten muchas ideas. Esencialmente, son filosofías que tratan de enfrentarse a los retos del desarrollo de nuevos productos y negocios en escenarios de gran riesgo y velocidad, que se han desarrollado prácticamente a la vez –a partir de finales del pasado siglo– y que se han “interfertilizado” mutuamente (por no decir que en ocasiones se han copiado sin demasiados miramientos). Y aunque cada una de ellas posee un lenguaje propio, en conjunto presentan muchas coincidencias y temas recurrentes:

  • Foco en el cliente
  • Experimentación (Producto Mínimo Viable, prototipos…)
  • Feedback
  • Aprendizaje
  • Iteración (sprints, ciclos…)
  • Coordinación y comunicación (interna y externa)
  • Equipos multidisciplinares

En realidad, estas filosofías ofrecen puntos de vista diferentes y parciales de lo que esencialmente es un mismo proceso: el que tiene por objetivo desarrollar un nuevo producto/empresa. Pero ahora ya no se trata de un proceso que siga un modelo lineal, por fases o en cascada, como los que han venido utilizándose con cierto éxito en el desarrollo de innovaciones incrementales.

Este nuevo modelo que va emergiendo es más adecuado para el desarrollo de productos y negocios verdaderamente nuevos – situaciones donde ni los clientes, ni sus necesidades, ni las soluciones que podrían cubrirlas ni las tecnologías que se aplicarían son totalmente conocidas o están en evolución– y es mucho más flexible y centrado en el mercado.

Agile, Diseño, Customer Development, Lean Startup son diferentes…

La realidad es que estas filosofías son diferentes (incluso complementarias) en cuanto a sus objetivos y alcance. A fin de distinguir entre unos enfoques y otros, si tuviéramos que resumir cada uno de ellos en un slogan o un par de frases el resultado podría ser el siguiente:

  • Customer Development – Sal fuera de la oficina y pon a prueba iterativamente las hipótesis de tu negocio. Después, constrúyelo y escala.
  • Diseño (y Design Thinking) – Crea productos (y negocios) que los clientes deseen a través de la empatía y el prototipado.
  • Agile – Entrega rápidamente valor a los clientes mediante una construcción iterativa e incremental que incorpora continuamente el feedback del mercado.
  • Lean Startup – Integra y aplica las filosofías anteriores en un contexto de emprendimiento: aplica ciclos rápidos de Construir-Medir-Aprender para que tu empresa sea flexible y rápida y use sus recursos de la manera más eficiente.

Dejando a un lado Lean Startup, que es una filosofía de empresa y hasta cierto punto engloba los demás enfoques, los otros representan perspectivas diferentes (y en ocasiones solapadas) del desarrollo de nuevos productos y negocios pero ninguno aporta una solución completa a todo el proceso de desarrollo. Por ejemplo:

  • Customer Development representa eminentemente una óptica de (modelo de) negocio. Es imprescindible validar la Propuesta de Valor y las otras hipótesis del modelo de negocio, pero en paralelo necesitamos saber cómo “poblar” esa propuesta y definir, diseñar y construir el producto. Los propios promotores del Customer Development aclaran que es necesario complementarlo con un proceso de “Product Development”. En particular Steve Blank y Eric Ries proponen que ese desarrollo de producto consista básicamente en una Ingeniería Ágil pero desde mi punto de vista eso no es suficiente.
  • El Diseño, especialmente el Diseño UX, recoge –como no podía ser de otra manera– la visión del diseñador y se centra en encontrar la solución para el problema/necesidad del mercado. Pero en general no entra en las actividades de definición del modelo de negocio ni de evaluación de la oportunidad de mercado y tampoco en la construcción del producto real.
  • Agile, por su parte, representa la visión del ingeniero y se enfoca en la construcción/implementación de la solución. Pero tampoco entra en las actividades de definición del modelo de negocio ni de evaluación de la oportunidad de mercado y trata de evitar las de investigación de clientes y diseño.

… e incluso contradictorias

Pero además, lo que es innegable para alguien que haya estudiado con un mínimo espíritu crítico estas filosofías (algo no habitual entre muchos de sus apóstoles)  es que entre ellas hay algunas diferencias y contradicciones muy relevantes:

Todos estos enfoques son las piezas de un puzzle que conforma un nuevo proceso de desarrollo de productos y negocios. La buena noticia es que muchos creemos que este proceso nos va a ayudar a innovar de manera más flexible y con mayores probabilidades de éxito. La mala noticia es que las piezas todavía no encajan muy bien… pero seguro que entre todos lo vamos a conseguir.

El post “Agile, Diseño, Customer Development, Lean Startup… ¿es todo lo mismo?” se publicó primero en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

2 comentarios

El rol de Product Owner no es suficiente en empresas basadas en producto. Para que un Product Owner pueda colaborar eficazmente con su Product Manager (o asumir alguna de sus funciones) es imprescindible un mayor conocimiento y experiencia en aspectos de negocio.

Las empresas de producto que desean tener éxito en el mercado necesitan Product Managers  experimentados… y los contratan. No hay más hay que ver las ofertas de empleo que se publican en los sitios web de las propias compañías (incluso de las más punteras) o en LinkedIn.

El rol de Product Owner no es suficiente en empresas que comercializan productos para un mercado. Para que un Product Owner pueda colaborar eficazmente con su Product Manager (o asumir alguna de sus funciones) es imprescindible un mayor conocimiento y experiencia en aspectos de negocio. Las empresas de producto que desean tener éxito en el mercado necesitan Product Managers  experimentados… y los contratan. No hay más hay que ver las ofertas de empleo que se publican en los sitios web de las propias compañías (incluso de las más punteras) o en LinkedIn. Sin embargo, en los últimos años la tendencia a la “agilización” ha llevado a algunos evangelistas de Agile a promover la sustitución del “anticuado puesto de Product Manager” por el más moderno de Product Owner. En realidad, lo que estos apóstoles promueven es extender las atribuciones del rol de Product Owner original de Scrum, elevándolo a la altura de una especie de “Súper Product Owner”, que aborde cada vez más áreas de la gestión de producto. En definitiva, lo que postulan es sustituir el rol de Product Manager por el de un Product Owner cuyas funciones cada vez se parece más a las de aquél. En este blog hemos hablado ya de las relaciones entre Product Manager y Product Owner y de por qué prescindir de uno u otro puesto es una mala idea. Y personalmente soy un firme partidario de aplicar lo que de bueno tienen los enfoques Agile/Lean/Design Thinking al Product Management… y a todas las áreas de la empresa. Creo que las empresas de producto -especialmente en mercados tecnológicos, rápidos e innovadores- se beneficiarían de una Gestión de Producto más Agile/Lean (no quiero entrar en guerras de religión con el nombre). Pero es ilusorio pensar que por ampliar el alcance del rol de Product Owner y prescindir del de Product Manager vamos a gestionar mejor nuestros productos. Y lo creo por varios motivos: •	Las actividades de un Product Owner (incluso en sus versiones más avanzadas) son una parte de las necesarias para garantizar el éxito de un producto en el mercado, y que definen la responsabilidad del Product Manager. El desarrollo de nuevos productos no lo es todo: antes hay que descubrir y analizar la oportunidad de mercado y después hay que comercializar, explotar, mantener y evolucionar el producto. Contrariamente a lo que muchos ingenieros podrían pensar, el lanzamiento no es el principio del fin de un producto: es el fin del principio. Un rol que en sus versiones más básicas únicamente existe durante el proyecto de construcción del producto no puede aspirar a garantizar el éxito de éste en el mercado. •	La realidad es que lo que con mayor frecuencia se encuentra en las empresas es un “Mini Product Owner”, no sólo en actividades, sino en habilidades. Aparte de que el alcance de los roles de Product Manager y Product Owner son diferentes (el Jefe de Producto es mucho más estratégico y enfocado al exterior), el tipo de profesional que desempeña este último tampoco ayuda. En la mayoría de las empresas se trata de alguien con bagaje puramente técnico y con escasa experiencia y aptitud para entender realmente un mercado, descubrir las necesidades esenciales de los clientes y colaborar con los otros departamentos de la empresa y gestionar el producto como un negocio a lo largo de todo su ciclo de vida. (Nota al margen: la formación sobre Product Owner/”Agile Product Manager” disponible en España deja bastante que desear, limitándose en muchos casos a cubrir una Gestión Ágil de PROYECTOS, en el mejor de los casos complementada con pinceladas de Lean Startup y otros enfoques de moda, pero no necesariamente con gestión de PRODUCTO). El Product Owner típico necesita más conocimientos y habilidades de negocio No podemos dar la “propiedad” de los aspectos estratégicos de un producto a alguien que carece de los conocimientos y la experiencia necesarios. Estos son algunos de ejes de gestión de producto que deberían mejorar muchos Product Owners:  •	Mejorar su perspectiva sobre la estrategia de producto global y las sinergias de la cartera de productos. El Product Owner típico tiende a optimizar la release, sin tener en cuenta las oportunidades de bundling y cross-selling con otros productos, y a veces pierde de vista el roadmap. •	Aprender a diferenciar entre unos pocos clientes y el mercado en su conjunto. El Product Owner medio tiende a dar credibilidad y a generalizar el input de los clientes más cercanos o comunicativos y de aquellos que se avienen a probar el producto durante el desarrollo. Además, es habitual que el mercado se componga en realidad de diferentes grupos de clientes, cada uno caracterizado por unas necesidades similares - pero diferentes de un grupo a otro. Pero las técnicas de segmentación y targeting no suelen estar entre los conocimientos del Product Owner. •	Entender los drivers que crean valor para el cliente para convertirlos en productos más comprables y aprender a elaborar posicionamientos, comparativas respecto a la competencia y mensajes significativos para el mercado. Las propuestas de valor que elabora el Product Owner típico en realidad consisten en enumeraciones de atributos y funcionalidades. •	Entender el modelo de negocio que sustenta el producto y las herramientas para capturar el máximo valor para la empresa: packaging, pricing. El Product Owner medio tiene tendencia a añadir funcionalidades sin pensar en cómo rentabilizarlas. •	Aprender a priorizar aspectos estratégicos del producto (tales como la experiencia de usuario, los drivers de compra o una arquitectura que permita evolucionarlo fácilmente y crear productos derivados) frente a funcionalidades de usuario visibles individuales. •	Mejorar sus habilidades para comunicar eficazmente y aumentar su credibilidad ante los departamentos de Marketing, Ventas, Soporte, la Dirección de la empresa y, en general, todos los que tienen que contribuir a que el producto sea un éxito en el mercado. Un Product Owner que mejorara sus capacidades de gestión de producto no sólo podría colaborar más eficazmente con su Product Manager, sino que podría abrir una vía de desarrollo y evolución profesional hacia ese rol. En resumen, necesitamos una gestión de productos mucho más Agile/Lean, pero suprimir la figura del Product Manager y sustituirla por la de un (Súper) Product Owner no es la manera de conseguirlo. El post “Si quieres ser un Product Owner excelente aprende Product Management” se publicó primero en “Marketing & Innovación”. [Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

Sin embargo, en los últimos años la tendencia a la agilización ha llevado a algunos evangelistas de Agile a promover la sustitución del “anticuado puesto de Product Manager” por el más moderno de Product Owner. En realidad, lo que estos apóstoles promueven es extender las atribuciones del rol de Product Owner original de Scrum, elevándolo a la altura de una especie de “Súper Product Owner”, que aborde cada vez más áreas de la gestión de producto. En definitiva, lo que postulan es sustituir el rol de Jefe de Producto por el de un Product Owner cuyas funciones cada vez se parecen más a las de aquél.

En este blog hemos hablado ya de las relaciones entre Product Manager y Product Owner y de por qué prescindir de uno u otro puesto es una mala idea. Y personalmente soy un firme partidario de aplicar lo que de bueno tienen los enfoques Agile/Lean/Design Thinking al Product Management… y a todas las áreas de la empresa. Creo que las empresas de producto -especialmente en mercados tecnológicos, rápidos e innovadores- se beneficiarían de una Gestión de Producto más Agile/Lean (no quiero entrar en guerras de religión con el nombre).

Pero es ilusorio pensar que por ampliar el alcance del rol de Product Owner y prescindir del de Product Manager vamos a gestionar mejor nuestros productos. Y lo creo por varios motivos:

  • Las actividades de un Product Owner (incluso en sus versiones más avanzadas) son una parte de las necesarias para garantizar el éxito de un producto en el mercado, y que definen la responsabilidad del Product Manager. El desarrollo de nuevos productos no lo es todo: antes hay que descubrir y analizar la oportunidad de mercado y después hay que comercializar, explotar, mantener y evolucionar el producto. Contrariamente a lo que muchos ingenieros podrían pensar, el lanzamiento no es el principio del fin de un producto: es el fin del principio. Un rol que en sus versiones más básicas únicamente existe durante el proyecto de construcción del producto no puede aspirar a garantizar el éxito de éste en el mercado.
  • La realidad es que lo que con mayor frecuencia se encuentra en las empresas es un “Mini Product Owner”, no sólo en actividades, sino en habilidades. Aparte de que el alcance de los roles de Product Manager y Product Owner son diferentes (el Jefe de Producto es mucho más estratégico y enfocado al exterior), el tipo de profesional que desempeña el de Product Owner tampoco ayuda. En la mayoría de las empresas se trata de alguien con bagaje puramente técnico y con escasa experiencia y aptitud para entender realmente un mercado, descubrir las necesidades esenciales de los clientes y colaborar con los otros departamentos de la empresa y gestionar el producto como un negocio a lo largo de todo su ciclo de vida.

(Nota al margen: la formación sobre Product Owner/”Agile Product Manager” disponible en España deja bastante que desear, limitándose en muchos casos a cubrir una Gestión Ágil de PROYECTOS, en el mejor de los casos complementada con pinceladas de Lean Startup y otros enfoques de moda, pero no necesariamente con gestión de PRODUCTO).

El Product Owner típico necesita más conocimientos y habilidades de negocio

No podemos dar la “propiedad” de los aspectos estratégicos de un producto a alguien que carece de los conocimientos y la experiencia necesarios. Estos son algunos de ejes de gestión de producto que deberían mejorar muchos Product Owners:

  • Mejorar su perspectiva sobre la estrategia de producto global y las sinergias de la cartera de productos. El Product Owner típico tiende a optimizar la release, sin tener en cuenta las oportunidades de bundling y cross-selling con otros productos, y a veces pierde de vista el roadmap.
  • Aprender a diferenciar entre unos pocos clientes y el mercado en su conjunto. El Product Owner medio tiende a dar credibilidad y a generalizar el input de los clientes más cercanos o comunicativos y de aquellos que se avienen a probar el producto durante el desarrollo. Además, es habitual que el mercado se componga en realidad de diferentes grupos de clientes, cada uno caracterizado por unas necesidades similares – pero diferentes de un grupo a otro. Pero las técnicas de segmentación y targeting no suelen estar entre los conocimientos del Product Owner.
  • Entender los drivers que crean valor para el cliente para convertirlos en productos más comprables y aprender a elaborar posicionamientos, comparativas respecto a la competencia y mensajes significativos para el mercado. Las propuestas de valor que elabora el Product Owner típico en realidad consisten en enumeraciones de atributos y funcionalidades.
  • Entender el modelo de negocio que sustenta el producto y las herramientas para capturar el máximo valor para la empresa: packaging, pricing. El Product Owner medio tiene tendencia a añadir funcionalidades sin pensar en cómo rentabilizarlas.
  • Aprender a priorizar aspectos estratégicos del producto (tales como la experiencia de usuario, los drivers de compra o una arquitectura que permita evolucionarlo fácilmente y crear productos derivados) frente a funcionalidades de usuario visibles individuales.
  • Mejorar sus habilidades para comunicar eficazmente y aumentar su credibilidad ante los departamentos de Marketing, Ventas, Soporte, la Dirección de la empresa y, en general, todos los que tienen que contribuir a que el producto sea un éxito en el mercado.

Un Product Owner que mejorara sus capacidades de gestión de producto no sólo podría colaborar más eficazmente con su Product Manager, sino además abrir una vía de desarrollo y evolución profesional hacia ese rol.

En resumen, necesitamos una gestión de productos mucho más Agile/Lean, pero suprimir la figura del Product Manager y sustituirla por la de un (Súper) Product Owner no es la manera de conseguirlo.

El post “Si quieres ser un Product Owner excelente aprende Product Management” se publicó primero en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

2 comentarios

Hacer que una misma persona desempeñe las funciones de Product Manager y Product Owner puede ser una opción válida si las circunstancias nos obligan, pero entraña un gran riesgo de fallo. Si es posible, lo mejor es dedicar recursos exclusivos para ambas funciones, que trabajen en estrecha colaboración.

Tanto el rol de Product Manager como el de Product Owner son funciones muy exigentes, que demandan una dedicación exclusiva. A eso se añaden las diferencias de foco, relación, etc. de ambos roles, que exigen perfiles muy diferentes:

  • El rol de Product Management tiene un foco más estratégico y centrado en el negocio y el mercado (éxito del producto), está más volcado hacia el exterior de la empresa y hacia los departamentos internos que deben colaborar para alcanzar ese éxito y su interacción con los clientes gira alrededor de sus necesidades presentes y futuras.
  • El rol de Product Owner tiene un foco más táctico y técnico, está más volcado hacia el interior de la empresa (equipo de implementación) y su interacción con los clientes se centra en las features a entregarles de manera inmediata.

Sin embargo, las circunstancias mandan y a veces resulta imposible cubrir ambas funciones con puestos (y personas) dedicados en exclusiva a cada una de ellas. En las empresas reales es muy habitual que un Product Manager deba asumir también el rol de Product Owner y viceversa.

Product Manager and Product Owner

¿Puede un Product Manager asumir el rol de Product Owner?

Mi opinión es que un Product Manager experimentado puede asumir también con garantías la función de Product Owner en un producto de una complejidad moderada. Sin embargo, también puede ocurrir que ese Product Manager fracase a la hora de sacar todo el partido de Agile y entre en alguno de los siguientes “modos de fallo”.

Dónde puede fallar un Product Manager que asume también funciones de Product Owner

Los problemas suelen venir cuando el Product Manager carece del tiempo, los recursos o la experiencia para desarrollar ambas funciones y acaba dando prioridad a una de ellas, que suele ser la suya original como Jefe de Producto. Como consecuencia:

  • Tiene una integración “a tiempo parcial” con el equipo técnico y nunca llega a sacar partido de la capacidad de éste para cambiar de dirección.
  • Prefiere enfocarse en los aspectos más globales -descuidando las labores del día a día del Product Owner- y acaba obligando a Ingeniería a asignar sus propios Product Owners… que tienen que adivinar lo que quiere ese Product Manager remoto.
  • Ocasiona que historias de usuario y pruebas de aceptación adolezcan de falta de detalle y actualización.

Eso se traduce en una insuficiente presencia de la voz del mercado durante la construcción del producto y, como consecuencia, en la implementación de features que no son aceptadas, reelaboraciones costosas, frustración en el equipo e incapacidad para entregar valor para el cliente.

¿Puede un Product Owner asumir el rol de Product Manager?

La realidad nos muestra que incluso un Product Owner experimentado tiene dificultades para asumir todas las funciones de Product Manager. Ello se debe a que las actividades más estratégicas y de relación con el mercado, la visión de negocio y la coordinación con los departamentos no técnicos de la empresa no figuran entre sus habilidades y experiencia.

Dónde puede fallar un Product Owner que asume también funciones de Product Manager

Aunque los veremos con más detalle en otro post, estos son los modos de fallo más habituales:

  • Foco en entregar features, no en la estrategia de producto a largo plazo: visión, roadmap.
  • Asunción de que los clientes que participan en las revisiones de producto representan al conjunto del mercado.
  • Desconocimiento de aquellas facetas del producto que condicionan su éxito en el mercado: precios, packaging/bundling, ofertas complementarias, valor para el cliente, diferenciadores competitivos.
  • Desconexión respecto a los departamentos internos (Marketing, Ventas, Dirección…) que deben colaborar para convertir el producto en un negocio.

La consecuencia de todo ello es un equipo de desarrollo muy productivo… pero que entrega un producto que no responde a un target claro, se lanza en el momento equivocado, con un precio inadecuado, con unos departamentos de Comercial y Soporte insuficientemente habilitados y, consecuentemente, incapaz de alcanzar su mercado objetivo y de aportar el beneficio esperado.

Si es posible, separar las funciones de Product Manager y Product Owner

En empresas de producto que aplican metodologías ágiles de implementación basadas en Scrum, las figuras del Product Manager y Product Owner (cada una con su alcance y funciones) son imprescindibles. Pero para desarrollarlas con el grado de profundidad y dedicación que requieren y evitar los modos de fallo enumerados anteriormente es conveniente que cada una esté desarrollada por personas especializadas y con dedicación completa:

  • Product Manager – el «CEO del producto», enfocado en los aspectos de negocio y en el mercado desde una perspectiva estratégica, encargado de “construir las features correctas” para crear y comercializar un producto que tenga éxito en el mercado.
  • Product Owner – integrado en el equipo de ingeniería ágil, enfocado en proporcionar funcionalidad a los clientes, encargado de “construir correctamente (y rápidamente) las features.

La ingeniería ágil puede mejorar la calidad y la flexibilidad en la construcción de nuestros productos. Y un enfoque ágil aplicado a toda la gestión de producto -y en general al conjunto de las funciones de la empresa- puede conseguir que seamos más adaptables, centrados en el mercado y rápidos. Pero eso no se consigue optando por la figura del Product Owner en lugar del Product Manager (o viceversa), sino desarrollando ambas funciones de la manera más coordinada y eficaz posible.

El post “Agile: ¿necesitamos Product Managers, Product Owners o ambos? (2)” se publicó primero en “Marketing & Innovación”.

[Una buena función de «product management» es imprescindible para gestionar cada producto como un negocio. Descubra en este taller práctico cómo implementar una gestión de productos realmente enfocada en el mercado.]

7 comentarios

Entre el Product Manager y el nuevo Product Owner de Agile existe un cierto solapamiento que hace que muchos se pregunten si son necesarios los dos. Pero en realidad el problema no es de personas o de puestos, sino de cuál es la mejor manera de desempeñar ambas funciones.

Algunas metodologías de Agile introducen un nuevo rol relacionado con la gestión de «producto»: el Product Owner. Su principal responsabilidad es representar al negocio ante el equipo de implementación, actuando como la voz del cliente, gestionando el backlog y priorizando historias de usuario. La función de Product Owner, originalmente muy táctica y ligada al equipo de proyecto, es una exigencia de las metodologías basadas en Scrum.

Por otra parte, en empresas orientadas a productos para un mercado (no proyectos a medida de un cliente) es imprescindible una figura que gestione el producto como un negocio a lo largo de todo su ciclo de vida, desde la concepción y construcción a su explotación comercial y ulterior retirada: ese es el rol que se suele conocer como Product Manager.

Equilibrio Product Manager Product Owner

Así definidos, los papeles de Product Manager y Product Owner son muy diferentes, aunque tienen zonas comunes. Sin embargo, en empresas de producto se está produciendo una tendencia del Product Owner a abarcar actividades más estratégicas -que tradicionalmente forman parte de la responsabilidad del Product Manager- y es habitual que surja la controversia ¿es necesario dotarse de uno u otro, de los dos… o basta con una persona para desempeñar ambas funciones?

Para poner las cosas en contexto, recordemos algo: aunque las ventajas de Agile son indudables, simplemente adoptar una metodología de implementación ágil no es la solución al desarrollo de productos. Agile ayuda a entregar algo antes y bien, pero sin un conocimiento del mercado, una visión y un diseño aquello que se entrega puede que realmente no nos ayude a vender más productos. Sin la función de Product Manager en un entorno ágil corremos el riesgo de construir el producto equivocado. Podríamos terminar deleitando al cliente que ha participado en nuestro proceso ágil, pero no siendo capaces de vender al producto a nadie más.

En realidad, aunque todas las empresas de producto necesitan Product Managers, no todas necesitan Product Owners. Antes de empezar a analizar el problema vale la pena recordar que hay varios contextos donde esta polémica no existe:

  • En empresas de producto para un mercado que no aplican Agile la figura del Product Owner no es estrictamente imprescindible. Si las necesidades de gestión de producto lo requieren es habitual crear el rol de Technical Product Manager encargado de la coordinación con el equipo de Tecnología y de suministrarle el input del mercado.
  • En empresas de proyectos a medida de clientes singulares -no de productos repetibles para un mercado- en general no se necesitan Product Managers. Si para esa gestión de proyectos se aplica alguna metodología basada en Scrum, el Product Owner sí es obligatorio.

Para el resto de casos –empresas de producto que aplican metodologías ágiles– la primera tentación es “aplicar el manual” de descripción de los roles y dar una respuesta obvia: si el Product Manager es responsable de gestionar su producto como un negocio durante todo su ciclo de vida y el Product Owner es el representante del negocio ante el equipo de implementación, entonces el Product Owner es el representante del Product Manager ante el equipo de implementación (lo cual no deja de ser una buena referencia).

Los nombres de los puestos importan menos que las funciones y las actividades

Sin embargo, esta respuesta tiene una carencia fundamental: asume que Product Manager y Product Owner son puestos o personas, cuando en realidad son roles o funciones. El “conflicto” entre Product Manager y Product Owner en empresas de producto no consiste tanto en decidir qué puestos crear como en asegurar que ambas funciones se realizan de la manera más armónica y eficaz.

Y la manera óptima de implementar y orquestar las funciones de Product Manager y Product Owner depende de muchos factores, entre ellos:

La fase en el ciclo de vida en la que se encuentra el producto. Veamos por ejemplo lo que ocurre al principio y al final del ciclo:

  • Cuando el producto está en desarrollo, la intensidad necesaria en las funciones de Product Manager y Product Owner hacen que sea conveniente cubrirlas con sendas personas con dedicación completa.
  • Cuando el producto pasa a la etapa de evolución/mantenimiento las exigencias son menores y puede ser suficiente con que una misma persona desempeñe ambas funciones.

La estructura organizativa de la empresa. Veamos un par de ejemplos extremos:

  • En la típica start-up formada por “dos amigos en un garaje” es muy habitual que uno de ellos asuma las funciones más relacionadas con el exterior (mercado, socios, inversores) y el otro las funciones más internas (ingeniería, tecnología). Eso se traduce en que el primero desempeña el papel de CEO + Product Manager + Product Owner y el segundo el de CTO + Jefe de Proyecto (Scrum Master).
  • En una empresa multiproducto con productos complejos (cuya construcción puede involucrar a varios equipos dispersos) lo habitual es que por cada producto exista un Product Manager que se ocupa de las actividades más estratégicas y de relación con el mercado, y que interactúa con varios Product Owners (uno por cada equipo de implementación).

Dependiendo del escenario, hay casos en los que un Product Manager asume la función de Product Owner, un Product Owner asume la función de Product Manager o ambas funciones son desempeñadas por diferentes personas… casos de los que hablaremos en la segunda parte de este post.

El post “Agile: ¿necesitamos Product Managers, Product Owners o ambos? (1)” se publicó primero en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

9 comentarios

Cuando se aplica Agile a la construcción de productos el Product Manager debe velar por que el trabajo más estratégico y relacionado con el mercado se siga realizando y por que las features que se entregan, además de implementadas correctamente, son las correctas para que el producto tenga éxito.

Como vimos en la primera parte de este post, la aplicación de metodologías Agile en el departamento de Ingeniería exige que los Product Managers interactúen con sus equipos de desarrollo y sus clientes más a menudo y con una mayor intensidad. En esta segunda parte seguimos hablando de la gestión de producto en un mundo Agile.

Expandiendo los límites de Agile

Como hemos dicho varias veces por aquí, Agile puede ser muy beneficioso (soy un convencido) pero no es la panacea ni una solución completa para gestionar toda la vida de un producto como un negocio. En empresas orientadas a productos para un mercado el Product Manager debe compensar algunas de las carencias que Agile sufre debido a su alcance y a sus orígenes en el campo de proyectos a medida. Pero además (y esto es más frecuente de lo que sería deseable) el Jefe de Producto debe contrarrestar algunos efectos laterales que una “implementación de manual” de Agile puede provocar. Aunque ya hablamos de este tema en otro post, resumimos aquí los principales problemas a evitar:

Product Manager strategic vision

  • Escaso conocimiento y caracterización del mercado y los clientes. A diferencia de los proyectos a medida de un cliente, el problema que debe resolver un producto no es conocido a priori. Antes que nada es necesario construir un mapa que muestre quiénes son los clientes y cuáles son sus problemas/necesidades. Además hay que conseguir que los clientes que participan en las validaciones de los sprints sean realmente representativos del mercado.
  • Insuficiente conceptualización y diseño inicial del producto. La urgencia por implementar y validar tiende a minimizar las actividades de definición y diseño. Y conjugar un diseño holístico con una implementación incremental puede resultar muy complicado. Por otra parte, la iteración y la validación con los clientes debe empezar durante esas actividades iniciales, y no postergarse hasta la construcción del producto. El diseño ágil de experiencias de usuario ayuda a combinar estos dos mundos.
  • Excesivo foco en el corto plazo en detrimento de los aspectos más estratégicos (visión, roadmap, arquitectura, portfolio de productos). El ritmo de entregas puede relegar el enfoque más estratégico a un segundo plano. Resulta difícil ser estratégico cuando se está sometido a las demandas constantes del corto plazo.

En definitiva, el Product Manager debe velar por que las actividades de la gestión de producto más estratégicas y relacionadas con el mercado se realicen.

¿Pero los buenos Product Managers no han sido siempre ágiles?

A pesar de que algunos Jefes de Producto sufren dificultades en la transición a Agile, gente como Saeed Khan sostiene en tono jocoso que los buenos Product Managers siempre han sido ágiles. (O, al menos, lo han sido desde mucho antes que se redactaran los principios del Agile Manifesto.) Desde siempre -y forzados por las circunstancias del puesto y las demandas del mercado- a los Jefes de Producto competentes no les ha quedado más remedio que dar prioridad a

  • Individuos e interacciones, antes que procesos y herramientas. Después de todo ¿los buenos Jefes de Producto no están siempre en contacto directo con su mercado y con los otros departamentos de la empresa?
  • Productos que funcionen, antes que documentación exhaustiva. Y es que ¿quién puede estar más interesado en que un producto funcione, sino la persona encargada de su éxito en el mercado?
  • Colaborar con los clientes, antes que negociar contratos. Y es que la principal prioridad de alguien que se define como el “mensajero del mercado” es interactuar y obtener insights de los clientes mediante entrevistas, visitas, encuestas, revisiones de producto, programas beta, etc.
  • Responder ante cambios, antes que seguir un plan. Los mercados (necesidades de clientes, ofertas competitivas…) cambian y el buen Product Manager reajusta las prioridades a la vista de las nuevas evidencias y datos.

El de Product Manager siempre ha sido uno de los puestos más “ágiles“ de una organización (no le ha quedado más remedio) aunque en general hay que admitir que muchos Jefes de Producto -y no sólo ellos- se beneficiarían de una mayor agilización de sus actividades. Hablaremos de ello en un próximo post.

Implementar las features correctas, antes que implementar features correctamente

Agile exige más a los Product Managers (según algunos expertos, hasta un 30-50% más de dedicación). Una de las grandes controversias en empresas de producto que adoptan alguna forma de Agile es si el rol de Product Manager debe ser desempeñado por la misma persona que el de Product Owner, o si deben ser personas diferentes pero con una estrecha colaboración entre ambas. Si se opta por la primera opción, esa persona debe conjugar los focos -eminentemente externo e interno, respectivamente- de una y otra función. (En empresas de proyectos a medida no hay lugar a este conflicto porque esencialmente no se necesitan Product Managers.)

En cualquier caso, ese tiempo dedicado a los equipos internos puede significar menos tiempo fuera de la oficina, en el mercado. Pero no se puede llegar a entender un mercado si no se sale del despacho. Y ese es el principal dilema del Product Manager en unas empresas de producto cada vez más Agile.

Agile ayuda a entregar de unas features & functions implementadas rápida y correctamente. Pero es responsabilidad del Product Manager garantizar que esas features & functions, además, son las correctas desde una perspectiva de mercado.

En otro post analizaremos que procesos y artefactos debe aplicar un Product Management más Agile/Lean.

El post “Product Management en un mundo Agile (2)” se publicó primero en “Marketing & Innovación”.

[Una buena función de «product management» es imprescindible para gestionar cada producto como un negocio. Descubra en este taller práctico cómo implementar una gestión de productos realmente enfocada en el mercado.]

2 comentarios
A %d blogueros les gusta esto: