martes, abril 29, 2025
martes, abril 01, 2025
domingo, marzo 23, 2025
lunes, marzo 17, 2025
Los formatos de las historias de usuario: más allá de los estándares populares
Hola a todos,
En el mundo ágil, a menudo se cree que las historias de usuario deben seguir un formato único y establecido. Sin embargo, la realidad es que no hay un solo formato universalmente correcto. La propuesta inicial era una petición de máximo un renglón (1). Nunca ha habido un formato oficial, lo que si ha existido, son propuestas muy usadas. La forma más clásica y ampliamente adoptada, es la propuesta por Rachel Davies y popularizada por Mike Cohn (2), se centra en quién usa el sistema, qué quiere lograr y por qué es importante:
- "Como <rol>,
- quiero <acción o funcionalidad>,
- para <beneficio de negocio>".
Ejemplos:
- Como comprador en línea, quiero poder filtrar productos por precio, para encontrar opciones dentro de mi presupuesto más rápidamente.
- Como gerente de recursos humanos, quiero recibir notificaciones cuando un nuevo empleado complete su documentación, para agilizar el proceso de incorporación.
- Como usuario de la aplicación de transporte, quiero poder calificar mi viaje después de llegar a mi destino, para mejorar la calidad del servicio.
¿Cuándo usarlo?
- Cuando se necesita claridad en el propósito de la historia.
- Para equipos nuevos en metodologías ágiles que aún están aprendiendo a formular historias de usuario.
Otro muy popular es el propuesto por Barry O'Reilly y conocido como Hypothesis Driven Development (desarrollo dirigido por hipotesis) (3):
- "Creemos que <hacer este cambio funcionalidad>,
- resultará en <impacto medible>,
- sabremos que habrá sucedido cuando <observemos este señal medible>",
- "Creemos que <hacer este cambio funcionalidad>,
- para <este grupo de usuarios>,
- resultará en/no impactará / impactará / aumentará/reducirá <impacto medible>,
- sabremos que habrá sucedido cuando <observemos este señal medible>"
- en/durante <una fecha determinada>,
Ejemplos:
- Creemos que permitir a los usuarios registrarse con su cuenta de Google, para nuevos visitantes del sitio web, resultará en un aumento de la tasa de registros en un 20% en dos semanas. Lo sabremos cuando la métrica de conversión pase de 25% a 45% en un tiempo máximo de 3 meses después de salir a producción.
- Creemos que ofrecer una opción de “modo oscuro” en nuestra aplicación, para usuarios frecuentes, resultará en una mejora en la retención semanal en un 10%. Lo sabremos cuando la retención W1-W2 pase de 30% a 33% en dos semanas luego del lanzamiento oficial.
- Creemos que aumentar el precio mensual de $10 a $12, para usuarios que han estado más de 3 meses suscritos, no impactará negativamente la tasa de renovación. Lo sabremos si la tasa de cancelación se mantiene bajo el 5%, durante el mes próximo del lanzamiento del cambio.
- Creemos que permitir ordenar los resultados por “más vendidos” para compradores indecisos, aumentará la conversión en un 15%. Lo sabremos si la tasa de clics en productos y las compras en esa categoría aumentan en ese porcentaje, en las próximas 4 semanas después del lanzamiento.
¿Cuándo usarlo?
- Estás creando un producto nuevo o una funcionalidad no probada.
- Hay mucha incertidumbre sobre el valor o la necesidad de lo que estás construyendo.
- Quieres reducir el riesgo de desarrollar algo que nadie usará.
- Tu organización valora el aprendizaje y la mejora continua.
- Estás en fases tempranas de descubrimiento o validación de mercado.
Las historias de usuario son un arte tanto como una técnica, y deben adaptarse a las necesidades específicas de cada organización, equipo y contexto. Lo esencial es que cumplan su propósito: capturar la necesidad de negocio desde la perspectiva del usuario, servir como una invitación a la conversación y permitir la colaboración para entregar valor incremental.
En este artículo exploraré varios formatos alternativos de historias de usuario que pueden resultar útiles en contextos diversos. Si bien en el libro de historias de usuario (4) y en este blog (5) ya habíamos analizado distintos modos de representación según la madurez del equipo, el nivel de regulación o la cultura organizacional en la que operan, en esta ocasión ampliaré la mirada hacia otras plantillas que también pueden ser efectivas y adaptables.
Avancemos entonces, y descubramos juntos estas nuevas propuestas.
Nota importante: las plantillas sugeridas, requieren de seguir cumpliendo la buena práctica de las 3C, cumplir con INVEST, e incluir criterios de aceptación, que se han enumerado bastantes veces en esta blog.
Algunos formatos sugeridos y sus posibles usos
1. El formato centrado en el problema: "Cuando – Entonces - Porque"
Este formato enfatiza el contexto y la causa raíz del problema que la historia intenta resolver.
Estructura:
- Cuando:[situación]
- Entonces: [acción]
- Porque: [motivación]
Ejemplos:
- Cuando el usuario agregue productos al carrito y cierre sesión sin comprarlos, entonces le enviaremos un recordatorio por correo electrónico, porque queremos aumentar la conversión de ventas.
- Cuando un usuario ingrese una contraseña incorrecta más de tres veces, entonces bloquearemos su cuenta temporalmente, porque queremos prevenir accesos no autorizados.
- Cuando el sistema de facturación detecte una inconsistencia en el número de documento del cliente, entonces alertaremos al equipo de soporte, porque queremos reducir los errores en la generación de facturas.
¿Cuándo usarlo?
- Cuando el equipo esté enfocado en resolver problemas específicos del usuario.
- En entornos donde se requiere justificar cada funcionalidad con un problema de negocio claro.
2. El formato inspirado en el comportamiento de BDD (Behavior Driven Development) (6): "Dado que – Cuando – Entonces"
Muy útil en historias de usuario que son de eventos o cuando se necesita precisión en cómo se comportará una funcionalidad. Se sugiere que sus criterios de aceptación sean en prosa.
Estructura:
- Dado que: [contexto],
- Cuando: [acción],
- Entonces: [resultado]
Ejemplos:
- Dado que un usuario ha ingresado una dirección de correo electrónico no verificada, cuando intente iniciar sesión, entonces se le pedirá que confirme su correo antes de continuar.
- Dado que un pago con tarjeta puede fallar por diversos motivos, cuando el intento de pago falle, entonces el sistema debe mostrar el mensaje adecuado según el código de error del proveedor de pagos.
- Dado que el usuario puede realizar múltiples solicitudes de soporte, cuando una solicitud sea resuelta, entonces se enviará una encuesta de satisfacción al usuario.
¿Cuándo usarlo?
- Para historias con criterios de aceptación claros.
- En historias de usuario que están indicando eventos en el sistema.
- En desarrollo de software donde las reglas de negocio son críticas.
3. El formato “Necesidad – Solución – Valor”
Este formato es ideal cuando se quiere conectar claramente el problema, la propuesta y el beneficio entregado.
Estructura:
- Necesidad: [Qué se necesita].
- Solución: [Qué se propone].
- Valor: [Qué se gana].
Ejemplos:
-
Necesidad: Los usuarios necesitan hacer seguimiento de sus gastos mensuales.
Solución: El sistema ofrece un panel con gráficos de gasto por categoría.
Valor: Los usuarios pueden tomar decisiones financieras informadas. -
Necesidad: Los vendedores necesitan saber qué clientes tienen más potencial.
Solución: Algoritmo de puntuación basado en historial de compras.
Valor: Mejora la eficiencia comercial y priorización de esfuerzos. -
Necesidad: El área legal necesita acceder rápidamente a contratos archivados.
Solución: Búsqueda avanzada con filtros por fecha, cliente y tipo.
Valor: Ahorro de tiempo y reducción de errores administrativos.
¿Cuándo usarlo?
- Cuando se busca justificar una funcionalidad ante stakeholders.
- En roadmaps donde se prioriza por impacto en negocio.
4. El formato “Evento – Respuesta – Valor”
Este formato ayuda a detallar cómo el sistema debe comportarse ante eventos específicos.
Estructura:
- Evento: [Qué lo desencadena].
- Respuesta: [Qué hace el sistema].
- Valor: [Por qué esto es útil].
Ejemplos:
-
Evento: Un usuario introduce credenciales erróneas tres veces.
Respuesta: El sistema bloquea temporalmente la cuenta y envía una alerta.
Valor: Protección contra accesos no autorizados. -
Evento: Se confirma el pago de una factura.
Respuesta: Se actualiza automáticamente el estado en el ERP.
Valor: Reducción de tareas manuales y errores contables. -
Evento: Se detecta una caída en el rendimiento del sistema.
Respuesta: Se dispara una alerta al equipo de DevOps.
Valor: Reacción temprana ante posibles incidentes críticos.
¿Cuándo usarlo?
- En sistemas reactivos o eventos disparadores.
- En plataformas con necesidad de respuestas automáticas ante condiciones de negocio.
5. Historias de usuario con “Job Stories”
Las Job Stories se centran en la situación, la motivación y el resultado, dejando de lado el “rol”.
Estructura:
- Cuando [situación],
- quiero [motivación],
- para que [resultado esperado].
Ejemplos:
- Cuando estoy fuera de la oficina, quiero aprobar facturas desde el móvil, para que los pagos no se retrasen.
- Cuando tengo poco tiempo, quiero ver un resumen de métricas clave, para tomar decisiones rápidamente.
- Cuando recibo muchas notificaciones, quiero filtrarlas por prioridad, para enfocarme en lo más importante.
¿Cuándo usarlo?
- En entornos donde el contexto de uso es más importante que el rol.
- En descubrimiento de producto centrado en comportamiento del usuario.
6. El formato “Sentimiento – Necesidad – Solución – Beneficiario”
Este formato incorpora la emoción inicial, que es clave en diseño centrado en el usuario.
Estructura:
- Sentimiento: [Cómo se siente el usuario].
- Necesidad: [Qué requiere].
- Solución: [Qué se le ofrece]
- Beneficiario: [Personas que se benifician de la solución, no siempre es el usuario que hace clic, en ocasiones podrá ser alguien del backend, o cliente interno de la solución"
Ejemplos:
- Sentimiento: Frustrado por la lentitud del proceso de pago.
- Necesidad: Un checkout más ágil.
- Solución: Pago con un solo clic.
- Beneficiario: usuario comprador
- Sentimiento: Inseguro sobre la calidad de un producto.
- Necesidad: Opiniones de otros compradores.
- Solución: Mostrar reseñas verificadas.
- Beneficiario: comprador de la tienda
- Sentimiento: Ansioso por confirmar la reserva de su vuelo.
- Necesidad: Verificación inmediata.
- Solución: Correo con QR y confirmación automática.
- Beneficiario: viajero de la aerolínea
¿Cuándo usarlo?
- En diseño de experiencia de usuario (UX).
- Cuando se desea empatizar con el dolor del usuario.
7. El formato “Deseo – Acción – Satisfacción”
Este formato está inspirado en la motivación humana: qué desea, qué hace, qué obtiene.
Estructura:
- Deseo: [Qué quiere].
- Acción: [Qué hace].
- Satisfacción: [Qué logra].
Ejemplos:
-
Deseo: Sentirme seguro al comprar en línea.
Acción: Uso un método de pago confiable.
Satisfacción: Compro con tranquilidad. -
Deseo: Ser productivo durante reuniones.
Acción: Tomo notas con ayuda de una IA.
Satisfacción: Puedo revisar y compartir de forma eficiente. -
Deseo: Encontrar el mejor producto sin perder tiempo.
Acción: Uso un comparador de productos.
Satisfacción: Elijo lo mejor según mis necesidades.
¿Cuándo usarlo?
- En productos con fuerte componente emocional.
- Cuando se quiere visualizar claramente la satisfacción del usuario como resultado.
8. El formato “Contexto – Sentimiento – Acción – Resultado – Emoción”
Una evolución del clásico formato de flujo, que introduce las emociones como parte esencial de la historia.
Estructura:
- Contexto: [Situación].
- Sentimiento: [Emoción inicial].
- Acción: [Qué hace].
- Resultado: [Qué obtiene].
- Emoción final: [Qué siente después].
Ejemplos:
-
Contexto: El usuario está haciendo una compra online.
Sentimiento: Se siente abrumado por tantas opciones.
Acción: Usa la función de comparación de productos.
Resultado: Ve una tabla clara de diferencias.
Emoción: Se siente aliviado y confiado al elegir. -
Contexto: El colaborador quiere pedir vacaciones.
Sentimiento: Está confundido por el proceso.
Acción: Utiliza un asistente paso a paso.
Resultado: Solicita fácilmente sus días.
Emoción: Se siente tranquilo y comprendido. -
Contexto: El usuario busca soporte técnico.
Sentimiento: Está frustrado por un error recurrente.
Acción: Usa el chatbot para resolver el problema.
Resultado: El problema se soluciona en 2 minutos.
Emoción: Siente satisfacción y fidelidad con el servicio.
¿Cuándo usarlo?
- En productos orientados a experiencia y emoción del usuario.
- Para lograr empatía en equipos multidisciplinarios.
9. El formato “Regla de Negocio – Comportamiento – Resultado Esperado”
Este formato es útil cuando se requiere modelar decisiones automáticas del sistema basadas en reglas de negocio bien definidas. Aporta precisión y trazabilidad en entornos donde las políticas o condiciones deben cumplirse de manera estricta.**
Estructura:
- Regla: [Condición o política de negocio].
- Comportamiento: [Qué debe hacer el sistema].
- Resultado esperado: [Qué debe pasar].
Ejemplos:
- Regla: Si el cliente tiene más de 3 meses de mora.
- Comportamiento: Bloquear automáticamente nuevos créditos.
- Resultado esperado: Se genera una alerta y se deniega la solicitud.
- Regla: Si la fecha de vencimiento del contrato está próxima a 15 días.
- Comportamiento: Enviar notificación automática al responsable.
- Resultado esperado: El contrato es renovado a tiempo o gestionado oportunamente.
- Regla: Si un pedido contiene productos de más de un proveedor.
- Comportamiento: Separar el pedido en órdenes independientes por proveedor.
- Resultado esperado: Cada proveedor recibe la orden correspondiente sin errores de reparto.
¿Cuándo usarlo?
- En funcionalidades que dependen de reglas de negocio bien definidas.
- En contextos donde se busca automatizar decisiones basadas en políticas.
- Para equipos que trabajan con lógica condicional, procesos de backoffice o gestión de riesgos.
Comparativo de formatos de historias de usuario
| Formato | Estructura | Ventaja principal | ¿Cuándo usarlo? |
|---|---|---|---|
| Formato clásico | Como <rol>, quiero <acción>, para <beneficio> | Claridad de propósito | Para equipos nuevos o cuando se necesita claridad en el valor entregado |
| Desarrollo dirigido por hipótesis (HDD) | Creemos que <acción>, para <grupo>, resultará en <impacto>. Lo sabremos cuando <métrica> cambie, en <cuándo deberá suceder> | Fomenta validación y aprendizaje | Innovaciones, funcionalidades nuevas o inciertas |
| Cuando – Entonces – Porque | Cuando <situación>, entonces <acción>, porque <motivación> | Explora la causa raíz del problema | Problemas específicos con justificación de negocio clara |
| Dado – Cuando – Entonces (BDD) | Dado que <contexto>, cuando <acción>, entonces <resultado> | Claridad para escenarios de negocio | Eventos del sistema y reglas de negocio críticas |
| Necesidad – Solución – Valor | Necesidad: <qué se necesita>. Solución: <qué se propone>. Valor: <qué se gana> | Conecta problema, solución y beneficio | Justificación de funcionalidades ante stakeholders |
| Evento – Respuesta – Valor | Evento: <detonante>. Respuesta: <comportamiento>. Valor: <impacto> | Describe reacciones automáticas | Sistemas reactivos, seguridad o monitoreo |
| Job Stories | Cuando <situación>, quiero <motivación>, para que <resultado> | Contextualiza más allá del rol | Descubrimiento de producto y uso real |
| Sentimiento – Necesidad – Solución – Beneficiario | Sentimiento: <emoción>. Necesidad: <problema>. Solución: <respuesta>. Beneficiario: <quién gana> | Conecta emoción con impacto | Diseño UX, experiencias empáticas |
| Deseo – Acción – Satisfacción | Deseo: <meta>. Acción: <interacción>. Satisfacción: <resultado> | Modelo motivacional claro | Funcionalidades que buscan generar confianza y bienestar |
| Contexto – Sentimiento – Acción – Resultado – Emoción | Contexto > Sentimiento > Acción > Resultado > Emoción | Incluye la emoción antes y después | Historias centradas en experiencia completa del usuario |
| Regla de Negocio – Comportamiento – Resultado Esperado | Regla: <condición de negocio>. Comportamiento: <acción del sistema>. Resultado esperado: <efecto> | Precisión en decisiones de negocio | Funcionalidades que reflejan reglas o políticas específicas |
Evalúa constantemente la utilidad del formato
No te cases con un solo formato. Si descubres que una plantilla no está funcionando para tu equipo o para un contexto de la funcionalidad del producto, ajusta el enfoque, ¡Simple!.
Ejemplo de una retro de historias de usuario
Preguntas a responder:
- ¿Las historias son claras y entendibles para todos los miembros del equipo?
- ¿Los criterios de aceptación han sido útiles para definir cuándo una historia está completa?
- ¿Se ha usado el formato adecuado en cada caso?
Tip: Ajusta las plantillas basándote en la retroalimentación del equipo.
Cerrando
No hay un único formato correcto para escribir historias de usuario. La clave es elegir el formato que mejor se adapte al contexto de la organización y del equipo. Más importante que la estructura es garantizar, la conversación durante el proceso de construcción y que las historias sean pequeñas (menos de 36 horas de trabajo), claras y centradas en generar valor.
Además, con la llegada de la Inteligencia Artificial Generativa (GenAI), el proceso de creación y refinamiento de historias de usuario está evolucionando, permitiendo que los equipos sean más eficientes sin perder el enfoque en la entrega de valor.
No se trata de seguir un molde, sino de asegurarnos de que las historias cumplan su propósito: alinear a los equipos, generar conversaciones efectivas y entregar soluciones valiosas.
¿Y si tu equipo diseñara su propio formato de historias de usuario? ¿Cómo se vería?
Saludos ágiles,
Jorge Abad
Notas, aclaraciones, referencias y comentarios
- La historia de las historias de usuario. Lucho Salazar.
- De Colección: Ejemplos de Historias de Usuario de la Fuente: Los Libros de Extreme Programming (XP)
- How to Implement Hypothesis-Driven Development. Barry O'Reilly
- Historias de usuario: Una visión pragmática (Spanish Edition)
- Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática.
- What's in a Story?. Dann North.
- Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.
- Pichler, Roman. Agile Product Management with Scrum. Addison-Wesley, 2010.
- Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley, 2004.
domingo, marzo 16, 2025
Frase: Actuando en tiempos de cambio
"El mayor peligro en tiempos turbulentos no es la turbulencia, es actuar con la misma lógica que antes."
-Peter Drucker
La necesidad del pensamiento Lean en la era de la GenAI: un enfoque hacia las historias de usuario
Hola a todos,
La inteligencia artificial generativa (GenAI) ha transformado significativamente el proceso de generación e identificación de historias de usuario (HU). Antes, construir una historia de usuario requería sesiones de descubrimiento, múltiples interacciones con los interesados y refinamiento iterativo con el equipo de desarrollo. Aunque estas sesiones siguen siendo esenciales para garantizar una alineación con las necesidades reales del usuario, la GenAI ha simplificado y acelerado el proceso al capturar múltiples puntos de vista clave, sintetizarlos y generar rápidamente una lista estructurada de épicas, características esenciales del producto e historias de usuario relevantes. Con un prompt bien diseñado, también puede proporcionar criterios de aceptación detallados e incluso generar el código base necesario para su implementación (1).
Automatización y eficiencia en la construcción de historias de usuario
Gracias a la GenAI, no solo podemos generar historias de usuario más rápido, sino que también podemos obtener el código que resuelve la funcionalidad requerida casi de inmediato. Esto significa que la velocidad de desarrollo ha aumentado drásticamente, pero al mismo tiempo, han surgido nuevos riesgos y desafíos que pueden comprometer la efectividad del producto final (2).
Sin embargo, la velocidad no es sinónimo de precisión., de nada sirve ir a 200 km/h en la dirección incorrecta, es preferible dirección y precisión sobre velocidad. La GenAI, aunque útil para agilizar procesos, no reemplaza la interacción humana ni la validación con usuarios reales. Es fácil caer en la trampa de creer que, porque la IA genera respuestas convincentes y completamente acertadas, recordemos que los modelos de GenAI tiene una precisión cercana (a hoy del 99%) (5). Pero la realidad es otra: un producto verdaderamente exitoso no solo debe ser funcional, sino que debe resonar con sus usuarios, ser intuitivo y sentirse como una extensión natural de su flujo de trabajo (3).
En Apple, el diseño se basa en una premisa clara: eliminar todo lo que no sea esencial. Un producto verdaderamente excepcional no es aquel que tiene más características, sino aquel que resuelve necesidades de la manera más elegante y precisa posible (4).
El peligro de la sobreconstrucción y la desconexión con el usuario
Uno de los mayores riesgos que enfrentamos en esta nueva era de automatización e inteligencia es la tendencia a construir más de lo que realmente se necesita. La facilidad con la que la GenAI genera código y funcionalidades puede llevarnos a desarrollar características que no son esenciales, simplemente porque es fácil hacerlo. Sin una adecuada priorización basada en las necesidades reales del usuario, podemos terminar creando productos saturados de opciones innecesarias, en lugar de soluciones minimalistas y funcionales que realmente resuelvan sus problemas (1).
Otro peligro latente es la falta de comunicación con el usuario. La GenAI puede simular el comportamiento de un usuario a través de perfiles de "Personas" creados mediante técnicas de Design Thinking (3). Un prompt como:
Contexto: Vamos a generar una app para los guardabosques, y vas a responder como si fueras un guardabosques de más de 10 años de experiencia. A continuación, te haré preguntas que me guiarán en el diseño de un producto que mejorará tu forma de gestionar el bosque que estás cuidando.
"Vamos a generar una app para guardabosques, y vas a responder como si fueras un guardabosques de más de 10 años de experiencia. A continuación, te haré preguntas que me guiarán en el diseño de producto que mejorará tu forma de gestionar el bosque que estás cuidando."
puede ayudar a capturar información valiosa, sin dudarlo. Sin embargo, aunque esto sirve, es indudable que tiene limitaciones. Nada sustituye las entrevistas reales, la observación en el campo y la empatía directa con quienes usarán el producto. Un diseño exitoso no es aquel que solo responde a suposiciones bien estructuradas, sino aquel que emerge de la interacción genuina con los usuarios reales (4).
La importancia del diseño centrado en el usuario y la medición del impacto
El éxito en esta nueva era dependerá de quién logre conectarse verdaderamente con los usuarios y utilice el potencial de la GenAI para construir productos alineados con sus expectativas reales (2). Empresas como Apple han demostrado que la simplicidad y la precisión en el diseño generan una experiencia de usuario superior (3). Los consumidores buscan productos que resuelvan sus necesidades de manera intuitiva, sin saturación ni funcionalidades innecesarias. En este sentido, herramientas como A/B Testing y el análisis de métricas de uso se vuelven indispensables para validar continuamente la utilidad de las funcionalidades implementadas (1).
Las empresas que no adopten este enfoque y se dediquen a saturar a los usuarios con opciones irrelevantes verán cómo el mercado elige la perfección sobre la sobrecarga. Sin una estrategia de medición y ajuste basada en el comportamiento real de los usuarios, muchas organizaciones podrían quedar desconcertadas al ver que sus productos no son elegidos, sin entender que la razón fundamental fue la falta de alineación con las necesidades del cliente (4).
¿Es esta historia de usuario necesaria o es desperdicio?
Para evitar la sobrecarga de funcionalidades innecesarias, los Product Owners y los equipos ágiles deben evaluar rigurosamente cada historia de usuario antes de desarrollarla. A continuación, algunas preguntas clave que pueden ayudar en esta validación:
-
¿Cuál es el problema real que esta historia resuelve?
- Si no puedes identificar claramente un problema que impacte negativamente al usuario, es posible que esta historia sea innecesaria.
-
¿Esta funcionalidad alinea con los objetivos del producto?
- Una historia de usuario debe contribuir a la visión del producto. Si no lo hace, podría ser un desperdicio de recursos.
-
¿Esta historia de usuario tiene métricas de éxito definidas?
- Si no hay una manera clara de medir su impacto, ¿cómo sabremos si fue útil?
-
¿Qué impacto tendría si no se desarrolla esta historia?
- Si el producto aún funciona perfectamente sin ella, probablemente no es prioritaria.
-
¿La funcionalidad generará fricción en la experiencia del usuario?
- Más opciones no siempre son mejores. A veces, menos es más.
-
¿Cuántos usuarios realmente la necesitan?
- Si la funcionalidad es relevante solo para un nicho muy reducido, podría ser mejor posponerla o encontrar una alternativa más general.
-
¿Es una funcionalidad que puede validarse con un experimento rápido?
- Antes de construirla completamente, ¿podemos hacer un test de baja fidelidad para ver si realmente se usa?
Un producto bien diseñado es aquel que parece haber leído la mente del usuario, eliminando lo innecesario y dejando solo lo esencial. Si cada historia de usuario se filtra a través de estas preguntas, el backlog estará compuesto solo por elementos que realmente aportan valor.
El rol del Product Owner en la era de la GenAI
A pesar de la automatización que permite la GenAI, el papel del Product Owner (PO) sigue siendo crucial. No basta con generar funcionalidades rápidamente; es necesario identificar qué sí y qué no hacer, qué agrega y qué no agrega valor (2). El PO es quien tiene la responsabilidad de ordenar y priorizar el backlog, asegurando que el producto final no solo cumpla con las necesidades funcionales, sino que logre la perfección oculta en el imaginario del usuario (3).
Cuando un usuario interactúa con un producto bien diseñado, experimenta una sensación de esbeltez y perfección. No se trata solo de que el producto funcione, sino de que se sienta preciso, exacto, como si hubiera sido diseñado específicamente para ellos (1). Esa sensación no se logra con cantidad, sino con calidad, atención al detalle (4) y a la eliminación de cualquier forma de desperdicio.
Cerrando
La GenAI es una herramienta poderosa que, bien utilizada, puede revolucionar la manera en que diseñamos y desarrollamos productos. Sin embargo, su éxito dependerá de nuestra capacidad para combinar la automatización con un enfoque genuinamente centrado en el usuario, evitando la trampa de construir más por el simple hecho de que podemos hacerlo. Aquellos que comprendan esto y logren equilibrar la velocidad con la precisión y la esbeltez serán quienes dominen esta nueva era digital+ai.
Saludos ágiles,
Jorge Abad
Notas, aclaraciones, referencias y comentarios
- Ries, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.
- Norman, Donald A. The Design of Everyday Things. Basic Books, 2013.
- Brown, Tim. Change by Design: How Design Thinking Creates New Alternatives for Business and Society. Harper Business, 2009.
- Blank, Steve. The Four Steps to the Epiphany: Successful Strategies for Startups That Win. K&S Ranch, 2013.
- Hughes Hallucination Evaluation Model (HHEM) leaderboard - https://huggingface.co/spaces/vectara/leaderboard
Suscribirse a:
Entradas (Atom)