Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta MVP. Mostrar todas las entradas
Mostrando las entradas con la etiqueta MVP. Mostrar todas las entradas

domingo, mayo 28, 2023

Inspirado: como crear productos de tecnología que tus clientes amen

Esta es la presentación de mi charla en el Lean Agile Summit, en Medellín este 27 de mayo de 2023. En ella brindé información sobre las prácticas y, sobre todo, los principios del enfoque exitoso de productos en empresas de tecnología y en otras con las que he trabajado a lo largo de mis 35 años de carrera profesional.

En particular, hablé de las Las causas fundamentales de los esfuerzos fallidos de producto, cómo nos pueden ayudar los enfoques Lean y Ágil en este proceso de Las 4D, descubrir, diseñar, desarrollar y distribuir productos que resuelvan la paradoja de las compañías que quieren tener éxito en el mundo convulsionado de hoy: quieren que sus clientes amen sus productos, pero no sabrán si esto es posible hasta tanto no pongan esos productos en manos de ellos.

También hablé de los principios de Lean Product Discovery y entrega frecuente y de mi tema favorito: personas. Detrás de cada gran producto hay una gran persona y, por extrapolación, un gran equipo. Principios de equipos de producto sólidos, sobre el líder de producto y el papel del liderazgo y, finalmente sobre la cultura sólida de producto que tienen las organizaciones brillantes. Por supuesto, fue tiempo para hablar de las Organizaciones B (Brillantes) y la triple restricción: estas son las empresas que no solo buscan el necesario y “sine qua non” beneficio financiero, sino también el beneficio social y ambiental. No podemos tener empresas sanas y, por consiguiente, productos sanos, en un planeta enfermo. Perentorio.

Al final, de mi libro Cultura ágil: ese oscuro objeto del deseo, mis tres leyes de la cultura:

1.    La ley del cambio

2.    La ley del lenguaje

3.    La ley del liderazgo cultural

No faltaron los consejos sobre cómo trabajar con equipos de diseño e ingeniería.

Fue un momento de compartir con amigos y colegas y un gran público que me acompañó atento durante la sesión. ¡Muchas gracias a todos!

Puedes descargar la presentación aquí: 👇

martes, noviembre 08, 2022

Cómo crear productos disruptivos con Lean Product Discovery

Created with DALL-E, an AI system by OpenAI

Nivel: principiante. Para todo público.

Esta es solo una manera… ¡de muchas!

Los productos disruptivos son aquellos que desafían el statu quo, crean nuevos mercados o cambian por completo una industria. Para crear un producto disruptivo, es importante tener una visión clara, liderazgo y un proceso que permita el descubrimiento ágil de productos, lo que posibilitará una rápida iteración y prueba de nuevas ideas.

La visión: un producto disruptivo necesita una visión sólida que lo guíe. Esta visión debe basarse en las necesidades reales del cliente y no en lo que la empresa quiere construir. Con demasiada frecuencia, las empresas intentan crear productos que creen que tendrán éxito, en lugar de comenzar con lo que quieren los clientes. La mejor manera de comenzar es comprender el problema que estás tratando de resolver y luego descubrir la mejor manera de resolverlo.

El liderazgo: se necesita un fuerte liderazgo para guiar a un equipo hacia la creación de un producto disruptivo. Este liderazgo debe poder mantenerse enfocado en la visión y al mismo tiempo ser lo suficientemente flexible para adaptarse según sea necesario. También debe poder tomar decisiones rápidas y asumir riesgos cuando sea necesario. Los líderes juegan un papel vital en Lean Product Discovery, ya que son responsables de establecer la dirección y guiar al equipo. Sin un liderazgo fuerte, es difícil crear productos disruptivos.

El proceso: el proceso para crear un producto disruptivo debe basarse en principios ágiles. Esto significa que debe iniciar con una pequeña cantidad de funciones o características y luego agregar más a medida que recibe retroalimentación validada de los clientes. También debería poder adaptarse rápidamente a medida que aprende más sobre lo que quieren esos clientes.

Cuando se trata de crear productos exitosos, Lean Product Discovery y los métodos ágiles de desarrollo de producto son clave. Lean Product Discovery se trata de desarrollar una visión sólida del producto y luego experimentar para validar esa visión. Este enfoque ayuda a garantizar que estés aprendiendo y avanzando constantemente, en lugar de atascarte en los detalles.

El desarrollo ágil, por otro lado, se trata de trabajar en ciclos cortos para entregar valor rápidamente. Este enfoque ayuda a garantizar que siempre estés progresando y que tu producto siempre esté evolucionando.

Juntos, estos dos enfoques pueden ayudarte a crear productos disruptivos que sean exitosos y rentables. Entonces, si estás buscando crear la próxima gran primicia en materia de producto, Lean Product Discovery y el desarrollo ágil son el camino a seguir.

Entonces, comencemos con lo básico.

Lean Product Discovery es una técnica que las personas, los equipos y las empresas, independientemente de su tamaño, pueden usar para crear un Producto Mínimo Viable (MVP) eliminando cualquier característica innecesaria y centrándose en las más importantes.

Lean product discovery también se puede llamar Innovación Lean, que es el proceso de encontrar la mejor solución a un problema, sin perder tiempo ni recursos. Incluye prototipos que se centran en el proceso de creación del MVP.

Lean Product Discovery es un proceso que ayuda a las empresas emergentes y a los equipos de productos a descubrir qué necesita el cliente, cómo lo quiere y cómo quiere interactuar con él.

El proceso se puede dividir en cuatro fases, a manera de "camino a seguir": Entender, Idear, Prototipar y Validar. La primera fase consiste en comprender el problema y descubrir qué necesitan los clientes. En este período es importante entender el problema detrás del problema, la causa raíz, cuál es su impacto, a quienes impacta. La segunda fase consiste en una lluvia de ideas para encontrar potenciales soluciones al problema. La tercera fase de este proceso es cuando creas un prototipo de lo que crees que resolverá el problema y luego lo pruebas con su público objetivo. Y finalmente, la cuarta fase consiste en validar si tu solución resuelve o no el problema del cliente realizando una prueba piloto en clientes reales para medir su respuesta.

Si tienes tu propia Startup, primero realiza un chequeo de referencia utilizando enfoques Lean

Esta es una técnica de evaluación utilizada para determinar la idoneidad de un posible socio o proveedor. A menudo lo realiza un gerente, un vendedor o el dueño del negocio. Esta prueba se puede realizar en persona, por teléfono o por correo electrónico.

