Cómo integrar estrategia, diseño de producto y analítica en agile.

Los usuarios de Internet son cada vez más exigentes y la oferta de servicios en la red es cada vez mayor. En este escenario es muy difícil diferenciarse entre tanta competencia y el concepto de fidelidad a una marca está desapareciendo. De hecho, si no los cuidamos, los usuarios no dudarán en cambiarnos si encuentran algo mejor.

¿Cómo se define la estrategia de producto en este nuevo entorno digital?

El objetivo ya no pasa por tener más funcionalidades que la competencia, sino una oferta más ajustada y diferencial. Por eso, en lugar de pensar en un producto con el mayor número de funcionalidades posible, lo ideal es quedarnos con el mínimo necesario para que el producto tenga sentido. Con esta versión reducida, que se suele llamar MVP (Minimum Viable Product), es con la que debemos salir al mercado lo más pronto que podamos.

A partir de ahí, no debemos añadir funcionalidades en base solo a nuestra intuición y expertise, como se ha hecho tradicionalmente, sino en base a la respuesta de los clientes a este MVP: funcionalidades más usadas, demandas de los usuarios, problemas generados en el call center, etc.

Es por eso que la analítica (tanto cuantitativa como cualitativa), apoyada en herramientas específicas y técnicas como los Test A/B o los MVT (Multi Variable Test), juegan un papel primordial dentro este proceso de cualificación de cada funcionalidad, ya que es la única forma veraz y objetiva de conocer si una idea de negocio funciona o no en el mercado, además de poder analizar el comportamiento del usuario en sus interacciones con esta idea.

Esto cambia radicalmente la forma de construir proyectos en Internet, que han dejado de ser algo cerrado, con un principio y un fin, para pasar a ser algo vivo que se va mejorando en ciclos iterativos. Esta idea, que ya está comúnmente aceptada en el ámbito del desarrollo del software, incluso en las empresas más tradicionales, no está tan extendida si hablamos de estrategia de producto, donde muchos siguen estancados pensando que, aunque la construcción deba hacerse en ciclos iterativos, el diseño estratégico e incluso el diseño de interacción deben hacerse completos (o casi) antes de empezar el desarrollo.

Alexander Osterwalder (autor del Business Model Canvas) da un paso más en esta idea en 2010, añadiendo que también es aplicable al diseño estratégico en un ámbito más amplio de negocio: “Una vez comprendido cómo funcionan los modelos de negocio en Internet, entenderemos que se pueden prototipar de la misma forma que se hacen prototipos de productos”. Es decir, que en el mundo digital, debemos abordar no solo la construcción, sino también la estrategia, en ciclos iterativos.

¿Cómo encaja todo esto en Scrum?

Scrum es el método de trabajo más extendido para el desarrollo de proyectos en Internet. Pero en mi experiencia he visto que es muy común aplicarlo de forma incorrecta, perdiendo el foco en reuniones, estimaciones, planificaciones… y olvidando que el principal objetivo, según la Scrum Guide, es maximizar el valor.

Así que el integrar la estrategia de producto y la analítica, lejos de cambiar nada en Scrum, solo viene a dar solución a dos errores que se comenten en la inmensa mayoría de los proyectos:

• Cada ítem del Product Backlog debe tener asociado un valor de negocio, el valor que añade esta funcionalidad a tu producto, preferiblemente en euros. Lógicamente es un valor orientativo y difícil de calcular de forma individualizada por cada funcionalidad, pero fundamental junto a la estimación del coste a la hora de priorizar cuál es la siguiente funcionalidad a abordar.
• Es común convertir la Sprint Review en una mal llamada “demo” y olvidar una de las partes fundamentales de esta reunión, como me recordaba esta semana mi compañera Ana: “Elegir qué es lo que vamos a hacer en el siguiente sprint en función de la aceptación en el mercado de las funcionalidades que ya han sido entregadas”.

Par empezar a integrar el diseño estratégico dentro de Scrum, lo primero que tenemos que pensar es que los perfiles de consultoría tradicional no nos sirven.

Simplificando un poco, se necesitan principalmente dos perfiles en el equipo, que escasean en las empresas tradicionales, y que rara vez he visto dentro de un equipo agile:

• El primero es un consultor de estrategia digital, uno sin corbata. Tiene que ser un perfil “de Internet” muy alejado de la imagen de un consultor tradicional que hace entregables al peso en base a copy&paste con gráficos de Gartner. Necesitamos un perfil que trabaje en equipo, experto en moderar dinámicas de co-creación tratando siempre de explotar las ventajas competitivas que aportan las últimas tendencias tecnológicas. Su aportación está muy cerca de algunas tareas que realizan comúnmente consultores de experiencia de usuario, por lo que algunos de ellos pueden provenir de esa disciplina pero poniendo en este caso un mayor foco en negocio.
• El segundo perfil es un analista de marketing digital, que conozca bien las herramientas de analítica, además de los diferentes canales digitales: apps móviles, redes sociales, etc. Debe tener la capacidad de definir los KPI’s del producto, así como los indicadores intermedios a medir, para después sacar conclusiones útiles y mejoras en base a la interpretación de estas métricas.

En los métodos ágiles, el Product Owner es la persona responsable del producto, de él se esperan superpoderes para definir, priorizar, maximizar el valor del equipo de desarrollo, etc.

Pues bien, estos dos perfiles, junto con algún que otro rol específico de experiencia de usuario, complementarían al Product Owner allí donde este nunca llega, para cumplir su principal función: maximizar el valor del producto y el trabajo del equipo.

Me centro únicamente en estos dos perfiles porque son más difíciles de ver integrados en un equipo Scrum y por centrarme solo en los perfiles que atañen a la parte puramente estratégica, aunque obviamente otros muchos aportan su parte.

