Una página / Una hora
Sobre por qué es importante acortar los ciclos de feedback en la fase de discovery. Y un modelo mental para hacerlo.
Si habéis seguido mis artículos en esta lista de correo sabréis que, en mi opinión, una de las claves para desarrollar productos de éxito consiste en tener ciclos de feedback lo más cortos posibles. Esto lo conseguimos desarrollando la funcionalidad mínima que, en manos de nuestros usuarios, nos permitirá validar y aprender cuanto antes.
Si estamos de acuerdo en los beneficios de acortar los ciclos de retroalimentación, hoy os traigo una propuesta para hacerlo también durante la fase de conceptualización de un proyecto. Se trata del framework One Page / One Hour de Matt Lemay.
LeMay escribió uno de los libros que más recomiendo a cualquiera que quiera aprender sobre la realidad del día a día de nuestra profesión, Product Management in Practice. Sobre libros hablaré algún día, pero hay que entender que mucho de lo que encontramos escrito sobre la profesión viene de gente cercana a la burbuja de Silicon Valley.
No me entendáis mal, esto está genial para entender cuál debería ser nuestra aspiración, pero puede llevar a engaño si creemos que la realidad fuera del valle es esa. En otras palabras, lo que nos vamos a encontrar en el mundo real se parece más a lo que escribe LeMay que a lo escribe Marty Cagan en Inspired o Empowered.
Volviendo al tema principal de este artículo, fomentar los ciclos de retroalimentación rápidos, el framework de LeMay consiste en no invertir más de una hora y una página en ninguna especificación sin compartirlo con el equipo. El objetivo es el mismo que perseguimos construyendo patinetes. Forzarnos a obtener feedback temprano lo antes posible, pero esta vez de nuestros compañeros en lugar de nuestros usuarios.
A mi juicio, esto tiene dos grandes ventajas:
Evita que nos atemos a una idea
En primer lugar, evita que pasemos mucho tiempo en la cueva diseñando una especificación muy detallada. El problema de esta aproximación es que, cuanto más tiempo invirtamos creándola, más nos va a costar aceptar cualquier cambio sobre la misma una vez la hagamos pública.
En cierto modo sería reconocer que hemos tirado ese tiempo a la basura, por lo que de forma inconsciente vamos a tratar de defender nuestras decisiones aunque pueda haber otras mejores. Comprometerse a no invertir más de una página o una hora sin compartirlo con el equipo evitará que nos pongamos en esa situación.
Nos obliga a involucrar al equipo
Por otra parte, el modelo nos obliga a involucrar al equipo en la fase de ideación de la iniciativa. Siendo sinceros, en una hora y en una página no se puede desarrollar algo con mucho detalle. Cómo mucho nos da para definir a alto nivel el problema a resolver y detallar algunos puntos sobre nuestros objetivos. Esto es para bien.
Es para bien porque como ya sabéis, cuanto más involucremos al equipo al inicio de la iniciativa, más motivado estará cuando finalmente se tenga que poner con ella. Además, ese feedback de ingeniería, de diseño y hasta de QA puede ser extremadamente valioso, pues son las personas que mejor conocen los retos que se esconden tras cada problema que les presentamos.
Hasta aquí las partes positivas. Veamos ahora algunas críticas que se le podrían hacer a la idea.
Críticas al artículo
Una página o una hora, ¿no es muy poco?
Puede ser. Personalmente no lo tomo como una regla estricta, sino como un modelo mental que me recuerda cuando me pongo a escribir una especificación, ésta no debería pasar de ser más que un boceto a comentar con el equipo.
Quizás he pasado 2 días entendiendo el problema, entrevistando a usuarios, buscando dependencias. Pero cuando me siento a escribir lo que quiero compartir con el equipo, intento no pasar demasiado tiempo haciéndolo evitando dar demasiado detalle. Es a partir de esas primeras reuniones iniciales, cuando la iniciativa irá cogiendo forma.
Mi equipo no quiere participar en el discovery
En algunas ocasiones, en empresas con poca cultura de producto o con ingenieros poco motivados, puede ocurrir que el equipo no quiera participar en la fase de conceptualización. Es una situación complicada porque si no logras que participen, las soluciones a las que lleguéis difícilmente serán las mejores.
Idealmente deberías tratar de introducir esta cultura poco a poco, buscando encender la llama del interés en el producto de algún miembro y apaláncandote en el mismo como ejemplo para el resto. Si no sucede, también puedes tratar de atraer talento de otras partes de la organización o incluso de fuera.
En mi experiencia, cuanto mejor es un ingeniero, más interesado está en participar en las soluciones porque quiere asegurarse de que está aprovechando su tiempo aportando valor real. Si se extiende el rumor de que los involucras al inicio de las iniciativas te convertirás en un imán de talento.
Mi empresa no valora esta forma de trabajar
Todos mis artículos van asociados a un determinado contexto, el de empresas de producto. Sin embargo, también hay empresas que no son de producto sino de servicio como las consultoras. También puede ocurrir que la empresa se autodenomine de producto, pero internamente trabaje como una consultora asignando “recursos” a proyectos. De hecho, la palabra “recurso”, que raramente escucharás en una verdadera empresa de producto, es un olor extremadamente fuerte de este tipo de contextos.
En un entorno así, vas a tener francamente difícil poder aplicar este modo de trabajo. De hecho, es incluso hasta difícil encontrar Product Managers en ellas. El rol suele ser sustituido por Analistas o Project Managers que simplemente se encargan de recoger requisitos y vigilar que se implementen sin preocuparse demasiado de si su trabajo tiene valor o será mantenible en el futuro.
Va a ser extremadamente difícil aplicar un mindset de producto en este contexto. Mi consejo sería que trataras de encontrar y posicionarte para aquellos puestos donde más libertad puedas tener para aplicarlo. Si no lo encuentras y eso te frustra, empieza a considerar cambiar de empresa.
Conclusión
En el artículo de hoy nos hemos apoyado en el framework One Page / One Hour de Matt Lemay para explicar algunas ideas básicas sobre el proceso de desarrollo de producto.
Los ciclos de retroalimentación, cuanto más cortos mejor, también en la conceptualización.
Evita atarte a una idea pasando mucho tiempo trabajando en ella sin compartirla con el equipo.
Involucra al equipo lo antes posible en una iniciativa para refinar tus ideas y motivarlos al mismo tiempo.
Referencias
Escucha al autor hablar de One Page / One Hour en este podcast de Mind The Product.
Cómo siempre, muchas gracias por estar ahí. Si te ha gustado el post y crees que le podría interesar a alguien de tu entorno sé libre de reenviarle este correo. También puedes utilizar estos enlaces para compartirlo directamente en Twitter o LinkedIn y así me ayudarás a que esta lista de correo llegue a más gente. ¡Gracias de antemano!