El proceso varía según el tipo de socio que necesitas evaluar. Por ejemplo, si estás evaluando el procesador de tarjetas de crédito de tu empresa para cumplir con los estándares y regulaciones de la industria (como el cumplimiento de PCI), querrás realizar una entrevista en persona con tu posible proveedor. Si estás evaluando una agencia de publicidad por su destreza creativa y su capacidad para cumplir con los plazos, es posible que desees tener una llamada telefónica con ellos antes de extenderles una oferta.

No te preocupes si no trabajas en una startup. Este enfoque funciona bien en casi todos los escenarios.

Puedes crear una nueva idea de producto con una característica mínima viable

El primer paso para crear una nueva idea de producto es determinar el problema. Esto generalmente se hace buscando respuestas a la pregunta: "¿Qué problema resuelve este producto?" A continuación, debes encontrar una respuesta a la pregunta "¿Cuáles son los beneficios de resolver este problema?"

Más tarde, crea una lista de características que resolverán estos problemas y brindarán beneficios. Luego puedes ordenar esta lista de funciones y elegir cuáles incluir en tu característica mínima viable. Finalmente, debes decidir un nombre para tu idea de producto y preparar un discurso de elevador (elevator pitch) para describirlo.

¡Esto suena simple pero no lo es! La clave aquí es hacerlo iterativamente. Hazlo una y otra vez hasta que encuentres tu voz. La experimentación es clave en el descubrimiento Lean de productos porque te permite validar tus hipótesis, aprender de tus errores y avanzar constantemente. Para experimentar de manera efectiva, debes tener una comprensión clara de tus objetivos. Una vez que hayas establecido esos objetivos, puedes comenzar a diseñar y realizar experimentos. Después de haberlos realizado, es importante analizar los resultados y determinar qué significan para tu producto.

Por ejemplo, puede usar la curva S para evaluar tus ideas.

Puedes evaluar ideas para posibles disrupciones con la curva S

La curva S es una herramienta para comprender el crecimiento de un nuevo producto. Ayuda a evaluar ideas potencialmente disruptivas. La curva S es una representación logarítmica del crecimiento del producto, por lo que no debe usarse como una medida absoluta de éxito.

La primera fase comienza con la introducción del producto, cuando acaba de ser lanzado o introducido al mercado. Esto es seguido por un período inicial de crecimiento lento. La siguiente fase es cuando el producto alcanza su punto máximo y comienza a declinar, lo que puede llevar mucho tiempo dependiendo de qué tan bien se haya diseñado el producto.

Adaptado de https://innospective.net/why-s-curves-are-probably-the-most-important-concept-in-entrepreneurship/

La curva S es una representación gráfica que se utiliza para visualizar el progreso de un producto o una industria a lo largo del tiempo. Se asocia con distintas fases del desarrollo del producto, como la ideación, el desarrollo y la innovación. La curva S ayuda a las organizaciones a comprender dónde se encuentra actualmente su producto o industria y predecir el futuro de esta. La curva S es esencial en el desarrollo Lean de productos, ya que ayuda a tomar decisiones informadas sobre la idea del producto, el momento de la introducción de nuevas características o productos en el mercado, etcétera.

La curva S también es útil para medir el progreso de una industria o un producto frente a sus competidores. Al comprender dónde se ubica un producto o industria en particular en la curva S, las empresas pueden realizar los cambios necesarios en sus estrategias para mantenerse a la vanguardia en la competencia del mercado. La curva S es, por lo tanto, una herramienta valiosa para que las industrias y organizaciones evalúen sus productos y realicen los cambios necesarios en su proceso de desarrollo para garantizar el éxito a largo plazo.

Puedes realizar análisis competitivo y de clientes después de que nazca tu idea

El análisis competitivo es un proceso de comprensión de la competencia en el mercado. Te ayuda a comprender las fortalezas y debilidades de tus competidores y cómo puedes usarlas para tu beneficio. Este tipo de análisis incluye conocer sus precios, ofertas de productos, público objetivo, estrategias de mercadeo, etcétera.

El análisis de clientes es un proceso de entendimiento de quiénes son tus clientes y qué necesitan de ti. Te ayuda a comprender sus puntos débiles y cómo perciben tu producto o servicio.

¿Qué pasa con el Producto Mínimo Viable (MVP)?

El Producto Mínimo Viable, o MVP para abreviar, es un producto con los atributos suficientes para satisfacer las necesidades iniciales de los clientes. A menudo se utiliza como prototipo y campo de pruebas para productos futuros que podrían necesitar más trabajo antes de lanzarse masivamente a un mercado objetivo.

Con el MVP puedes evaluar tu idea sin invertir demasiado tiempo y energía en ella. La hipótesis detrás de este enfoque es que si los primeros clientes disfrutan de lo que ofreces, las características futuras también deberían ser más amigables para la mayoría.

Repasemos esto una vez más. Un MVP es la primera versión de un producto que lanzas al público. Se refiere a la forma más temprana de un producto que aún es viable y proporciona algún valor a los clientes. Es simple y solo incluye las características más esenciales para evaluar tu idea en el mercado. Un MVP también se puede utilizar para identificar posibles problemas con tu idea antes de invertir tiempo y dinero en la creación de un producto completo.

Conclusión y resumen de ideas clave para crear productos disruptivos con Lean Product Discovery

La clave del éxito es tener en cuenta al cliente durante todo el proceso y estar constantemente probando e iterando. Lean Product Discovery es una herramienta esencial para cualquier equipo que quiera crear productos que la gente ame. Al centrarse en el cliente y utilizar métodos ágiles, los equipos pueden crear mejores productos de manera más rápida y eficiente.

El siguiente paso es juntar todas las ideas y crear un nuevo producto. El producto debe evaluarse con clientes potenciales, iterarse y luego escalarse.

El proceso de Lean Product Discovery puede ayudarte a crear productos disruptivos que harán crecer tu negocio. Entonces, es hora de que dejes de adivinar lo que la gente quiere y comiences a experimentar con ideas innovadoras.


martes, septiembre 29, 2020

Entiende el MVP (Producto Mínimo Viable) y por qué prefiero Producto que se pueda probar, utilizar y adorar más temprano

Por Henrik Kniberg. Publicado el 2016-01-25 – 12:14.

Hace un par de años dibujé esta imagen y comencé a usarla en varias presentaciones sobre desarrollo ágil y lean:

¡Desde entonces el dibujo se ha vuelto viral! Aparece en todas partes, en artículos y presentaciones, incluso en un libro ("User Story Mapping" de Jeff Patton, una lectura excelente por cierto). Muchos me dicen que el dibujo realmente captura la esencia del desarrollo iterativo e incremental, la puesta en marcha ajustada, el MVP (producto mínimo viable) y demás. Sin embargo, algunos lo malinterpretan, lo cual es bastante natural cuando sacas una foto de su contexto original. Algunos lo critican por simplificar demasiado las cosas, lo cual es cierto. La imagen es una metáfora. No se trata del desarrollo real de un automóvil, se trata del desarrollo de un producto en general, utilizando un automóvil como metáfora.

De todos modos, con todo este rumor, pensé que era hora de explicar el pensamiento detrás de esto.

Primer ejemplo: no así

La fila superior ilustra un concepto erróneo común sobre el desarrollo iterativo e incremental de productos (también conocido como Ágil).

Muchos proyectos fracasan gravemente porque realizan una entrega tipo Big Bang (construya la cosa hasta que esté 100% terminada y entregue al final). Perdí la cuenta de la cantidad de proyectos fallidos que vi debido a esto (ve más adelante para ver algunos ejemplos). Sin embargo, cuando Ágil se presenta como una alternativa, las personas a veces se resisten a la idea de entregar un producto sin terminar, ¿quién quiere la mitad de un automóvil? Imagina esto:

“Aquí señor, aquí está nuestra primera versión, un neumático delantero. ¿Qué piensa?"

El cliente dice "¿Por qué diablos me entregas un neumático? ¡Pedí un COCHE! ¿Qué se supone que debo hacer con esto?"

(Por cierto, estoy usando el término "cliente" aquí como un término genérico para representar a personas como gerentes de productos, dueños de productos y usuarios pioneros en la adopción).

Con cada entrega, el producto está más cerca de estar terminado, pero el cliente todavía está enojado porque en realidad no puede usar el producto. Todavía es un auto parcial.

Y finalmente, cuando el producto está terminado, el cliente dice “¡Gracias! ¡Finalmente! ¿Por qué no entregaste esto en primer lugar y te saltaste todas las demás entregas inútiles?”.

En este ejemplo, el cliente está contento con el producto final, porque es lo que pidió. En realidad, eso no suele ser cierto. Ha pasado mucho tiempo sin ninguna prueba de usuario real, por lo que es muy probable que el producto esté plagado de fallas de diseño basadas en suposiciones incorrectas sobre lo que la gente necesita. Entonces esa carita sonriente al final es bastante idealista.

De todos modos, la primera fila representa “ágil bastardo”. Técnicamente, puede ser una entrega incremental e iterativa, pero la ausencia de un ciclo de retroalimentación real lo hace muy arriesgado, y definitivamente no es ágil.

De ahí el título "No así".

Segundo ejemplo: ¡así!

Ahora para la segunda fila.

Aquí adoptamos un enfoque muy diferente. Comenzamos con el mismo contexto: el cliente pidió un automóvil. Pero esta vez no solo construimos un automóvil. En su lugar, nos centramos en la necesidad subyacente que el cliente quiere que se satisfaga. Resulta que su necesidad subyacente es "Necesito ir de A a B más rápido", y el Carro es solo una posible solución para eso. Recuerda, el automóvil es solo una metáfora, piensa en cualquier tipo de situación de desarrollo de productos personalizados.

Entonces, el equipo ofrece lo más pequeño que se les ocurre que hará que el cliente pruebe cosas y nos dé su opinión. Algunos podrían llamarlo MVP (Producto mínimo viable), pero yo prefiero llamarlo Producto Comprobable más Temprano (más sobre esto más adelante).

Llámalo como quieras (algunos incluso llaman a su primer lanzamiento "la versión en patineta" del producto, basándose en esta metáfora...).

Es poco probable que el cliente esté satisfecho con esto porque no está cerca del auto que ordenó. ¡Pero eso está bien! Aquí está el truco: no estamos tratando de hacer feliz al cliente en este momento. Podríamos hacer felices a algunos de los primeros en adoptarlo (o a los pragmáticosque están sufriendo), pero nuestro principal objetivo en este momento es simplemente aprender. Idealmente, el equipo explica esto claramente al cliente con anticipación, para que no se sienta demasiado decepcionado.

Sin embargo, a diferencia de la rueda delantera en el primer escenario, la patineta es en realidad un producto utilizable que ayuda al cliente a pasar de A a B. No es genial, pero es un poquito mejor que nada. Entonces le decimos al cliente "no se preocupe, el proyecto no está terminado, esta fue solo la primera de muchas iteraciones. Seguimos intentando fabricar un coche, pero mientras tanto, intente esto y envíenos sus comentarios”. Piensa en grande, pero entrega en pequeños incrementos funcionalmente viables.

Podríamos aprender algunas cosas realmente sorprendentes. Supongamos que el cliente dice que odia la patineta, le preguntamos por qué y dice "Odio el color". Estamos como "uh... ¿el color? ¿Eso es todo?". Y el cliente dice “¡Sí, hazlo azul! Aparte de eso, ¡está bien!”. ¡Acabas de ahorrar *mucho* dinero sin construir el auto! No es probable, pero ¿quién sabe?

La pregunta clave es "¿Cuál es la forma más barata y rápida en que podemos empezar a aprender?" ¿Podemos entregar algo incluso antes que una patineta? ¿Qué tal un tiquete de autobús?

¿Ayudará esto a resolver el problema del cliente? Tal vez, tal vez no, pero definitivamente aprenderemos algo al poner esto en manos de usuarios reales. Lean Startup ofrece un gran modelo basado en enumerar sus hipótesis reales sobre los usuarios y luego trabajar sistemáticamente para validarlas o invalidarlas.

No es necesario que pruebes el producto en todos los usuarios y no es necesario crear un producto para probar algo. Probar un prototipo incluso en un solo usuario te enseñará más que nada.

Pero bueno, volvamos al ejemplo de la patineta.

Después de jugar con él en la oficina, el cliente dice: “Está bien, es un poco divertido y me lleva a la máquina de café más rápido. Pero es inestable. Me caigo con demasiada facilidad”.

Así que en la próxima iteración intentamos resolver ese problema, o al menos aprender más sobre él.

¡El cliente ahora puede moverse por la oficina sin caerse!

¿Contento? En realidad, no, todavía quiere ese coche. Pero mientras tanto, en realidad está usando este producto y nos está dando su opinión. Su mayor queja es que es difícil viajar distancias más largas, como entre edificios, debido a las ruedas pequeñas y a la falta de frenos. Entonces, el siguiente lanzamiento, el producto se transforma en algo así como una bicicleta.

Ahora el cliente puede moverse por el campus. ¡Yiihaaa!

