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

Posts from the ‘desarrollo ágil’ category

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.]

Anuncios
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 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 -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

Las empresas de producto están adoptando masivamente metodologías Agile. Eso presenta para los Product Managers nuevas oportunidades -pero también dificultades- y redefine muchos de los procesos y artefactos de la gestión de producto.

[NOTA: Este post trata del impacto sobre los Jefes de Producto de la adopción de filosofías Agile en el departamento de Ingeniería, no de cómo hacer un Product Management más Agile/Lean, que será objeto de otra entrada.]

Agile, por su iteración, su cadencia y la involucración de los clientes impone nuevas exigencias a los Product Managers. En este blog hemos hablado repetidamente de ambos temas (ver aquí y aquí). Veamos ahora cómo se influyen mutuamente.

Incluso con Agile, las empresas de producto necesitan Product Managers

Como hemos dicho por aqui repetidamente, las empresas de producto necesitan Product Managers, y las que aplican Agile no son una excepción. En realidad, deberíamos decir que necesitan de alguien que desempeñe la función de Product Management: alguien que sea el “CEO del producto” (aunque esa función, dependiendo del tipo de empresa, pueda ser desempeñada por uno o varios Product Manager… o el propio CEO). Porque nada bueno cabe esperar si esa responsabilidad, en vez de a una persona, se la damos a un comité.

Esencialmente, Agile no cambia el alcance de las responsabilidades del Product Manager (debe seguir gestionando su producto como un negocio y ser el “mensajero del mercado”) pero la manera de desempeñarlas debe adaptarse a un entorno -en lo que a construcción del producto se refiere- caracterizado por una cadencia más rápida, un enfoque más iterativo y flexible y una interacción más intensa con el mercado y el equipo de proyecto.

Product manager en empresa ágil

Cadencia, iteración, interacción

En Agile, los Jefes de Producto interactúan con sus equipos de desarrollo y sus clientes más a menudo -y con una mayor intensidad- que con las metodologías más lineales: participan en reuniones de releases y sprints, incorporan antes a los clientes para las revisiones de producto y reelaboran el backlog para adaptarlo a cambios en las necesidades del mercado. En algunas situaciones el Product Manager debe asumir también las funciones del Product Owner.

Los documentos tradicionales de la gestión de productos (Requisitos de Mercado, Especificaciones de Producto…) se desagregan y se sustituyen por otros artefactos más sencillos, relevantes y adaptados al ciclo de Agile: visión, roadmaps, prototipos, épicas, historias de usuario, backlogs actualizados…  De hecho, tal vez la responsabilidad principal del Jefe de Producto para con el equipo técnico sea aportar prototipos e historias de usuario útiles y usables sobre las que los ingenieros puedan construir. Estos nuevos artefactos contienen los ingredientes esenciales de nuestros antiguos documentos (y algunos más), pero transformados para ofrecer una mayor claridad, adaptabilidad y alineamiento con el equipo.

Cuando la construcción del producto se hace ágil se requiere del Jefe de Producto una mayor involucración en actividades internas, de nivel táctico y contenido técnico. Un criterio enormemente importante del trabajo del Product Manager en entornos Agile es no dejarse absorber por su foco táctico y orientado al proyecto de construcción del producto.

La mayor parte del trabajo de generación de ingresos de un producto no la realiza el equipo técnico

El desarrollo de nuevos productos es un área vital en la gestión de productos, pero no la única: la comercialización y el alineamiento con el resto de productos de la empresa son también aspectos primordiales. Y ese desarrollo de nuevos productos es mucho más amplio que su construcción o implementación: hay que descubrir y analizar la oportunidad de mercado, definir el producto…  Algunos han escrito que si afirmas que usas Agile como tu proceso de gestión de producto es como si dijeras que probar los platos mientras cocinas es tu proceso para ser un chef. Agile no es un marco para Product Management.

