Cuando entras en el terreno de inventar soluciones conectadas a la mejora de un aspecto del producto en el que trabajas -a lo que has llegado a través de métricas, apuestas, empatía o una combinación de todo eso- debes primero mirarlas como un conjunto de alternativas y no solo como una posible solución. Se suele hablar, en este sentido, de no enamorarte de tu primera idea, o en general de no enamorarte de tus ideas, para poder analizarlas en su conjunto.
Contemplar las soluciones como un conjunto de alternativas tiene beneficios claros. Para poder habilitar este enfoque hay una serie de prácticas orientadas a articular un proceso de descubrimiento. En esta etapa del programa entramos en el terreno de cómo se suelen concretar las acciones en los equipos de producto, es decir, adoptamos una mirada de proceso.
Empezamos también a trabajar por equipos también para los ejercicios de casa.
Soluciones como conjunto de alternativas
Es muy recomendable no saltar rápido a LA solución. Como siempre, es más fácil decirlo que hacerlo. Hay muchas fuerzas que actúan en contra de esa recomendación. Y te enfrentarás a muchas situaciones en las que LA solución te vendrá ya dada, con un detalle variable. Si te deslizas por ese tobogán, acabarás rápidamente atrapada en la entrega.
Necesitas ordenar la toma de decisiones.
Consiste en entender el desarrollo de producto como una forma de entregar cosas en vez de conseguir progreso en lo que la gente persigue. Es la trampa más habitual y en ella viven de una forma u otra todos los equipos de producto. Esa trampa convierte a los equipos involucrados en desarrollar algo en gestores de proyectos que se tienen que entregar, y por ahí también aparecen problemas de sobre-ingeniería y sobre-diseño con bastante frecuencia.
El remedio más eficaz para no caer en esa trampa es contemplar un conjunto de soluciones alternativas y evaluarlas en función de los indicadores que te resulten más sustantivos: la propia experiencia de los clientes, métricas cuantitativas, objetivos financieros, etc. Tanto esa búsqueda de una multiplicidad de soluciones como el buscar una conexión constante con lo que sucede entre tu producto y las personas que lo utilizan, te conducen a la necesidad de diseñar lo que se suele conocer como una máquina de descubrimiento.
Desarrolla tus propios árboles de oportunidades para no perderte el bosque.
Instrumentar el proceso de descubrimiento
La mejor forma de buscar una alternativa al enfoque centrado en la entrega es diseñar un flujo de toma de decisión tratando de forma distinta a cada uno de los momentos que intervienen. En todos ellos tienen relevancia los aspectos que hemos visto hasta ahora. La búsqueda de evidencia como un ancla para tomar decisiones cruza todos esos momentos.
El primer momento que debes considerar es el que te permite recoger, clasificar, agrupar, priorizar, ponderar, y relacionar señales por parte de las personas que utilizan tu producto. Puedes llegar a estas señales a través de recogida automática de información, pero también a través de relaciones de empatía. En las primeras puedes incorporar métricas cuantitativas, evidencia observable, pero también patrones a través de información consistente. En las segundas es más habitual la evidencia cualitativa y un esfuerzo por descubrir contextos en los que se producen las acciones.
Evita que las personas para las que inventas, sean unas meras sombras en tu caverna.
No todo lo que recoges en el primer momento debe pasar al segundo. Aquí está la primera clave que cualquier proceso de descubrimiento debe incorporar. Necesitas manejar un semáforo que indique cuándo consideras que una señal, o un conjunto de ellas, puede pasar al segundo momento. Tu objetivo es darle importancia a la energía, al foco y al pensamiento que pones en los temas, así como a organizarlo para tu equipo. Por lo tanto, buscas hacer que este proceso sea operativo y que no profundice en aquellas temáticas que todavía no han alcanzado una luz verde.
Por la naturaleza del software si no utilizas un semáforo, multiplicas el riesgo de tu negocio.
Una forma efectiva de sistematizar el paso entre este momento y el siguiente es darte una plantilla con las cuestiones básicas que cualquier conjunto de señales debe responder para considerarse como candidata. Pero recuerda que tienes a tu alcance otros muchos medios, también muy asequibles, para no quedarte atrapada en la mirada hacia dentro, la mirada de la oferta, las cuatro paredes de tu empresa, la falsa sensación de estar haciendo algo simplemente por publicar funcionalidades: conversaciones con clientes, pruebas con personas dentro de tu empresa, sesiones de escucha, lectura de valoraciones, lectura de incidencias en canales de atención al cliente, ejercicios de empatía participando en otras funciones dentro de la empresa, etc.
Monta tu propio proceso de cualificación de decisiones con preguntas que te reten.
El siguiente momento que debes tener en cuenta no es todavía la ejecución inmediata. Tienes que darte un espacio para dedicarle reflexión a las señales que has trabajado y movido a este momento. Reflexionar no significa que tengas que caer en el enfoque de redacción de requisitos y diseño en detalle, para luego esperar que se ejecute. Reflexionar en este momento significa, ante todo, pensar en soluciones alternativas que abran el espacio de lo imaginable. Cuando oigas hablar de cosas como experiment mindset, ten en cuenta que se estarán refiriendo en la mayoría de los casos a lo que sucede en esta etapa, donde buscas apostar por algo que te ayude a reducir la incertidumbre que existe entre aquello que buscas mejorar -conectado a alguna señal- y lo que pones en marcha para conseguirlo. Aquí ya necesitas que se unan más perspectivas (tecnología, atención al cliente, diseño...) para empezar a tener un contraste del alcance.
Te mueves todavía en una proyección de punto gordo. Borrosa.
En el último momento ya nos movemos en el espacio de la construcción. Lleno, también, de numerosas decisiones-sobre-la-marcha que van aportando nitidez al alcance borroso. Veremos en la próxima sesión los retos a los que nos enfrentamos en esa etapa.
El primer beneficio claro de instrumentalizar un flujo de descubrimiento es que no tienes que caer en los dos extremos entre los que se suele mover la práctica de desarrollo de producto. El enfoque tradicional suele desatender los aspectos críticos relacionados con todos los retos que plantea la incertidumbre y el riesgo, que nacen de la naturaleza misma del software. El enfoque que se suele conocer como “ágil” tiende a diluir la capacidad metodológica, reduciendo el enfoque a una entrega constante troceada sin un propósito explícito, y por lo tanto sin herramientas claras para evaluarse. Es fácil que caiga en mera reacción o incluso que acabe siendo una reformulación, por piezas, del enfoque tradicional.