Aprendemos algunas cosas en el camino: al cliente le gusta la sensación de aire fresco en su rostro. El cliente está en un campus y el transporte consiste principalmente en desplazarse entre edificios.

La bicicleta puede llegar a ser un producto mucho mejor que el automóvil que se imaginó originalmente. De hecho, mientras probamos este producto, podemos aprender de todos modos que los caminos son demasiado estrechos para un automóvil. ¡Le ahorramos al cliente toneladas de tiempo y dinero, y le dimos un producto mejor en menos tiempo!

Ahora puedes estar pensando "¿pero no deberíamos haberlo sabido ya a través de un análisis inicial del contexto y las necesidades del cliente?" Buen punto. Pero en la mayoría de los escenarios de desarrollo de productos de la vida real que he visto, no importa cuánto análisis inicial hagas, todavía te sorprendes cuando pones la primera versión real en manos de un usuario real y muchas de tus suposiciones resultan estar muy lejos.

Entonces, sí, haz algo de análisis inicial, descubre todo lo que puedas antes de comenzar el desarrollo. Pero no le dediques demasiado tiempo y no confíes demasiado en el análisis; en su lugar, comienza a crear prototipos y a publicar, ahí es cuando ocurre el verdadero aprendizaje.

Como sea, volviendo a la historia. Quizás el cliente quiera más. A veces necesita viajar a otra ciudad y el paseo en bicicleta es demasiado lento y sudoroso. Entonces, en la próxima iteración agregamos un motor.

Este modelo es especialmente adecuado para software, ya que el software es, bueno, Soft. Puedes "transformar" el producto a medida que avanzas, a diferencia del hardware en el que esencialmente debes reconstruir cada vez. Sin embargo, incluso en proyectos de hardware, la entrega de prototipos tiene un gran beneficio para observar y aprender de cómo el cliente usa su producto. Es solo que las iteraciones tienden a ser un poco más largas (meses en lugar de semanas). Incluso las empresas de automóviles reales como Toyota y Tesla hacen muchos prototipos (bocetos, modelos 3D, modelos de arcilla a gran escala, etc.) antes de desarrollar un nuevo modelo de automóvil.

¿Y ahora qué? Una vez más, tal vez el cliente esté contento con la motocicleta. Podríamos finalizar el proyecto antes de lo planeado. La mayoría de los productos están plagados de complejidad y características que nadie usa. El enfoque iterativo es realmente una forma de entregar menos o encontrar la forma más sencilla y económica de resolver el problema del cliente. Minimiza la distancia a Impresionante. Muy zen.

O, nuevamente, el cliente puede optar por continuar, con o sin modificaciones a los requisitos. De hecho, podemos terminar con exactamente el mismo automóvil que se imaginó originalmente. Sin embargo, es mucho más probable que obtengamos conocimientos vitales en el camino y terminemos con algo ligeramente diferente. Me gusta esto:

¡El cliente está encantado! ¿Por qué? Porque en el camino aprendimos que aprecia el aire fresco en su rostro, así que terminamos con un descapotable. Después de todo, consiguió un coche, ¡pero mejor de lo planeado originalmente!

Así que retrocedamos un paso.

¿Cuál es tu patineta?

El escenario principal (entregar una llanta delantera) apesta porque seguimos entregando cosas que el cliente no puede usar en absoluto. Si sabes lo que estás haciendo (tu producto tiene muy poca complejidad y riesgo, tal vez hayas construido ese tipo de cosas cientos de veces antes), entonces sigue adelante y haz una única entrega tipo “big bang”. Construye la cosa y entrégala cuando esté lista.

Sin embargo, la mayoría de los esfuerzos de desarrollo de productos que he visto son demasiado complejos y arriesgados para eso, y el enfoque del Big Bang con demasiada frecuencia conduce a fallas enormes y costosas. Entonces, la pregunta clave es ¿Cuál es tu patineta?

En el desarrollo de productos, una de las primeras cosas que debes hacer (después de describir qué problema estás tratando de resolver para quién) es identificar su equivalente en patineta. Piensa en la patineta como una metáfora de lo más pequeño que puedes poner en manos de usuarios reales y obtén retroalimentación real. O usa un "boleto de autobús" si esa metáfora funciona mejor.

Esto te dará el circuito de retroalimentación vitalmente necesario y te dará a ti y al cliente el control sobre el proyecto; puedes aprender y hacer cambios, en lugar de simplemente seguir el plan y esperar lo mejor.

Veamos algunos ejemplos de la vida real.

Ejemplo 1: reproductor de música Spotify

“Con más de 75 millones de usuarios, es difícil recordar un momento sin Spotify. Pero hubo una época en la que todos estábamos reflexionando sobre los pasillos de Target en busca de nuevos CD. Un momento de nuestras vidas en el que todos nos convertimos en ladrones en Napster. Una época en la que iTunes nos obligaba a comprar canciones por 2 dólares la pieza. Y luego vino Spotify". –Tech Crunch.

Spotify es un producto bastante elegante ahora. Pero no empezó de esa manera. Tuve la suerte de estar involucrado muy temprano en este viaje increíble (y todavía lo estoy).

Como startup en 2006, Spotify se fundó sobre algunas suposiciones clave: que la gente está feliz de transmitir (en lugar de poseer) música, que los sellos discográficos y los artistas están dispuestos a permitir que la gente lo haga legalmente y que la transmisión rápida y estable es técnicamente factible. Recuerda, esto fue en 2006 cuando la transmisión de música (como Real Player) era una experiencia bastante horrible, y la música copiada por piratas era prácticamente la norma. La parte técnica del desafío fue: “¿Es posible crear un cliente que transmita música instantáneamente cuando presionas el botón Reproducir? ¿Es posible deshacerse de esa molesta barra de progreso de 'Buffering'?"

Empezar de a poco no significa que no puedas pensar en grande. Este es uno de los primeros bocetos de lo que tenían en mente:

Pero en lugar de pasar años construyendo todo el producto y luego averiguar si las suposiciones se mantenían, los desarrolladores básicamente se sentaron y piratearon un prototipo técnico, pusieron cualquier música copiada que tuvieran en sus computadoras portátiles y comenzaron a experimentar salvajemente para encontrar formas de hacer que la reproducción fuera rápida y estable. La métrica de conducción fue "¿cuántos milisegundos se necesitan desde que presiono Reproducir hasta que escucho la música?". ¡Debería reproducirse casi instantáneamente y continuar reproduciéndose sin problemas sin tartamudear!