Si bien los ingenieros podemos tener a veces una percepción diferente, la realidad es que la mayor parte del trabajo necesario para que un producto tenga éxito en el mercado se desarrolla fuera del departamento de Tecnología /Ingeniería (aunque, deseablemente, en estrecha colaboración con éste):

  • Antes de la construcción del producto: descubrimiento de problemas de mercado, análisis y cuantificación de la oportunidad de mercado, definición de segmentos (necesidades, personas, escenarios) e identificación de los más interesantes, elaboración de concepto, visión y roadmap del producto, diseños iniciales.
  • Durante la construcción: iteraciones de diseño, incorporación de los segmentos importantes del mercado en la validación del producto, empaquetamiento de la funcionalidad en productos y módulos, estrategia de precios.
  • Después de la construcción del producto: elaboración de mensajes, generación de contenidos y habilitación de equipos de marketing y ventas para que puedan comercializar el producto, participación en programas, campañas y oportunidades comerciales, gestión de alianzas, supervisión y medida del éxito del producto en el mercado.
  • En paralelo con todo el proceso (especialmente en empresas con una cartera de varios productos en distintas fases de su ciclo de vida): estrategias de producto, gestión de una cartera sinérgica, previsiones financieras, comunicación y coordinación con otros involucrados internos (dirección, marketing, ventas, ingeniería).

En definitiva, Agile exige más a los Product Managers pero no constituye un proceso de gestión de producto. En la segunda parte de este post seguiremos hablando de las interacciones entre Product Management y Agile.

El post “Product Management en un mundo Agile (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.]

5 comentarios

La imparable adopción de filosofías Agile en el desarrollo de productos viene suscitando una cierta polémica sobre el papel del Product Owner y su intersección (en algunos casos, colisión) con el del Product Manager.

En este post introductorio no pretendo hacer una descripción detallada de la función del Product Owner (no soy un experto y podéis encontrar miles de mejores referencias), sino centrarme en algunas de sus peculiaridades en empresas orientadas a producto y en la evolución que está experimentando para adaptarse a estos entornos.

Pero antes de empezar tal vez convenga recordar un par de características de Agile que influyen en este tema (y que hemos tratado anteriormente aquí y aquí). Aunque originalmente las metodologías Agile provienen del campo de los proyectos a medida de un cliente, es en los últimos años cuando se han incorporado al desarrollo de productos repetibles para un mercado. Sin embargo, por su propia naturaleza, Agile se aplica principalmente a las actividades de construcción / implementación del producto, es decir, entra en juego cuando se ha analizado la oportunidad de mercado y se ha decidido que se va a construir “algo” (la “unidad 0” de un producto replicable).

Product Owner y gestión de proyectos

El rol o función de Product Owner proviene de Scrum, una metodología Agile de gestión de proyectos en la que el equipo colabora unido e integrando continuamente el feedback del cliente a través de un proceso iterativo dividido en sprints.

En sus orígenes, el Product Owner de Scrum era un rol táctico, orientado al proyecto e integrado en el equipo técnico que lo ejecuta. Su misión era representar al “negocio” en el proyecto y asegurar que las decisiones de implementación estaban alineadas con las necesidades del cliente y que cualquier problema o duda se resolvía lo antes posible. Para ello actúa como interfaz entre el cliente y el equipo técnico, recabando el feedback del primero al final de cada sprint y adaptándose a los cambios en sus necesidades.

El Product Owner está en contacto permanente con equipo de proyecto (jefe y desarrolladores) gestionando el backlog de la release, elaborando y priorizando historias de usuario, expandiendo especificaciones y tomando decisiones inmediatas sobre funcionalidad y prioridades. Originalmente, en escenarios de proyectos a medida, era incluso habitual que el propio Product Owner fuera un miembro de la organización cliente. En estas circunstancias el Product Owner era literalmente el dueño del “producto” (entendido éste como el resultado del proyecto).

Product Owner y construcción de productos

La gestión de productos replicables para un mercado difiere de la gestión de un proyecto para un cliente en muchos aspectos fundamentales. Empezando por el hecho de que en el escenario de producto repetible no hay un cliente predefinido, sino una mezcla de clientes más o menos heterogéneos y desconocidos (y que en el mejor de los casos podremos segmentar y representar mediante uno o varios arquetipos significativos de clientes). Por eso uno de los primeros pasos en el desarrollo de un producto es acotar el espacio de problemas de mercado y definir el problema a resolver.

Como consecuencia, resulta prácticamente imposible que el Product Owner sea una persona proveniente de la (o, mejor, una) organización cliente: tiene que tratarse de un miembro de la empresa desarrolladora, encargado de representar al mercado en las actividades de construcción del producto. Unas actividades que se enmarcan en un ciclo de vida de producto mucho más amplio y que abarca desde el análisis de la oportunidad de mercado hasta la comercialización del producto.

