Tabla de contenidos
La concepción del producto y roadmapping es un factor clave en el éxito de cualquier empresa basada en productos. Aunque la mayoría de las startups comienzan su actividad con una buena idea o detectando una necesidad en el mercado que no ha sido satisfecha, y comienzan su desarrollo de forma más bien «anárquica» o sin un producto claro en mente, existen muchas herramientas y metodologías que pueden ayudarles a darle forma desde las primeras etapas de su actividad.
El uso de un proceso sólido para concebir y desarrollar productos les puede ayudar a ahorrar tiempo y dinero y a maximizar la tasa de éxito, y se complementa perfectamente con el hecho de seguir una corazonada.
Concepción del producto y roadmapping
El proceso que se presentará en este artículo consta de 4 pasos bien conocidos, ya que muchos autores presentan la misma diferenciación – siendo uno de los más notables Roman Pichler (1):
Figura 1 – Fases de concepción y planificación del producto.
Este artículo tiene como objetivo proporcionar una revisión del proceso de concepción del producto y presentar algunas técnicas que pueden ser utilizadas en cada paso del proceso. Y, antes de entrar en detalles, el conjunto de técnicas y los procesos que presentaré son los que uso y funcionan mejor para mí, pero no tengo intención de pintarlos como los «mejores» métodos que existen. Esto es 100% subjetivo ?
La idea inicial: Transformar una corazonada en la semilla de un producto
«¡Hey! Estoy harto de…»
«Estaría bien si tuviéramos…»
Todo empieza aquí. Algún margen de mejora, alguna posibilidad de innovación, algún dolor que se pueda aliviar. En el artículo anterior sobre la figura del product owner presenté un producto como algo que satisface una necesidad del cliente. Desde una perspectiva de marketing, es una definición de producto ampliamente aceptada.
Cuando tenemos este tipo de «revelación» tendemos a hacer un salto de tres años en el futuro e imaginarnos cómo podría ser nuestra idea como producto, pero el hecho es que ni siquiera sabemos si la gente estaría dispuesta a pagar por ella.
Hay dos cosas que me gusta hacer con estas «ideas iniciales»: trabajarlas un poco en profundidad y ver qué tipo de necesidad podrían satisfacer, qué personas estarían interesadas en ellas y por qué.
Uno de los primeros ejercicios que hay que hacer cuando se acuña la idea de un nuevo producto es hacer preguntas a la gente, y para ello tenemos que saber a quién le vamos a hacer preguntas. Es muy importante tener un conocimiento previo de cuál es nuestro segmento de mercado y obtener retroalimentación directa sobre nuestra idea: queremos saber si podría ser útil, si generará expectativas y cuánto estaría dispuesto a pagar por ella nuestro segmento. Existen varias herramientas para obtener este tipo de información, pero empezar con un buen cuestionario utilizando los formularios de Google y difundirlos entre tus amigos y familiares puede ser muy útil y darte una primera impresión sobre el potencial de tu idea.
Otro buen ejercicio a realizar al principio del proceso es encontrar la posición de nuestra idea en la estructura de necesidades de nuestro segmento. La pirámide de Maslow (3) es un sistema de jerarquía de necesidades muy conocido, pero me parece demasiado amplia para aplicarla al producto digital. Almquist, Senior y Bloch propusieron una extensión de la pirámide de Maslow en un artículo llamado «The elements of value» (4) que introduce una clasificación de necesidades más adecuada para el producto digital, como se muestra en la figura 1.
Lo que me parece interesante de este último artículo es que los autores proponen no sólo una pirámide que representa la prioridad de las necesidades de los usuarios finales, sino que también establecen qué atributos valoran más los usuarios en función del segmento de mercado o producto. Una de sus conclusiones es que las empresas que obtienen mejores resultados que sus competidores cuidan mejor los atributos importantes. Finalmente, en relación con este enfoque, cabe destacar que Almquist et al. publicaron un artículo similar en 2018 sobre las empresas B2B, «The B2B elements of value» – (5). También es muy interesante.
Cuando tenemos una idea inicial que queremos convertir en producto, es muy importante tener un concepto claro de lo que nuestro cliente potencial piensa de nuestro producto, qué es lo que más valora y cómo podemos hacerlo mejor que la competencia. Debemos mantener esta información como una prioridad durante todo el ciclo de vida del producto y estar abiertos a adoptar cambios si es necesario.
Figura 2 – Elementos de la pirámide de valor propuesta por Almquist et al.
¿Qué obtenemos de este paso?
Esta fase tiene como objetivo definir las coordenadas de nuestro producto. Tenemos un concepto, luego necesitamos tener una idea inicial de cuál es nuestro segmento de mercado y cuáles son los atributos más importantes para su éxito, es decir, los más valorados por nuestros usuarios.
De una semilla a una propuesta de valor: Lienzo de proposición de valor y análisis Kano
Llegados a este punto tenemos una amplia idea de qué necesidad satisface nuestro producto, dónde encaja en la pirámide de valor del usuario y cuales son los atributos que más tienen en cuenta nuestros clientes.
Es hora de hacer algunas preguntas:
- ¿Quiénes son nuestros usuarios/clientes? (no sólo el segmento de mercado, sino también sus hábitos, tendencias, etc.)
- ¿Por qué querrían el producto? ¿Pagarán por él?
- ¿Qué hace que nuestro producto sea diferente?
- ¿Podríamos construir una masa crítica para que el negocio sea sostenible y rentable?
Con esta información básica junto con nuestra idea inicial, una buena práctica es mapear el valor de nuestro producto con las necesidades de nuestros clientes – Yo utilizo el Lienzo de Propuesta de Valor o Value Proposition Canvas(6), VPC de ahora en adelante.
Figura 3 – La estructura del Lienzo de Proposición de Valor (VPC) tal y como la presenta Osterwalder.
El VPC nos ayuda a mapear las necesidades de los clientes con nuestra propuesta de producto. Coloca al usuario en el lado derecho -círculo rojo- frente a nuestra propuesta, en el lado izquierdo (nuestra propuesta de valor). De derecha a izquierda, mapeamos lo que el usuario quiere hacer (trabajos) con los productos o servicios que ofrecemos (Productos y servicios); lo que le gusta de este proceso con lo que proponemos que le puede hacer feliz (Ganancias vs. Creadores de Ganancias) y lo que le odia o disgusta con lo que le puede reducir esta sensación negativa (Dolores vs Alivios). El lado izquierdo del lienzo de la proposición de valor puede contener algunas características específicas, pero también ideas para ser elaboradas en etapas posteriores.
Este mapeado proviene directamente de la información que obtuvimos en el paso anterior (nuestra idea inicial, los comentarios de los usuarios y los atributos que más se valoran en nuestro sector, información sobre la competencia, las preguntas que nos hicimos, etc.) y nos da la base de lo que tenemos para ofrecer, qué características u operaciones deben estar disponibles con nuestro producto.
Ahora es el momento de pasar del dominio de las ideas al dominio de las características del producto y proponer el conjunto de funcionalidades que tendrá nuestro producto. Para tal fin, las herramientas que mejor funcionan son el trabajo con grupos focales y las sesiones de brainstorming. Personalmente, me gusta subirme a una habitación con el equipo y un pequeño grupo de usuarios y empezar a escribir las características en post-its, engancharlas en una pared y luego agrupar las que se relacionan en torno a temas, creando un diagrama de afinidad para reunir lo que nuestro producto tiene para ofrecer. (Éste proceso se puede hacer en ambas direcciones; podemos empezar pegando los temas principales y añadir luego las funciones).
Figura 4 – Un diagrama de afinidad sobre una pared, una herramienta muy útil para el brainstorming.
Sin embargo, debemos tener mucho cuidado. Hasta ahora hemos buscado activamente las características o atributos más valorados por nuestros clientes, pero un producto es más que eso; según Kano (7), podemos clasificar las características de un producto en 3 grupos:
- Atributos básicos: Características que deben estar en el producto, de lo contrario el producto no será considerado como una opción por el usuario final. Por ejemplo, podríamos considerar un depurador integrado en un IDE de desarrollo como una característica básica.
- Atributos de rendimiento (o calidad unidimensional): Un atributo de rendimiento es una característica que se relaciona directamente con el nivel de satisfacción del cliente. Siguiendo nuestro ejemplo de desarrollo IDE, tener un proceso de compilación rápido e inteligente sería un atributo de rendimiento.
- Atributos atractivos. Estas son las cualidades que no son necesariamente esperadas por el cliente (necesidades desconocidas) pero que cuando se presentan tienen un impacto positivo en su satisfacción. Estas son las características clave que proporcionarán el mayor margen y las más potentes, ya que las características atractivas son las que entusiasman a nuestros usuarios. Visual Studio live share, que permite colaborar remotamente en tiempo real en la creación de código, es un buen ejemplo de atributo atractivo
Consejo – Construye una visión de producto compartida!
Las reuniones de brainstorming para crear mapas de afinidad de características son una oportunidad perfecta para construir una visión de producto compartida y alinear a todo el equipo hacia el mismo objetivo. Las reuniones de afinidad deben tener un moderador que acepte, discuta y explique cada característica. Mi recomendación es tener al PO como moderador de estas reuniones, y aprovechar esta ventaja para hablar sobre la visión del producto y tener a cada miembro involucrado en el proceso. Se visual, usa herramientas, pide retroalimentación, etc. . . Las reuniones deben ser muy dinámicas!
Una de las conclusiones del modelo Kano es que los atributos atractivos se convierten en atributos de rendimiento con el tiempo. Esto tiene mucho sentido, ya que el usuario no puede sorprenderse siempre por lo mismo; una vez que se ha familiarizado con este atributo atractivo, pasa a convertirse en uno de rendimiento, porque el cliente lo esperará en la siguiente iteración…. y en la competencia.
Otra conclusión es que las características básicas son algo que nuestro producto debe ofrecer, de lo contrario ni siquiera será considerado por nuestro segmento objetivo. Es crítico tener esto en cuenta de cara a construir el mapa de afinidad: el equipo debe estudiar a la competencia y enumerar todas las características básicas que nuestro futuro producto debe contener, incluso si no proporcionan ninguna ventaja competitiva, porque son obligatorias para mantenernos en el juego.
El modelo kano se representa fácilmente como se ve a continuación:
Figura 5 – El modelo Kano.
El objetivo principal de realizar un análisis de Kano es etiquetar cada una de las características que hemos recopilado para saber cuáles nos ayudarán a igualar a la competencia, cuáles nos proporcionan una ligera ventaja y cuáles son una ventaja competitiva.
Tener todas las características etiquetadas nos ayudará a priorizar, analizar las prioridades entre ellas, y tener la información necesaria para planificar la introducción de los productos en el mercado.
Consejo – Fracasa temprano y rápido
Es casi imposible clavar un concepto de producto empezando de cero. Es probable que la idea básica del producto vaya por buen camino, pero nos hayamos dejado algunas características, tengamos un enfoque equivocado o haya margen de mejora. Involucra a los clientes desde el principio. Obtén retroalimentación tan rápido como puedas. Debes estar preparado y abierto a cambiar las cosas y modificar tu VPC, temas, características o modelo de negocio. Cuanto antes alinees tu producto con las necesidades de tus clientes, mejor.
¿Qué obtenemos de este paso?
La segunda etapa de la planificación del producto nos da una lista específica de temas y características, junto con información relacionada muy valiosa: Cómo estas características agradan a nuestros usuarios o responden a sus necesidades, y una etiqueta (Kano) que indica cómo los usuarios percibirán estas características.Al final de este paso debemos estar listos para planear cómo vamos a distribuir las características con el tiempo.
Mapas de historias de usuario
Los mapas de historias de usuario fueron introducidos por primera vez por Jeff Patton en 2005 (8). Un mapa de historias de usuario es un método poderoso y visual para presentar cómo el usuario interactuará con el producto, mostrando los temas y características que se han reunido en el paso anterior.
Patton hizo la siguiente consideración sobre el uso de los tradicionales backlogs frente a los mapas de historias de usuario (9):
«Pasamos mucho tiempo trabajando con nuestros clientes. Trabajamos duro para entender sus objetivos, sus usuarios y las principales partes del sistema que podríamos construir. Luego, finalmente, llegamos a los detalles: las piezas de funcionalidad que nos gustaría construir. En mi cabeza veo un árbol donde el tronco se construye a partir de las metas o beneficios deseados que impulsan el sistema; las ramas grandes son los usuarios; las ramas pequeñas y las ramitas son las capacidades que necesitan; finalmente las hojas son las historias de los usuarios, suficientemente pequeñas como para colocarlas en iteraciones de desarrollo.
Después de todo ese trabajo, después de establecer todo ese entendimiento compartido, siento que sacamos todas las hojas del árbol y las cargamos en una bolsa de hojas – luego cortamos el árbol.
Eso es lo que un backlog plano es para mí. Una bolsa de mantillo sin contexto»
Jeff Patton
Mi opinión personal sobre esta confrontación de backlog vs mapa de historias de usuario es que ambos son 100% compatibles, incluso complementarios.
Figura 6 – Imagen que ilustra la diferencia entre backlog y un mapa de historias de usuario.
Pero sí creo que el mapa de historias de usuario debería ser el punto de partida de la planificación formal del producto.
Para construir un mapa historias de usuario, tomaremos los resultados del paso anterior y haremos lo siguiente:
- Usaremos una pizarra o una pared y pegaremos los temas que hemos descubierto en el paso anterior. Cada tema será el encabezado de una columna; Patton lo llama Backbone (Columna Vertebral).
- Debajo de cada tema del backbone, pegaremos todas las características del tema en cuestión de arriba a abajo de la pared.
- En la fila superior de las características, justo debajo del backbone, pondremos las historias que conforman el MVP del producto, que es el conjunto mínimo de características que se necesitan para llevar el producto al mercado. Esto se llama el esqueleto del producto.
- Estas características deben ser colocadas en orden: en el paso anterior hemos analizado las precedencias entre las características (no queremos colocar «filtrado avanzado para la búsqueda» antes de introducir una «función de búsqueda básica«, por ejemplo). Ordenamos de arriba hacia abajo, de la más alta prioridad a la más baja.
Idealmente, deberíamos conseguir algo como esto:
Figura 7 – Ejemplo de iteración inicial de un mapa historias de usuario.
Algunas lecturas sugieren que los mapas de historias de usuario también deben tener un orden de izquierda a derecha que represente el orden del “viaje del usuario”. Mi recomendación: no te lo tomes al pie de la letra; hay casos en los que esto se puede aplicar de forma sencilla, sin embargo, en otras ocasiones el producto tiene tantos inputs y flujos que aplicarlo se vuelve demasiado complejo. Solo intenta ordenar de izquierda a derecha lo que en tu mente sea el camino lógico del producto.
¿Qué obtenemos de este paso?
El mapa de historias de usuario estructura el mapa de afinidad y traza la línea temporal de cada tema de nuestro producto. Una vez tengamos esto, obtendremos una presentación visual de las partes críticas de nuestro producto y una visualización paso a paso de cómo evolucionará cada característica con el tiempo.
Planificación de lanzamientos
El paso final consiste en «cortar» (honrando el artículo de Patton) nuestro mapa de historia de producto en lanzamientos. Para esta tarea, haremos uso de toda la información recopilada en los pasos anteriores: VPC, etiquetas Kano y el mapa de la historia del usuario.
Hay varias normas que, en mi opinión, deberían respetarse en el proceso de planificación lanzamientos:
- Un lanzamiento siempre debe tener un propósito y una meta clara.
- Las especificaciones deben ser muy claras.
- Debe haber una definición concisa de «done».
- Cada lanzamiento debe proporcionar un incremento en la ventaja competitiva del producto.
Hay dos formas tradicionales de planificar las versiones de producto, la tradicional ofrecería una actualización equilibrada de todos los temas del producto y una alternativa sería hacer un incremento más significativo de uno o dos temas en cada versión.
La Figura 8 muestra un plan de lanzamientos de enfoque tradicional, y la Figura 9 un plan de lanzamientos de los avances verticales.
Figura 8 – Ejemplo de un mapa de historias de usuario dividido en lanzamientos, con un plan equilibrado
Figura 9 – Ejemplo de un mapa de historias de usuario dividido en lanzamientos con un plan desequilibrado
Si quieres ver ejemplos de historias de usuarios que hemos elaborado en apiumhub puedes ver el artículo que te he mencionado. En él, no solo abordamos la definición sino los casos de usos y ejemplos prácticos. Además te damos consejos de cómo escribir buenas historias de usuario.
Personalmente, me gusta estar abierto a ambas alternativas y combinarlas. Dependiendo del contexto (feedback de los usuarios, mercado y competencia, etc.) podemos optar por el más conveniente.
Si tenemos un producto con lanzamientos periódicos (lanzamientos anuales, por ejemplo), proporcionaremos un lanzamiento anual equilibrado, pero dependiendo de las tendencias del mercado podemos tener lanzamientos desequilibrados entre los lanzamientos anuales que nos ayuden a igualar una nueva característica lanzada por la competencia o traer al mercado una nueva funcionalidad que nos sitúe a la cabeza tan pronto como sea posible.
Consejo – ¿Cómo enfocamos el roadmapping?
El factor clave para el éxito del producto es poder presentar características que lo diferencien de sus competidores y se ajusten a las necesidades del cliente. En mi opinión, un roadmapping siempre debe aspirar tanto a conseguir características atractivas que le proporcionen una ventaja competitiva al producto como a cubrir las características básicas. Hay varios factores que pueden afectar a un plan de lanzamiento: campañas de marketing o nuevas características lanzadas por productos similares a las que debemos reaccionar. El PO debe tener en cuenta todos los elementos a la hora de planificar o adaptar un plan de lanzamientos.
Preparación y desarrollo del backlog del producto
Una vez que tengamos definido el roadmapping, es hora de preparar el backlog y planificar los sprints y las estimaciones. Este es el paso final de nuestra planificación, el punto con el que todos los desarrolladores agile están familiarizados ya que el proceso es muy conocido:
- El Product Owner informa al equipo sobre los objetivos y el propósito del lanzamiento, proporcionando el mayor contexto posible y asegurándose de que todo el equipo de desarrollo está en la misma página y tiene la misma visión sobre la tarea que se avecina.
- El Product Owner revisa todas las Historias de Usuario que pertenecen a la versión, se asegura de que contienen toda la información necesaria y los criterios de aceptación e información de prioridad.
- El equipo de desarrollo junto con el Scrum Master o facilitador de proyectos proporcionan una estimación inicial de la historia de cada usuario.
- El equipo prepara los sprints, asignando tareas y definiendo objetivos intermedios.
- Comienza el ciclo de desarrollo.
Conclusiones: concepción del producto y roadmapping
Los apartados anteriores nos han llevado a través de un viaje que comenzó con una intuición inicial de lo que podría ser un producto hasta el inicio de su desarrollo.
Como ya he mencionado, este es un enfoque que funciona para mí, y en mi experiencia es similar a lo que hacen la mayoría de las empresas, pero de ninguna manera es algo sagrado.
También es muy importante tener en cuenta que todo este proceso está vivo y en constante cambio. El mercado nunca se detendrá para darnos feedback, la competencia nunca dejará de avanzar y las tendencias siempre estarán cambiando, y por supuesto, nuestros equipos estarán generando nuevas ideas día a día. El Product Owner debe saber hacer malabarismos con todos estos factores y adaptar el roadmapping cuando sea necesario.
Lo que me parece más importante es tener un proceso bien definido como empresa. Uno de los errores más comunes de las nuevas empresas es abordar la concepción del producto y el roadmapping de forma bastante caótica. Esto es a menudo compensado a base de pasión y horas de trabajo, pero cuando las empresas crecen y tienen más experiencia, entienden la importancia de este proceso.
Hay varios temas que no han sido discutidos en este texto – UX/UI, el manejo de la deuda técnica o de código vs. los nuevos desarrollos, una discusión sobre cómo abordar el establecimiento de prioridades, etc. – que se han dejado de lado en aras de la claridad; espero poder tratar estos temas en artículos venideros.
Bibliografía: Concepción del producto y roadmapping
1. Pichler, Roman. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age. s.l. : Pichler Consulting, 2016. 0993499201.
2. Felip, Ramon. Product Leader – Not (only) agile. Apiumhub Tech Blog. [Online] 6 28, 2018. https://apiumhub.com/tech-blog-barcelona/product-leader/
3. Wikipedia. Maslow’s hierachy of needs. Wikipedia. [Online] https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs.
4. Eric Almquist, John Senior, Nicholas Bloch. The Elements of Value. Harvard Business Review. [Online] 09 1, 2016. https://hbr.org/2016/09/the-elements-of-value.
5. Eric Almquist, Jamie Cleghorn, and Lori Sherer. The B2B Elements of value. Harvard Business Review. [Online] 03 01, 2018. https://hbr.org/2018/03/the-b2b-elements-of-value.
6. Osterwalder, Alexander. Achieve product–market fit with our brand-new Value Proposition Designer Canvas. Businessmodelalchemist.com. [Online] 08 29, 2012. http://businessmodelalchemist.com/blog/2012/08/achieve-product-market-fit-with-our-brand-new-value-proposition-designer.html.
7. Attractive quality and must-be quality (Journal of the Japanese Society for Quality Control). Kano, Noriaki, et al. Tokyo : s.n., 1984.
8. Patton, Jeff. It’s how you slice it. Jeff Patton and Associates. [Online] 01 2005. https://www.jpattonassociates.com/wp-content/uploads/2015/01/how_you_slice_it.pdf.
9. —. The new user backlog is a map. Jeff Patton and Associates. [Online] 2008. https://www.jpattonassociates.com/the-new-backlog/.
Y no te olvides de suscribirte a nuestro boletín mensual para recibir las últimas tendencias e información sobre concepción del producto y roadmapping.
Si este artículo sobre concepción del producto y roadmapping te gustó, te puede interesar:
Beneficios de la metodología ágil
Los beneficios de la tecnología Scrum
Beneficios de la integración contínua
¿Porque debería usar Docker en mi proyecto de desarrollo?
Beneficios de la pruebas unitarias
La importancia de las retrospectivas en la metodología Ágil
Simular respuestas del servidor con Nodejs
Principio de responsabilidad única
Arquitectura de microservicios