“Pasamos una gran cantidad de tiempo enfocándonos en la latencia, cuando a nadie le importaba, porque estábamos empeñados en hacer que pareciera que tenías toda la música del mundo en tu disco duro. Obsesionarse con los pequeños detalles a veces puede marcar la diferencia. Eso es lo que creo que es el mayor malentendido sobre el concepto de producto mínimo viable. Esa es la V en el MVP". -Daniel Ek, cofundador y CEO.

Una vez que tenían algo decente, comenzaron a probarse a sí mismos, con su familia y amigos.

La versión inicial no se pudo lanzar a una audiencia más amplia, estaba totalmente sin pulir y básicamente no tenía características excepto la capacidad de encontrar y reproducir algunas canciones codificadas, y no había acuerdo legal o modelo económico. Era su patineta.

Pero descaradamente pusieron la patineta en manos de usuarios reales, – Amigos  y familiares –  y rápidamente obtuvieron las respuestas que necesitaban. Sí, era técnicamente posible. Y sí, a la gente le encantó el producto (o más bien, ¡en lo que el producto podía convertirse!) ¡Las hipótesis fueron validadas! Este prototipo en ejecución ayudó a convencer a los sellos discográficos y a los inversores y, bueno, el resto es historia.

Ejemplo 2: Minecraft

Minecraft es uno de los juegos más exitosos en la historia del desarrollo de juegos, especialmente si se tiene en cuenta el costo de desarrollo. Minecraft es también uno de los ejemplos más extremos de la mentalidad de lanzamiento temprano y frecuente. El primer lanzamiento público se realizó después de solo 6 días de codificación, ¡por un solo hombre! No se podía hacer mucho en la primera versión: era básicamente un paisaje en 3D feo y en bloques donde se podían desenterrar bloques y colocarlos en otro lugar para construir estructuras toscas.

Esa fue la patineta.

Sin embargo, los usuarios estaban muy comprometidos (la mayoría de las comunicaciones entre desarrolladores y usuarios se realizaban a través de Twitter, bastante divertido). Entre los primeros usuarios estábamos mis cuatro hijos y yo. Se realizaron más de cien lanzamientos durante el primer año. El desarrollo de juegos es todo acerca de encontrar la diversión (algunas compañías de juegos con las que he trabajado usan el término "Definición de Diversión" en lugar de "Definición de Terminado"), y la mejor manera de hacerlo es haciendo que personas reales efectivamente jueguen ese juego. – En este caso, se trataba de miles de personas reales que habían pagado para probar la versión de acceso anticipado y, por lo tanto, tenían un incentivo personal para ayudar a mejorar el juego.

Gradualmente, se formó un pequeño equipo de desarrollo alrededor del juego (en realidad, eran 2 chicos), y el juego se convirtió en un gran éxito en todo el mundo. No creo haber conocido a ningún niño en ninguna parte que no jugara Minecraft. Y el año pasado, el juego (bueno, la compañía que se formó alrededor del juego) se vendió a Microsoft por $ 2.5 mil millones. Bastante sorprendente.

Ejemplo 3: Un gran proyecto gubernamental

Alrededor de 2010, la policía sueca lanzó una gran iniciativa para permitir que la policía pasara más tiempo en el campo y menos en la estación: PUST (Polisens Utrednings STöd). Un proyecto fascinante, participé como coach y escribí un libro sobre lo que hicimos y lo que aprendimos (Lean from the Trenches).

La idea era colocar computadoras portátiles en los automóviles y software personalizado para que la policía tuviera acceso a los sistemas que necesitaran en tiempo real, por ejemplo, mientras se interroga a un sospechoso (estábamos en la era anterior a las tabletas).

Habían intentado construir sistemas similares en el pasado y fracasaron estrepitosamente, principalmente debido al pensamiento Big Bang. Me dijeron que uno de sus intentos anteriores tomó 7 años desde el inicio hasta el primer lanzamiento. ¡SIETE AÑOS! Para entonces, por supuesto, todo había cambiado y el proyecto fue un fracaso total. Así que esta vez querían hacerlo de otra manera.

El proyecto de 60 personas (más tarde denominado "PUST Java") tuvo un éxito sorprendente, especialmente por ser un gran proyecto gubernamental (incluso quedó en segundo lugar en los premios CIO "Proyecto del año"). Uno de los principales factores de éxito fue que no intentaron construir todo de una vez, sino que dividieron al elefante en dos dimensiones:

  • Por región. No es necesario que lo publiquemos en TODA Suecia a la vez, podríamos comenzar publicando solo en una región.
  • Por tipo de delito. No es necesario que soportemos TODOS los tipos de delitos inicialmente, podríamos comenzar apoyando solo 1-2 tipos de delitos.

La primera versión, la 1.0, fue su patineta.

Era un sistema pequeño, que soportaba solo un par de tipos de delitos, y se probó sobre el terreno con un puñado de policías en Östergötland (una región de Suecia). Otros tipos de delitos tenían que tratarse a la antigua: conducir hasta la estación y hacer el papeleo. Sabían que eran conejillos de indias y que el producto no estaba ni cerca de estar terminado. Pero estaban felices de probarlo, porque conocían la alternativa. Habían visto qué tipo de sistemas asquerosos surgían de procesos que carecían de retroalimentación temprana de los usuarios, ¡y ahora finalmente tenían la oportunidad de influir en un sistema mientras se estaba construyendo!

Sus comentarios fueron duros y honestos. Muchas de nuestras suposiciones volaron por la ventana, y uno de los grandes dilemas fue qué hacer con todas las especificaciones de casos de uso cuidadosamente elaboradas que se estaban volviendo cada vez menos relevantes a medida que llegaba la retroalimentación de los usuarios reales (esta era una organización con un historial en cascada y el hábito de hacer un extenso análisis al principio de los proyectos).

De todos modos, en pocas palabras, la retroalimentación temprana se canalizó hacia mejoras del producto y, gradualmente, a medida que a los policías de Östergötland les empezó a gustar el producto, pudimos agregar más tipos de delitos y difundirlo a más regiones. Para cuando llegamos al gran lanzamiento (1.4), con el despliegue a nivel nacional y la capacitación de 12000 policías, no estábamos tan preocupados. Habíamos hecho tantos lanzamientos, tantas pruebas de usuarios, que dormimos bien la noche del lanzamiento nacional.

Desafortunadamente, la victoria duró poco. Un proyecto de seguimiento (PUST Siebel) lo estropeó y volvió al pensamiento de cascada, probablemente debido a un viejo hábito. 2 años de análisis y pruebas sin lanzamientos ni pruebas de usuario, seguidos de un lanzamiento espectacular de la "próxima generación" del producto para los 12.000 policías a la vez. Fue un desastre absoluto, y después de medio año de hemorragia cerraron todo. El costo del desarrollo fue de unos 20 millones de euros, pero los estudios internos estiman que el coste para la sociedad sueca (porque la policía se vio perjudicada por el horrible sistema) fue del orden de mil millones de euros.