Aplicado al desarrollo de productos para un mercado, el rol del Product Owner es muy exigente: antes de planificar los sprints, debe escribir historias de usuario y colaborar con el equipo de testing para definir los criterios de aceptación. Durante la planificación de los sprints debe explicar al equipo de implementación las historias sobre las que van a trabajar a lo largo de las siguientes semanas. Durante el sprint (típicamente 1-4 semanas) supervisa el avance, toma decisiones sobre alternativas de implementación,  responde a preguntas, valida las historias terminadas y prepara las historias para el siguiente sprint.

Del Product Owner se espera que esté disponible para el equipo cuando aparecen dudas y que mantenga actualizado el backlog del producto, reorientando las prioridades en función del feedback de los clientes y otros afectados, unas responsabilidades que exigen una presencia casi continua en la war room. El del Product Owner es un trabajo a jornada completa.

Por poner este rol en el contexto de empresas de producto, podemos compararlo con las funciones típicas del Product Manager. En este post Rich Mironov toma el Framework de Pragmatic Marketing al que nos hemos referido otras veces y superpone las actividades del Product Owner.

Agile Product Manager - Product Owner

Así obtenemos una perspectiva de las funciones del Product Owner y de su intersección con las actividades globales de Product Management: ocupan un área a caballo entre la zona estratégica y la táctica y muy centrada en el hemisferio más “técnico” del plano. De hecho, el alcance del rol de Product Owner guarda un gran paralelismo con el del clásico Technical Product Manager, si bien algunas de las actividades que desempeñan, la cadencia con que las realizan (y, desde luego, el nombre que les dan ;- ) son muy diferentes.

Y en este contexto el nombre de Product Owner es menos afortunado: en general sigue estando más enfocado en el proyecto de construcción que en el resto de la vida del producto y la propiedad que ejerce no abarca mucho más que el backlog y las historias.

El Product Owner ideal… y el real

En aquellas empresas que aplicaron un Agile “de manual” al desarrollo de productos (lo que en muchos casos significa la exclusión de la figura del Product Manager) pronto se descubrió que el alcance original del Product Owner era insuficiente para asegurar el éxito del producto en el mercado. Como consecuencia, los defensores de Agile han ido reclamando para el Product Owner la responsabilidad sobre un rango más amplio de funciones que van desde la visión y el roadmap de producto hasta la asignación de recursos.

Se ha pretendido evolucionar hacia un Product Owner ideal (una especie de “Súper Product Owner”) más estratégico y centrado en el negocio, aunque ello ha llevado a una cierta explosión de sus atribuciones… y a una tendencia sospechosa a solaparse con el papel tradicional del Product Manager. En general, esta definición del papel del Product Owner responde a una concepción de la gestión de producto desde la óptica del departamento de Tecnología, que inevitablemente resulta incompleta (y, en ocasiones, sesgada).

Además, en la realidad el puesto de Product Owner es habitualmente cubierto con personal del departamento de Tecnología/Ingeniería con escasos conocimientos del mercado (clientes, competidores) y de otras áreas y funciones de la empresa. Y eso limita su capacidad para realizar eficazmente las tareas de interacción externa e interna necesarias para garantizar el éxito del producto.

Algunos autores y consultores que promueven este nuevo papel del Product Owner llegan a sostener que hasta ahora no había en las empresas una única persona responsable de cada producto y que el Product Owner viene a suplir esa carencia (y si queréis saber cómo, no tenéis más que leer su libro o cursar uno de sus seminarios ;- ). Pero como ya sabemos, la realidad es que en cualquier empresa de producto razonablemente gestionada ya existe esa figura de “CEO del producto” y que atiende al nombre de Product Manager.

Por eso hace unos años se suscitó la polémica de si las empresas de producto comercial necesitaban únicamente Product Managers o Product Owners (o los dos) y si ambas funciones podían ser desempeñadas por la misma persona, aspectos estos que iremos cubriendo en próximas entradas.

El post “Agile y el papel del Product Owner en empresas de producto” 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.]

11 comentarios
A %d blogueros les gusta esto: