Discovery y ese amigo con el que no consigues quedar

Todos tenemos uno de esos, ¿no?

Os tenéis un gran cariño, cada vez que os juntáis todo son recuerdos, risas y buen rato. Sin embargo, es un dolor intentar quedar. Las agendas no cuadran, nunca es el momento adecuado, se cancela a última hora…

Lo que sucede lo conocemos todos.

No es que no haya tiempo, es que no hay tiempo para eso. No es una cuestión de agenda, sino de prioridades.

Hay algo más descorazonador que un equipo no quiera hacer Discovery: que le interese y, aún así, no salga adelante.

La historia iría de la siguiente manera: Se prioriza un elemento del Outcome Roadmap, con su definición de problema, audiencia objetivo, impacto, etc. Se hace un kickoff dando el contexto y al final de la sesión nadie pregunta nada. Las personas designadas empiezan con el Discovery. Se invita al equipo a diferentes sesiones, pero cuando hay que idear nadie se acuerda de cuál era el objetivo. Se ponen las sesiones de investigación en calendario y es imposible encontrar apuntadores. Se anuncia la sesión de análisis de hipótesis y al resto del equipo le coincide con algo “más importante”.

Es un escenario ficticio, pero una o varias de esas situaciones se pueden encontrar en un equipo que da sus primeros pasos. En realidad, si se observa bien no es un problema de Discovery. Es un problema de Dual Track. De encajar el trabajo nuevo en las cabezas y el día a día del equipo.

¿Qué puede estar sucediendo?

• Falta de visibilidad en calendario

• Desconocimiento del proceso de Discovery

• Desconexión con objetivos y resultados

• Falta de foco y demasiadas responsabilidades

Veamos cómo se pueden atacar.

Falta de visibilidad en calendario

El trabajo invisible es un cáncer. No se puede priorizar, no se puede gestionar, sus dependencias explotan cuando no te lo esperas y suele ser el principal culpable de las horas de más.

Delivery ha hecho un buen trabajo combatiendo este mal. Hay metodologías y disciplinas enteras dedicadas a identificar, evaluar, visualizar y medir cada carga de trabajo del equipo. Echando un vistazo rápido puedes ver qué toca hacer cada dos semanas y qué vendrá después. Las cadencias son repetibles y predecibles. El ritmo es como un baile de salón, un-dos-tres, un-dos-tres.

Discovery lo lleva un poco peor. Los procesos y metodologías aún se están formando. Hay acuerdos generales a alto nivel, pero los detalles se tienen que bajar en cada casa. Y tiene bastante de impredecible. No se puede programar cuándo se habrá encontrado un aprendizaje, cuándo se habrá modelado un sistema, cuándo se habrá validado una hipótesis.

Hay que hacer un esfuerzo consciente para encajonar esa incertidumbre en tiempos que se puedan comunicar. El primer paso es usar el calendario. Dar a las actividades y tomas de decisiones una fecha y un espacio. Especialmente las que involucren a grupos grandes.

Para tener más certeza o acuerdo sobre los tiempos de Discovery se pueden hacer dos cosas: Usar timeboxing, coger un tiempo fijo y dar por bueno lo que se haya conseguido en ese periodo o tener sprints de Discovery con sus actividades previamente identificadas y acordadas por fase (e.g. investigación, análisis, ideación, validación). Después de cada sprint el equipo se reúne y decide si se pasa de fase o se necesitan sprints adicionales. De esta manera no se condicionan los resultados a una fecha fija, pero hay certeza de qué sucederá en las semanas siguientes.

Con eventos en el calendario ya es posible balancear la carga de trabajo de Discovery y Delivery y evitar colisiones. Es el primer paso hacia un Dual Track real.

Desconocimiento del proceso de Discovery

El bajar a tierra el proceso de Discovery aún es fruto de debate y exploración, con ejemplos que van del Shape Up de Ryan Singer al Continuous Discovery de Teresa Torres pasando por diferentes variaciones de Design Sprint.

Estructura de Discovery. Teresa Torres

Discovery está en el corazón de Producto, ya que es el trabajo que se preocupa por responder la pregunta ¿A través de qué valor X puedo causar la reacción Y? Outcomes over Outputs. La mentalidad taylorista extendida en la industria de planificación más construcción hace que no sea fácil que los equipos interioricen las actividades y los objetivos que hay resolver durante Discovery.

Es un cambio de perspectiva muy grande.

En Ingeniería este problema es más visible, pero también menos problemático. En Diseño es más peligroso ya que muchas de las técnicas y el lenguaje usados son los mismos: investigación, ideación, personas, journeys, flujos, prototipos, etc. Sin embargo, el cómo y el por qué se usan pueden responder a maneras clásicas de pensar. Hay muchísimos Product Designer que no pueden estar más alejados de Producto.