¡Una forma bastante cara de aprender!

Ejemplo 4: Lego

Actualmente estoy trabajando en Lego y estoy asombrado por su capacidad para ofrecer nuevos éxitos, año tras año, sin falta. Escucho muchas historias interesantes sobre cómo hacen esto, ¡y el tema común es la creación de prototipos y las primeras pruebas de usuario! A menudo veo grupos de niños en la oficina y los diseñadores colaboran con los jardines de infancia, las escuelas y las familias locales para probar sobre el terreno las últimas ideas de productos.

Aquí hay un ejemplo reciente: Nexo Knights (lanzado en enero de 2016):

Cuando comenzaron a explorar este concepto, hicieron prototipos en papel y se los llevaron a los niños pequeños. La primera reacción de los niños fue "oye, ¿quiénes son los malos? ¡No veo quién es bueno y quién es malo!". ¡Ups! Así que los diseñadores siguieron iterando y probando hasta que encontraron un diseño que funcionó con los niños. Apuesto a que incluso tú puedes ver quién es el bueno y quién es el malo en la imagen de arriba...

No estoy seguro de dónde está exactamente la patineta en esta historia, pero entiendes la idea: ¡retroalimentación temprana de usuarios reales! No te limites a diseñar el producto y construirlo todo. ¡Imagínate si hubieran construido el producto basándose en sus supuestos de diseño originales y hubieran aprendido sobre el problema después de entregar miles de cajas a tiendas de todo el mundo!

Lego también tiene su parte de fracasos duramente ganados. Un ejemplo es Lego Universe, un mundo Lego en línea multijugador masivo. Suena divertido, ¿eh? El problema es que se volvieron demasiado ambiciosos y terminaron tratando de construir todo a la perfección antes de lanzarlo al mundo.

Aproximadamente 250 personas trabajaron durante 4-5 años (por el constante cambio de alcance debido al perfeccionismo), y cuando finalmente llegó el lanzamiento, la recepción fue... tibia. El juego terminado fue hermoso, pero no tan divertido como se esperaba, por lo que el producto se cerró después de 2 años.

¡No hubo patineta!

¿Por qué no? Porque las patinetas no son geniales (al menos no si esperas un automóvil), y la cultura de Lego se trata de brindar experiencias increíbles. Si trabajas en los cuarteles generales de Lego en Billund, Dinamarca, pasas por este enorme mural todos los días:

Se traduce aproximadamente como "Solo lo mejor es suficientemente bueno". Ha sido el principio rector de Lego desde que la empresa comenzó hace más de 80 años y les ha ayudado a convertirse en una de las empresas más exitosas del mundo. Pero en este caso se aplicó mal el principio. La búsqueda de la perfección retrasó la retroalimentación vital, lo que significó suposiciones erróneas sobre lo que a los usuarios les gusta y no les gusta. Exactamente lo contrario de Minecraft.

Curiosamente, los equipos de Lego Universe estaban usando Scrum e iterando en gran medida, al igual que los chicos de Minecraft. Pero los comunicados fueron solo internos. Así que lo más probable es que hubiera una patineta y una bicicleta, etc., pero esos productos nunca llegaron a los usuarios reales. No es así como se pretende utilizar Scrum.

Fue una falla costosa, pero Lego aprendió de ella y constantemente mejoran en las primeras pruebas y de la retroalimentación de los usuarios.

Mejora sobre el "MVP"

Y eso (respiración profunda…) me lleva al tema de MVP - Producto Mínimo Viable.

La idea subyacente es genial, pero el término en sí mismo causa mucha confusión y angustia. He conocido a muchos clientes que dicen "De ninguna manera quiero una entrega de MVP – ¡esa es la última entrega que recibiré!" Con demasiada frecuencia, los equipos entregan el llamado Producto Mínimo Viable, y luego rápidamente son llevados al siguiente proyecto, dejando al cliente con un producto sin terminar y con errores. Para algunos clientes, MVP = MRC (Basura Mínima Liberable - Minimum Releasable Crap).

Lo sé, lo sé, esto se reduce a una mala gestión en lugar del término MVP, pero aun así... el término invita a malentendidos. “Mínimo” y “Viable” significan cosas diferentes para diferentes personas y eso causa problemas.

Así que aquí hay una alternativa.

En primer lugar, reemplaza la palabra "Mínimo" por "Temprano". La idea principal detrás del lanzamiento de un MVP es obtener retroalimentación temprana: al entregar un producto mínimo en lugar de un producto completo, podemos obtener la retroalimentación antes.

¡Pocos clientes quieren "mínimo", pero la mayoría de los clientes quieren "temprano"! Entonces ese es nuestro primer cambio:

Mínimo => Más temprano

A continuación, elimina la palabra "Viable", ya que es demasiado vaga. Tu "viable" es mi "horrible". Algunas personas piensan que Viable significa “algo que puedo probar y de lo que puedo obtener comentarios”, otras piensan que significa “algo que el cliente realmente puede usar”. Así que seamos más explícitos y dividámoslo en tres cosas diferentes:

El producto comprobable* más temprano es la patineta o el tiquete de autobús, el primer lanzamiento con el que los clientes pueden hacer algo. Puede que no resuelva su problema, pero genera al menos algún tipo de retroalimentación. Dejamos muy claro que el aprendizaje es el objetivo principal de esta versión y que cualquier valor real para el cliente será una ventaja.

El producto utilizable más temprano es quizás la bicicleta. La primera versión que los primeros usuarios realmente usarán, de buena gana. Está lejos de estar terminado y puede que no sea muy agradable. Pero pone a tus clientes en una mejor posición que antes.


El producto adorable más temprano es quizás la motocicleta. El primer lanzamiento que los clientes adorarán, les contarán a sus amigos y por el que estarán dispuestos a pagar. Todavía hay mucho que mejorar y es posible que acabemos con un descapotable, un avión o algo más. Pero hemos llegado al punto en el que tenemos un producto realmente comercializable.

Consideré agregar un paso anterior, "Producto con retroalimentación más temprana", que es básicamente el prototipo en papel o equivalente que usas para obtener tu primera retroalimentación del cliente. Pero cuatro pasos parecen demasiados, y la palabra retroalimentable... ¡Uf! Sin embargo, ese también es un paso importante. Algunos llamarían a un prototipo de papel el Producto que se puede probar más temprano, pero supongo que eso se reduce a cómo se define “Comprobable”. Consulta la Guía de MVP de Martin para conseguir más información – tiene muchos ejemplos muy concretos de cómo obtener retroalimentación temprana con una inversión mínima.