Fase inicial de “visión”

Si aceptamos que la mejor forma de abordar un producto de Internet es trabajar por ciclos de forma iterativa e incremental, estoy de acuerdo en que la primera iteración debe ser ligeramente diferente al resto.

Nosotros lo llamamos Sprint 0, aunque no guste mucho a los puristas, pero lo llames como lo llames, la realidad es que antes de empezar a construir un producto digital debes tener claras algunas cosas: posicionamiento y estrategia de alto nivel; identidad visual; tecnología a utilizar y un esbozo las funcionalidades diferenciales de tu producto, para que después no se convierta en una mezcla de funcionalidades inconexas y sin sentido. Este primera fase de “visión” debe ser lo más corta posible hasta conseguir estos objetivos.

En esta fase se debe definir la estrategia del producto de una forma muy diferente a una consultoría tradicional, de una forma más práctica y efectiva, con dinámicas de grupo y entregables muy visuales.

Es necesario combinar diferentes dinámicas dependiendo del grado de madurez de la idea: desde la definición de nuevos modelos de negocio, definición de estrategia de producto y definición de la experiencia de cliente.

Es necesario combinar también diferentes perfiles dependiendo de la dinámica, para completar así la visión desde todos los puntos de vista: tecnología, marketing, negocio, experiencia de usuario... Incluso una visión de cliente final al que queremos llegar con nuestro producto.

El experto en estrategia digital y el analista de marketing son los que deben liderar esta fase, junto con un perfil más cercano a UX&UI que se centraría más en la parte visual y aportar la perspectiva “customer centric”.

El primero de ellos definiría el modelo de negocio y la estrategia de producto (el qué), además de moderar las dinámicas. El segundo de ellos, aportaría la visión del ROI (el por qué), definiendo unos KPI’s que justifiquen la necesidad del producto en el mercado y los indicadores para después evaluar si las ideas están funcionando o no como inicialmente se esperaba.

Una vez bien definido el modelo de negocio y la estrategia de producto, esta primera fase termina con lo que en Agile se denomina “Product Backlog”, una la lista priorizada de las funcionalidades del producto que se quiere construir.

Con este Product Backlog debemos pensar no en añadir, como ya comentábamos antes, sino en quitar, para quedarnos con un subconjunto que formará nuestro MVP.

Ciclos de construcción o Sprints

A partir de la lista de funcionalidades de nuestro MVP empiezan los ciclos de construcción, donde los perfiles de estrategia digital y marketing digital no desaparecen, aunque puede que su carga de trabajo disminuya.

Uno de los principios lean más importantes es evitar emplear el tiempo en tareas innecesarias. Es por eso que no se pierde tiempo en definir en detalle todas las funcionalidades del Product Backlog, ya que no sabemos si realmente se llegarán a abordar en algún momento.

Esta definición incremental se hace dentro de cada Sprint en un proceso de “refinement” centrado únicamente en las funcionalidades que se van a construir en el siguiente Sprint. En este refinement, el perfil de estrategia digital se encarga de seguir generando nuevas ideas a probar, que se incluirán como nuevos ítems en un product backlog siempre vivo.

Mientras, el analista de marketing digital definirá unos indicadores a medir asociados a cada ítem del Product Backlog. Estos indicadores se traducirán después principalmente en integraciones con Google Analitycs, que serán abordados por equipo de desarrollo.

Además de avanzar en la definición, este perfil no pierde ojo de las funcionalidades ya entregadas, analizando durante el Sprint los indicadores de las mismas para proponer mejoras e influir en la priorización de las siguientes funcionalidades a abordar.

Todos los ciclos deben ser iguales, de unas 3 semanas, tras las cuales se entrega un incremento funcional que se revisa en la “sprint review”. Independientemente de si el proyecto está ya en producción, se debe incorporar en todas las entregas: calidad, seguridad, etc; además de la implementación de los indicadores correspondientes a cada funcionalidad, como acabamos de comentar.

Será decisión del Product Owner si el producto está o no listo para producción. La única diferencia es si tenemos o no feedback del mercado sobre la entrega, de ahí que el MVP deba lanzarse en el menor tiempo posible.

A continuación, un resumen de los añadidos a Scrum para incorporar el diseño estratégico, junto con las partes ya incluidas dentro del método, pero que habitualmente se suelen omitir:

Alguno podrá preguntarse: ¿incorporar todo esto no hace que el proyecto sea más caro? En primer lugar, seguramente son cosas que ya se estén haciendo fuera de Scrum de una manera aislada y desorganizada, por lo que al integrarlo lo que conseguimos es optimizar y disminuir el coste global.

En segundo lugar, podríamos decir que lo caro sería no incorporarlos e invertir tiempo y dinero en largos desarrollos que después no tienen ningún retorno, o que es mucho más caro no medir nada e intentar competir a ciegas en Internet.

Conclusiones

El agilismo tiene la lacra de haber sido creado inicialmente para desarrollar software, pero tiene unos objetivos y unos principios que son aplicables mucho más allá del software.

Incorporar la estrategia de producto y la analítica en Scrum no es complicado y en ningún caso contradice sus principios, sino que cubre esa parte relacionada con añadir valor, que comúnmente se olvida. No se pueden cumplir bien algunos puntos de Scrum como que cada ítem del Product Backlog tenga un valor de negocio o el repriorizar en función de la aceptación en el mercado, sin incluir esta parte de estrategia y analítica.

Esta integración de Agile y estrategia digital permite d****ar un salto de calidad respecto a la forma de abordar la consultoría estratégica tradicional e incluso cambia la forma de construir nuevos negocios en Internet.

hbspt.cta.load(2189055, '7317a215-fbd1-4cc3-a54d-afee694a88f7', {});