¿Cómo conseguir entonces que el equipo haga suyas las técnicas y la mentalidad de Discovery?

Entregándoles el problema a ellos y aplicando la técnica Feynman. Poniendo como objetivo de sprint y que una parte del equipo investigue sobre Discovery y diseñe el proceso a seguir. A continuación que se lo presente y explique al resto del equipo.

Es crucial que sea trabajo visible de sprint, que tengan foco y espacio y que puedan estar arropados desde Producto con material e información.

Conectar el trabajo con el plan y los resultados

El equipo de producto debe ser capaz de responder en cualquier momento a la pregunta: “¿cómo conecta mi trabajo del día a día con el objetivo y estrategia de la organización?”.

Es responsabilidad de la líder de Producto proporcionar esa claridad y esas referencias. Por un lado, es un trabajo constante: repetir día a día las consignas y prioridades del momento, empezar un ejercicio con un repaso general de por qué y para qué, dar a los equipos el contexto de las conversaciones que se hayan tenido en otros círculos, etc.

Sin embargo, ayuda que el equipo tenga una referencia para saber cuál es el aporte particular de su trabajo a la organización. Un Roadmap no ayuda, ya que es un conjunto de iniciativas ordenadas, las acciones para llevar a cabo el plan. La discusión de por qué y para qué se eligen ha sucedido por fuera.

Una manera interesante de abordar el reto es en modo de pinza: de arriba abajo y de abajo arriba. Y una capa de contexto.

De arriba abajo

La idea es poder ver una cascada lógica entre la misión/visión y el sprint de esta semana. La dificultad está en que no haya huecos entre los saltos, que el anterior explique perfectamente el siguiente.

Nosotros en Erudit usamos una versión adaptada del VMOST.

Como decía antes, el reto de está en que cada una de las capas conecte lógicamente con la siguiente. No es el objetivo de este artículo, pero la gran mayoría de los problemas suele estar conectada con la estrategia. O no hay o se confunde con la Propuesta de Valor/Visión o se obvia a través de OKRs.

En este ejercicio Tactics es equivalente al Roadmap.

De abajo arriba

La mejor manera de conectar el trabajo de la gente con resultados reales es a través de la métrica de Producto que resume su valor. El mejor framework que conozco para ello es el North Star de John Cutler, en Amplitude.

No sólo es un ejercicio excelente para tener una visión coherente y completa del Producto. También es un gran vehículo para trabajar la filosofía de Producto con el equipo: impacto antes que producción.

En la imagen anterior se puede ver en azul, conectando por abajo con el Roadmap y por arriba con los objetivos.

Todos estos documentos y artefactos tienen su versión oficial y documentada en otros entornos, pero los conectamos visualmente en el panel.

Capa de contexto

Por mucho que se quiera poner estructura y documentación nada supera la riqueza del debate y el escarbar juntos un tema en concreto.

La decisión sobre qué versión de prototipo se ha elegido, por qué se ha decidido incluir un balance de la audiencia objetivo diferente al anterior sprint o cómo el mirar nuestra data nos ha abierto un camino de actuación que no estaba contemplado. Mucha gente puede sentirse perdida cuando hablan con Discovery y se encuentran ante algo bastante diferente al punto de partida.

Por eso establecer puntos de encuentro programados para dar ese contexto es vital.

Usar Discovery Checkpoints al final de cada semana obliga al equipo de Discovery a organizar y reflexionar sobre lo aprendido y trabajado y da la oportunidad al resto del equipo de ponerse al día y preguntar.

Un espacio más abierto (nosotros lo llamamos Product Café) da la oportunidad de conversar sobre temas más estratégicos, repasar la dirección general del Producto o resolver esas dudas que se quedan en el messy middle.

Falta de foco y demasiadas responsabilidades

Uno de los mayores enemigos de cualquier equipo es un alto WIP (work in progress). Sus efectos son de sobra conocidos: afectando al foco, los cambios de contexto, el trabajo profundo y la capacidad de reacción ante imprevistos.

WIP bajo no es sinónimo de poca carga o vaguear. Significa que hay pocos temas en paralelo. Un equipo que está a demasiadas tareas va a dejar caer bolas al suelo y las invitaciones a actividades de Discovery tienen muchas papeletas.

Si además esta saturación está institucionalizada y ese equipo tiene que conjugar desarrollo de Producto con dar servicio a cliente y con temas de seguridad de plataforma, la situación va a necesitar de una pensada más seria y honesta.

Un WIP alto tiene una gran correlación con la capacidad de establecer prioridades y decidir de manera explícita dejar cosas fuera, responsabilidad del líder de Producto.

---

¿Cuál es tu caso? ¿Estáis todavía intentando introducir el concepto de Discovery?¿Lo tenéis ya fino y engrasado? ¿Cómo fue en tu casa?