Por supuesto, la gente todavía puede malinterpretar el Más temprano probable / Usable / Adorable, pero es al menos un paso más explícito que el nebuloso Producto mínimo viable.

Puntos para llevarte

Buen momento para terminar. Nunca pensé que sería tan largo, ¡gracias por quedarte! Conclusiones clave:

  • Evita la entrega Big Bang para el desarrollo de productos complejos e innovadores. Hazlo de manera iterativa e incremental. Eso ya lo sabías. ¿Pero, lo estás haciendo realmente?
  • Empieza por identificar tu patineta, el producto comprobable más temprano. Apunta a las nubes, pero trágate tu orgullo y comienza entregando la patineta.
  • Evita el término MVP. Sé más explícito acerca de lo que realmente estás hablando. El más temprano comprobable / utilizable / adorable es solo un ejemplo, usa los términos que sean menos confusos para tus partes interesadas.

Y recuerda: el dibujo de la patineta / automóvil es solo una metáfora. No lo tomes tan literal: o)

PD: aquí hay una historia divertida sobre cómo mis hijos y yo usamos estos principios para ganar una competencia de sumo de robots: o)

Gracias Mary Poppendieck, Jeff Patton, Alistair Cockburn, Anders Haugeto, Sophia, colegas de Crisp, Spotify y Lego, y todos los demás que dieron toneladas de retroalimentación útil.

***

Artículo original de Henrik Kniberg: Making Sense of MVP

***

domingo, diciembre 15, 2019

El contexto de tu producto importa: aquí te cuento el porqué

Imagen tomada de Pixabay

Escucha el audio de este artículo aquí:

Los dueños de producto virtuosos utilizan una combinación de análisis de negocios, experiencia de usuario y habilidades de gestión de productos para determinar cuál es el siguiente producto correcto a diseñar y construir y para compartir con el equipo de desarrollo el entendimiento que tienen de su visión.

Mucho antes de la era ágil ya enseñaba y acompañaba a los gerentes de producto y líderes de equipos de producto a:
  • Entender mejor a los interesados, a los usuarios y a todo aquel que se viera impactado de una u otra forma por el producto y por su desarrollo
  • Comprender el contexto de su producto
  • Tener una percepción más íntima de las necesidades de sus consumidores
  • Entender y juzgar el producto derivado de su trabajo con el equipo
  • Organizar la información recopilada del aprendizaje del uso del producto, más del contexto de este.
El movimiento ágil me enseñó posteriormente que una técnica específica puede o no ser apropiada en cada situación. También me enseñó que el diseño y la elaboración de productos impresionantes es una forma de pensar, una mentalidad. De esta manera, el mensaje que llevo a los Dueños de Producto actuales para ayudarlos a determinar el momento adecuado para usar una u otra técnica y la forma más sencilla de aplicarla, es conocer en profundidad los diferentes escenarios, las circunstancias o condiciones bajo las cuales será usado el producto que tienen en mente, lo que casi siempre incluye conocer al detalle a los usuarios o consumidores.

Pero en el camino de establecer una comprensión compartida del problema y más allá, de la causa raíz, el problema detrás del problema, y de las mejores soluciones para resolverlo, nos encontramos con ciertos impedimentos como:
  • Muchos backlogs de producto
  • Dificultad en la priorización de cada uno de ellos y entre unos y otros
  • Poca percepción del valor de cada producto y de cada uno de sus componentes, el valor para el negocio
  • Muchas interdependencias entre unos y otros y hasta con productos que no están en el radar de nadie
  • Los equipos no necesariamente están trabajando en los productos correctos desde una perspectiva del negocio, aunque los Dueños de Producto no ayudan mucho en este sentido

Para sobrepasar estas dificultades ayuda conocer el contexto en el cual estamos trabajando. Es útil encontrar las respuestas a preguntas como:
  • ¿Quién necesitará o usará nuestro producto?
  • ¿Quién es nuestro consumidor final?
  • ¿A qué mercado o segmento de mercado queremos llegar?

Pero ya no estamos en el momento de quedarnos con las respuestas simples. Estamos en la era de la hiperpersonalización de productos. Cada consumidor o usuario quiere tener su propia experiencia, única, así es que dediquemos tiempo a conocer a muchos de ellos. No es que necesitemos salir con un MVP para cada uno, se trata de salir lo más rápido posible con un producto en excelentes condiciones, listo para usar o consumir y,  a partir de allí, incrementarlo y desplegarlo a más y más usuarios de manera frecuente.

Dediquemos un tiempo importante a repensar el producto. No caigamos en la trampa del “MVP muy temprano”. El mayor miedo de las organizaciones hoy es llegar al mercado con el producto incorrecto. Está bien lo de fallar rápido y barato pero no se trata de fallar por fallar. Nos enfrentamos a la paradoja de las organizaciones exitosas: solo queremos brindar productos que enamoren a las personas, pero no sabemos si el producto deleitará a nuestros clientes hasta tanto no lo hayamos entregado.

Las cosas así, llevar a cabo minuciosamente algunas de estas actividades, sino todas, ayuda:
  • Definir y defender la visión del producto.
  • Investigar la naturaleza y probar las necesidades del mercado
  • Identificar múltiples opciones de productos de alto valor.
  • Decidir las fechas de lanzamiento y el contenido. Sobre todo, lanzar con calidad.
  • Durante el desarrollo “a lo Scrum”, lograr que los elementos del backlog de producto estén "Preparados" para la planificación y desarrollo
  • En ese mismo orden de ideas, aceptar solo trabajo "Terminado"
  • Realizar demostraciones de productos y solicitar retroalimentación en vivo y en directo, tomar atenta nota e incorporar, de ser posible, las nuevas solicitudes

En mi artículo Las historias de usuario se cuentan con C de Contexto, enumeraba Algunas herramientas que nos ayudan a entender mejor el contexto de las historias de usuario y del producto en general. Puedes leer el artículo en:

Ahora bien, antes de pensar en la tecnología, pensemos en el negocio. Antes de salir a vender (o a producción), pensemos en el mercado. Antes de desarrollarlo, pensemos en el cliente o usuario. Antes de considerar sus componentes internos, pensemos en cómo se verá a los ojos, a los sentidos de las personas a las que queremos llevarle el producto.

