Para entender lo que es, es necesario pensarlo en la relación con el Product Delivery. Para desarrollar productos de Software realizamos ambas cosas: Resolver qué construir: “Product Discovery” y Construirlo: “Product Delivery”.
En el lado del Product Delivery, una vez que hemos decidido qué construir, nuestra meta es sacarlo y entregar valor tan rápido como sea posible y evaluamos nuestras prácticas de delivery en medida de la velocidad de nuestros ciclos de release y cuánto valor entregamos en cada iteración a los usuarios finales tan rápido como al equipo le sea posible manteniendo la calidad en el código.
Esto tiene sentido porque las empresas necesitan ir cada vez más rápido con el fin de entregar este valor y alcanzar el “Time to Market” en su industria.
Pero ¿Cuál es la meta en el lado del Product Discovery?¿Cómo sabemos que estamos haciendo un buen trabajo? En el desarrollo de Software han existido innumerables éxitos y muchos más fracasos que tardaron años en salir al mercado y no fue algo que las personas quisieran, derivando en pérdidas millonarias para las empresas.
A partir de esos años se empieza a poner énfasis en construir cosas que las personas vayan a querer. En los años 2000 aparece el Manifiesto Ágil, y con esto la premisa para construir Software que evoluciona y se adapta a los cambios.
“Nadie quiere pasar años, creando un producto que nadie quiere” Ash Maurya, author of Running Lean
Nuevas metodologías y marcos de trabajo, como Lean, Design Thinking, Lean UX o Customer Journal entre otros, están orientadas a resolver las preguntas: ¿Los clientes quieren nuestras soluciones?, ¿Estamos resolviendo los verdaderos problemas de nuestros clientes? y para luego proceder con la entrega de este valor están las otras herramientas como Scrum o XP.
Entregar todo lo que los clientes quieren, no siempre es suficiente…o rentable
Las fuentes de ideas para productos tecnológicos pueden venir de muchos lugares: proyectos de los stakeholders, solicitudes de clientes, la competencia, nuestro equipo, propuestas de partners, …y sobran fuentes para ideas; pero estadísticamente, según un estudio realizado en el Harvard Business Review: Digital Transformation Is Not About Technology el 70% de esas ideas No tendrán el impacto que deseamos en el negocio, está claro que no podemos construir todo lo que se propone como una idea.
Bajo esta premisa, por ejemplo, si nos enfrentamos a un trabajo de al menos 12 features al año + otros gastos en los que incurre la empresa para el desarrollo de Software podríamos tener un costo de digamos $7500 mensual, y una inversión anual de $90000.
Siguiendo el 70/30 tenemos un desperdicio del $63000 de esa inversión; afortunadamente el negocio logra generar los resultados necesarios para que estas funcionalidades rentables generen más que lo invertido en el desarrollo total, teniendo una balanza a favor, aunque está claro que hubo un importante desperdicio.
¿Qué pasaría si puedo identificar lo antes posible las funcionalidades que SÍ generan el retorno que necesitamos? Muchas personas se hicieron la misma pregunta, lo que derivó en la evolución de la forma de hacer Product Discovery. Entonces ya no es suficiente solucionar problemas, sino que además se debe generar soluciones que la gente quiera o por las que está dispuesta a pagar. Hablamos de identificar esa solución que me va a permitir alcanzar mis oportunidades en el mercado con el máximo retorno de la inversión.
El empresario Henry Ford decía “Si hubiera preguntado a la gente lo que querían, me habrían pedido un caballo más rápido”
Históricamente las empresas que lograron aplicar este enfoque resolviendo el problema/ la necesidad realmente importante alcanzaron una oportunidad y trascendieron. Einstein decía a sus alumnos que si él tuviera una hora para resolver un problema usaría 55 minutos en analizar el problema para llegar a un diagnóstico certero, y una vez conociendo las causas, tardaría 5 minutos en encontrar una solución. En el mundo del Software, nos obsesionamos con las caracteristicas (features) cuando deberíamos estar obsesionados con los resultados que estamos creando para nuestros clientes y para nuestro negocio.
Entonces, ¿Cuál es la meta de Product Discovery?
Es aprender rápido, estamos en una industria en la que aprender, y aprender rápidamente es la cosa más importante para reducir el riesgo de un fracaso mayor, para discernir si lo que vamos a construir es realmente lo que necesitamos construir
Y con cada metodología (Design Thinking, Lean,Agile, OKRs) empezamos a responder preguntas más temprano durante el proceso para encontrar ese producto que nos permita alcanzar una oportunidad en el mercado entregando valor real al cliente y a nuestra organización.
Product Discovery: Maximize su rentabilidad
¿Ha escuchado hablar de Product Discovery?
Para entender lo que es, es necesario pensarlo en la relación con el Product Delivery.
Para desarrollar productos de Software realizamos ambas cosas: Resolver qué construir: “Product Discovery” y Construirlo: “Product Delivery”.
En el lado del Product Delivery, una vez que hemos decidido qué construir, nuestra meta es sacarlo y entregar valor tan rápido como sea posible y evaluamos nuestras prácticas de delivery en medida de la velocidad de nuestros ciclos de release y cuánto valor entregamos en cada iteración a los usuarios finales tan rápido como al equipo le sea posible manteniendo la calidad en el código.
Esto tiene sentido porque las empresas necesitan ir cada vez más rápido con el fin de entregar este valor y alcanzar el “Time to Market” en su industria.
Pero ¿Cuál es la meta en el lado del Product Discovery?¿Cómo sabemos que estamos haciendo un buen trabajo?
En el desarrollo de Software han existido innumerables éxitos y muchos más fracasos que tardaron años en salir al mercado y no fue algo que las personas quisieran, derivando en pérdidas millonarias para las empresas.
A partir de esos años se empieza a poner énfasis en construir cosas que las personas vayan a querer. En los años 2000 aparece el Manifiesto Ágil, y con esto la premisa para construir Software que evoluciona y se adapta a los cambios.
“Nadie quiere pasar años, creando un producto que nadie quiere” Ash Maurya, author of Running Lean
Nuevas metodologías y marcos de trabajo, como Lean, Design Thinking, Lean UX o Customer Journal entre otros, están orientadas a resolver las preguntas: ¿Los clientes quieren nuestras soluciones?, ¿Estamos resolviendo los verdaderos problemas de nuestros clientes? y para luego proceder con la entrega de este valor están las otras herramientas como Scrum o XP.
Entregar todo lo que los clientes quieren, no siempre es suficiente…o rentable
Las fuentes de ideas para productos tecnológicos pueden venir de muchos lugares: proyectos de los stakeholders, solicitudes de clientes, la competencia, nuestro equipo, propuestas de partners, …y sobran fuentes para ideas; pero estadísticamente, según un estudio realizado en el Harvard Business Review: Digital Transformation Is Not About Technology el 70% de esas ideas No tendrán el impacto que deseamos en el negocio, está claro que no podemos construir todo lo que se propone como una idea.
Bajo esta premisa, por ejemplo, si nos enfrentamos a un trabajo de al menos 12 features al año + otros gastos en los que incurre la empresa para el desarrollo de Software podríamos tener un costo de digamos $7500 mensual, y una inversión anual de $90000.
Siguiendo el 70/30 tenemos un desperdicio del $63000 de esa inversión; afortunadamente el negocio logra generar los resultados necesarios para que estas funcionalidades rentables generen más que lo invertido en el desarrollo total, teniendo una balanza a favor, aunque está claro que hubo un importante desperdicio.
¿Qué pasaría si puedo identificar lo antes posible las funcionalidades que SÍ generan el retorno que necesitamos?
Muchas personas se hicieron la misma pregunta, lo que derivó en la evolución de la forma de hacer Product Discovery. Entonces ya no es suficiente solucionar problemas, sino que además se debe generar soluciones que la gente quiera o por las que está dispuesta a pagar. Hablamos de identificar esa solución que me va a permitir alcanzar mis oportunidades en el mercado con el máximo retorno de la inversión.
Históricamente las empresas que lograron aplicar este enfoque resolviendo el problema/ la necesidad realmente importante alcanzaron una oportunidad y trascendieron.
Einstein decía a sus alumnos que si él tuviera una hora para resolver un problema usaría 55 minutos en analizar el problema para llegar a un diagnóstico certero, y una vez conociendo las causas, tardaría 5 minutos en encontrar una solución. En el mundo del Software, nos obsesionamos con las caracteristicas (features) cuando deberíamos estar obsesionados con los resultados que estamos creando para nuestros clientes y para nuestro negocio.
Entonces, ¿Cuál es la meta de Product Discovery?
Es aprender rápido, estamos en una industria en la que aprender, y aprender rápidamente es la cosa más importante para reducir el riesgo de un fracaso mayor, para discernir si lo que vamos a construir es realmente lo que necesitamos construir
Y con cada metodología (Design Thinking, Lean,Agile, OKRs) empezamos a responder preguntas más temprano durante el proceso para encontrar ese producto que nos permita alcanzar una oportunidad en el mercado entregando valor real al cliente y a nuestra organización.
Categorías
Tags
Contactos
De las Alondras, E10-115
+593 979 733 071
olivia@softwareevolutivo.net
8:30am-6:00pm