Product Discovery: Identificar el problema y el valor único
•Download as PPTX, PDF•
2 likes•1,800 views
Taller realizado en el Agiles 2015 en Montevideo
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Product Discovery: Identificar el problema y el valor único
Similar to Product Discovery: Identificar el problema y el valor único (20)
Recently uploaded
Recently uploaded (20)
Product Discovery: Identificar el problema y el valor único
- 1. Product Discovering Que preguntarse antes de iniciar un proyecto Octubre 2015 Jorge Silva - @jor_silva – jsilva@10pines.com
- 3. “The hardest single part of building a software system is deciding precisely what to build.” -Fred Brooks, autor de “No Silver Bullet”
- 4. ////// ¿Qué se preguntan cuando empieza un proyecto?
- 5. ////// Cual es el problema? Cada uno tiene una idea diferente de que construir No sabemos muy bien que queremos Que conviene hacer primero? Da lo mismo? Como lo identificamos?
- 6. ////// Cual es el problema? Product Discovery
- 7. //////QueesentonceselProductDiscovery? Es un taller… Conocimiento validado de 5 años de experiencias Es practica puesta en teoria…
- 8. 1 2 4 3 > Unique Value Proposition > Elevator Pitch > Story Mapping > Complementos //////Lospasosaseguir > Flujo de negocio 5
- 9. ////// Unique Value Proposition 1
- 10. 1 ////// Algunos buenos ejemplos de UVP
- 12. Para Quienes El Es un Que A diferencia de Nuestro proyecto <<Template de Elevator Pitch>> <<Usuario objetivo>> <<Necesidad u oportunidad>> <<Nombre del proyecto>> <<Categoria del producto>> <<Beneficio clave>> <<Diferenciacion principal>> <<Competencia/metodo tradicional>>
- 13. ////// Algunos ejemplos reales
- 15. Nuestra receta para un Story Mapping feliz 4 2. Nos repartimos las actividades por persona y escribimos las tareas para cada actividad 3. Priorizamos (método del 20/30/50) 4. Identificamos el MVP 1. Tomamos las actividades del workflow y las llevamos en linea de tiempo al tablero
- 16. El resultado final: Historias listas para contar 4
- 18. El producto final: Product Discovery
- 19. Análisis Desarrollo Validación UsuarioNegocio Contexto Product Discovery Salida Producción Como se sigue?
- 20. ////// Algunas consideraciones 1. Incluir a todas las personas involucradas 2. El proceso completo puede llevar unos 2 o 3 dias 3. Se puede usar como herramienta de preventa o venta 4. Confianza con el cliente 5. Objetivo: "Que nos alineemos” 6. Permite tener un mayor entendimiento del negocio y del problema. 7. Sacamos/identificamos desperdicio/vicios 8. Concientización del costo de hacer software 9. Construcción colectiva del alcance. 10. Emergente: Tomar el producto como propio. Aumenta el compromiso 11. El ejercicio de las priorizaciones, pone de manifiesto las limitaciones, y se obliga a moderar las expectativas 12. La incertidumbre no se anula, se reduce 13. Ejercicio para mejorar la comunicación con el equipo 14. Se reduce la ambigüedad y las asunciones 15. Se baja y esparce el entendimiento de lo que hay hacer
- 21. Conclusion Final El Product Discovery es una herramienta que nace y toma su fuerza con la colaboración. La colaboración y participación traen consigo el compromiso. Y el compromiso significa un proyecto exitoso
- 23. agile software development & service ////// Información de contacto Alem 693 5ºB (1001) - Buenos Aires - Argentina +54 (11) 6091-3125 Info@10pines.com www.10pines.com @10pines
Editor's Notes
- Que problemas tienen cuando empiezan un proyecto? Cada uno tiene una idea diferente <imagen de pensamientos diferntes> No esta muy definido que construir No sabemos bien que queremos Muchas ideas, poco orden Que conviene hacer primero? Da lo mismo? Como lo identificamos?
- El PD es un taller, compuesto de varias actividades que ayuda a cursar las problematicas identificadas anteriormente Es un taller que surge de la practica <es practica puesta en teoria> Surge de un proceso continuo de aprendizaje sobre varios proyectos realizados en 10P durante los ultimos 5 años
- Unique Value proposition Elevator pitch Flujo de negocio Story mapping (custom) Otras Que no nos deja dormir Trade off Sliders A-Team
- Es una de las cosas mas importantes, y de las mas dificiles Destilar la escencia del producto que estamos por construir, en unas pocas palabras Imagina que una persona entra a tu sitio, ve este UVP y en 10 segundos que lee, tiene que entender el valor que agregas con esto. “Unique Value Proposition: A single, clear compelling message that states why you are different and worth buying.” by S. Blank Ejemplos de UVP Leer un poco mas el lean canvas
- Contar la historia del nombre, pensar una buena historia Hacer un elevator pitch planteando un ejemplo (pensar un ejemplo) Vineria online? Buscar ejemplos en internet Un producto conocido? ML? Amazon? Mostrar el template Imagenes de ejemplos
- Toda desarrollo de software tiene un dominio. Ese dominio, de ese dominio tomamos un recorte de la realidad para modelarlo con un sistema en forma de software en la computadora. Este software que vamos a desarrollar, tiene asociado una serie de actividades que surgen del negocio que estamos representando de la realidad. <imagen mapeando realidad con computadora y programador> La idea es identificar las principales actividades del proceso de negocio que estamos a punto de trabajar Las actividades Empiezan con verbos No ensusiarlas con herramientas tecnologicas Alto nivel (tampoco un nivel como “hacer sistema”) Quienes son los que mejor saben esto? Los mismos usuarios potenciales del sistema, los involucrados en el sistema.
- Para una efectiva priorizacion, definir bien que salidas requiere la aplicación. Esto esta muy atado a que objetivos tiene el sistema. Esto basicamente define el espiritu del sistema. Luego, se define que entradas deberia tener. Output => outcome => Impact (como sabemos que estamos teniendo impacto?? De esto habla mucho el libro Lean Startup de Eric Ries)
- Una vez que se tienen las actividades, se empiezan a desmenuzar en tareas Por ejemplo… Esto lleva unas 4 a 8 horas dependiendo el tamaño del sistema a construir. Se puede partir en dos la sesion Luego se prioriza en 3 niveles Aca es importante tener en cuenta el objetivo de negocio (identificado previamente) Identificamos lo que seria el MVP en la primera prioridad Luego podria llegar a estimarse cada tarea y estimar cuanto puede llevar el primer release/entregable
- Que no nos deja dormir Identificar riesgos en forma de probabilidad de ocurrencia x impacto => importancia => plan de accion: mitigarlo, eliminarlo, etc Diferencia entre mitigar/tratar/evitarlo/etc Trade off Sliders Sirve para medir y obligar al cliente a priorizar que es mas importante y que vea que no todo puede ser importante. Sirve para que en el momento de tener que tomar decisiones rapido, se tiene decidido que es mas importante A-Team Identificamos los roles mas importantes Identificamos a las personas que van a estar trabajando Las personas son lo mas importante en un proyecto, sin
- Algo que nosotros cambiamos fue que en lugar de separa en layer/release, separamos en layers/prioridad. De esta forma, definimos/obligamos/ayudamos a poner prioridad a las cosas a hacer.
- Que problemas tienen cuando empiezan un proyecto? Cada uno tiene una idea diferente <imagen de pensamientos diferntes> No esta muy definido que construir No sabemos bien que queremos Muchas ideas, poco orden Que conviene hacer primero? Da lo mismo? Como lo identificamos?