Una técnica que estamos aplicando con éxito es esta del desarrollo de productos basado en experimentos: una forma de abordar el diseño del producto y el proceso de desarrollo para que la investigación, el descubrimiento y el aprendizaje (hacer preguntas y obtener respuestas útiles y confiables) tengan prioridad sobre el diseño y luego la validación de las soluciones propuestas. Pero sobre desarrollo de productos basado en experimentos hablaremos en otra oportunidad.

Imagen tomada de Pixabay
Mientras tanto, atención Dueños de Producto, Gerentes de Producto, deleguen completamente el diseño y la construcción del producto al equipo de desarrollo, ustedes dedíquense a explorar el mercado, a aprender de él, a pensar en nuevas formas de cambiar el estilo de vida de las personas y a conocer las necesidades de estas. Es lo que finalmente los conducirá al éxito en sus tareas habituales. ¡Escucha a tu usuario!

Finalmente, es solo a través de procesos efectivos de diseño, prueba, retroalimentación e iteración, que un Dueño de Producto y su equipo pueden validar el impacto de una idea en un contexto. Súmate a un equipo grandioso, porque un equipo estupendo hace productos fantásticos.

martes, octubre 29, 2019

La deuda de producto: cómo se manifiesta y qué hacer al respecto

The Uncomfortable Entrance - Illustration by Katerina Kamprani

Este tipo de deuda se presenta cuando el producto no constituye algo significativo para tu identidad como consumidor o usuario, para tu desarrollo personal o tu bienestar. Aquí estamos hablando de la experiencia de usuario. Es decir, si el producto no genera en sus consumidores emociones y actitudes positivas que sean capaces de impactar su estatus actual. O si esos usuarios no perciben aspectos del producto como su utilidad, la facilidad de uso y la eficiencia, entonces estamos ante una deuda en rojo.

Le faltan esos atributos tangibles e intangibles que brindan al consumidor los beneficios esperados por este y que le resuelven una necesidad específica. Con tangibles me refiero a lo que hace el producto, a la tecnología, al diseño, a la forma. Con intangibles, a los elementos emocionales que generan apego en el usuario, a su identidad de marca, a su ecosistema, a si impacta positivamente la vida de quienes lo consumen y si ese impacto es sostenible. Otra vez, estas dos clases de características es lo que hace posible una extraordinaria experiencia de consumidor, de cliente.

La deuda de producto también es interna, algo que muchas veces ni siquiera el usuario es capaz de percibir. Me refiero a la cultura de Agilidad en medio de la cual fue creado o elaborado el producto, al empoderamiento del equipo, a la felicidad de sus miembros, al foco en el cliente que pusieron todas las personas encargadas de su ideación, descubrimiento, prototipado, desarrollo y puesta en producción de ese producto.

La deuda de producto crece cuando el equipo no aprendió ni mejoró un ápice durante su desarrollo. Además, si el equipo y otros interesados no conocen al cliente, cuáles son sus necesidades o porqué deberían adquirir o usar el producto, la deuda de ese producto también se incrementa.

Si no hubo confianza en el equipo, no se le delegaron las principales responsabilidades para elaborar el producto ni se les habilitó un entorno seguro, donde el empoderamiento y la experimentación estuvieran a la orden del día, hay más deuda de producto.

Si todas las buenas ideas del producto terminan con su despliegue al mercado, todavía habrá un gran camino que recorrer, una deuda aumentada que pagar. El despliegue del producto no es el objetivo. La meta es el cliente, su satisfacción, su felicidad, mejorar su modus vivendi. Si nos quedamos en la puesta en marcha del producto, apenas si nos habremos concentrado en la salida del producto, un número de características de las cuales no sabemos cuáles serán usadas y cuáles no. Consecuencia: más deuda de producto. En cambio, si nuestro foco es el cliente y sus necesidades y la experiencia que tenga usando el producto, entonces estaremos concentrándonos en el valor, en el resultado positivo que puede entregar ese producto a la humanidad.

Otras causas de la deuda de producto:
  • Siempre aplicamos las mismas prácticas en todas partes
  • Siempre exigimos adherencia a actividades y procesos, ágiles o no
  • Definimos la cadena de herramientas permitida
  • Forzamos la estandarización en todas partes
  • Creemos que el proceso habla por sí mismo
  • Confiamos en el proceso más que en las personas y el equipo
Las cosas así, podríamos definir la deuda de producto como:

Deuda de Producto = Falta de Experiencia de Usuario + Falta de Tangibles (Tecnología, Diseño, Forma) + Falta de Intangibles (Emociones, Identidad de Marca) + Falta de Agilidad + Falta de Foco en el Cliente + Falta de Confianza en el Equipo + Falta de Delegación + Otros*

* Incluye aquí los que aplican para tu entorno específico

Para no incurrir en más deuda de producto

El Dueño de Producto debe:
  • Definir y liderar la visión del producto.
  • Investigar y probar las necesidades del cliente / mercado
  • Identificar opciones de productos de alto valor.
  • Hacer que los elementos del backlog estén "preparados" para su planificación y desarrollo
  • Aceptar solo trabajo "terminado"
  • Realizar demostraciones de producto
  • Fomentar la consistencia donde esta sea importante, en todos los niveles de la organización
  • Explicar siempre el valor detrás de un proceso
  • Observar, aprender de y analizar el mercado.
  • Compartir ideas en la organización con respecto al producto y aceptar retroalimentación oportuna
  • Decidir las fechas de lanzamiento y el contenido.
  • Salir al mercado (a producción) tan rápido como sea posible e ir afinando el producto a medida que recibe información de su uso
  • No lanzar en la fecha, lanzar en calidad (a lo Spotify).
  • Asegurarse de que el producto vaya de excelente en su salida inicial a extraordinario después del lanzamiento, afinándolo continuamente.
  • Saber cuándo descontinuar o sacar el producto del mercado
El equipo de desarrollo de producto debe:
  • Ser pragmático en la elección de las herramientas
  • No obsesionarse con las ceremonias o eventos de un proceso o marco de trabajo, por muy ágil que este parezca. Atención a eso Scrum Másters, coaches ágiles, habilitadores ágiles, consultores Lean y estrategas Kanban, entre otros.
  • Demostrar voluntad de evolucionar en función de la retroalimentación que proporcione el entorno
Toda la organización debe:
  • Concentrarse en el Valor.
¡Esperen! Sobre Valor del producto hablaré en una próxima oportunidad. Hasta entonces, déjame saber en el foro tus experiencias e impresiones sobre este asunto crítico de la deuda de producto.

Créditos de la imagen de portada:
The Uncomfortable Entrance
Illustrations by Katerina Kamprani
https://www.theuncomfortable.com/portfolio/the-uncomfortable-entrance/