Requisitos «just-in-time»: cuándo pasar de explorar soluciones a un plan de entrega ligado al valor de negocio

El artículo de Amy Mitchell (Product Management IRL) plantea cuándo conviene escribir requisitos de producto y cuándo es pronto para hacerlo. Su propuesta es no fijar todos los requisitos al inicio, sino mantener un esquema vivo que conecte lo que aprenden los equipos con la oportunidad de negocio, y consolidarlo en requisitos formales solo cuando la entrega depende de un entendimiento común.

El escenario de partida es el de un equipo de producto que explora una solución prioritaria para la dirección. La carta del equipo es escalar un producto existente a un mercado nuevo. Al ser una prioridad, cuatro equipos exploran soluciones en paralelo: ingeniería investiga un kit para desarrolladores que permita escalar mediante automatización; soporte estudia cómo querrán estos clientes obtener ayuda; gestión de producto considera cómo crear una comunidad alrededor de los nuevos clientes; y los product managers de plataforma analizan la formación de clientes sobre la tecnología. Los equipos avanzan, pero aún no están definidos ni la oportunidad de negocio ni los requisitos de la solución global.

La autora subraya que el respaldo de la dirección es una razón para explorar en paralelo, pero no decide por sí solo qué construir ni cuánto invertir. Cada subiniciativa acaba identificando trabajo que necesita personas y presupuesto, y entre las piezas quedan huecos. Los ejemplos que da son: un kit de desarrollo para instalar el producto sin plan para mantenerlo; un equipo de soporte con conocimiento pero sin vía para canalizarle las consultas de los clientes; contactos de clientes para una comunidad sin forma de implicarlos; y material de formación sobre el producto pero no sobre su instalación. La pregunta clave es si la solución combinada alcanzará el resultado de negocio y qué inversión exige.

Sobre por qué escribir requisitos demasiado pronto puede frenar al equipo, el texto explica que, si los requisitos no están claros, las decisiones de solución y viabilidad entran en bucle. Pone el ejemplo de un equipo que depende de cambios en TI mientras otro no quiere comprometerse con un seguimiento manual de clientes: todos están dispuestos a explorar alternativas, pero ninguno puede comprometerse en solitario. Intentar cerrar todos los requisitos antes de explorar compromisos retrasa el avance; dejar explorar sin más crea otro problema, porque las opciones de un equipo afectan a los demás. Por eso, en lugar de requisitos y planes, propone capturar lo que el equipo va aprendiendo y conectarlo con la oportunidad de negocio.

Ese «esquema vivo» se construye en paralelo a la exploración y descansa en los beneficios para el cliente y las restricciones de la organización. El primer componente es el recorrido del cliente a lo largo del ciclo de uso: compra, implantación, uso continuado, mantenimiento y renovación. Ayuda a entender por qué compran los clientes, cómo la solución crea valor con el tiempo (uso, expansión, renovación) y qué hace falta para que tengan éxito (rendimiento, calidad, soporte y mantenimiento). Esta visión cambia a medida que el equipo habla con clientes potenciales, y de las posibles soluciones también salen compromisos.

El segundo componente es una estimación inicial de la oportunidad de negocio. Según el texto, hay demasiadas combinaciones para hacer una previsión, pero sí se puede obtener un orden de magnitud aproximado por dos vías. La primera, un análisis de mercado: tomar el tamaño del mercado al que se puede servir, estimar el porcentaje que cubre la solución y aplicar la tasa de éxito habitual. La segunda, por analogía: revisar el lanzamiento de un producto o función similar, propio o ajeno, localizar su ritmo de crecimiento en ingresos o unidades y aplicarlo para estimar la oportunidad. En ambos casos el resultado es una estimación inicial.

Colocar el recorrido del cliente junto a la oportunidad de negocio resulta valioso para las exploraciones paralelas: la oportunidad establece cuánta inversión está justificada, y el recorrido identifica las capacidades y costes continuos que esa oportunidad requiere. El esquema vivo es un resumen de trabajo que cambia con el aprendizaje del equipo y sirve para comparar enfoques y entender cómo cada decisión afecta a la solución global. Incluye el recorrido del cliente, la oportunidad aproximada con sus supuestos, las restricciones y los probables motores de coste, y las preguntas abiertas y decisiones que afectan al equipo.

La autora señala tres señales de que ha llegado el momento de formalizar requisitos: los equipos revisan una y otra vez las estimaciones de esfuerzo porque el alcance o las dependencias no están claros; las decisiones se reabren porque el enfoque de un equipo cambia los requisitos o costes de otro; y la dirección pide un caso de negocio más sólido antes de comprometer personas o presupuesto. En ese punto, los requisitos dejan de ser documentación pendiente y pasan a ser las decisiones compartidas que el equipo necesita para avanzar.

El papel de la IA, según el artículo, es consolidar el esquema vivo en cuatro artefactos conectados: un caso de negocio (oportunidad, valor esperado, inversión, costes y supuestos); los requisitos (qué debe hacer el producto, con restricciones y criterios de aceptación); un plan de entrega y mantenimiento (trabajo, dependencias, responsables y esfuerzo continuo); y un resumen de preparación (qué está resuelto, qué sigue incierto y qué compromisos necesitan el acuerdo de la dirección). La autora matiza que el equipo debe validar los resultados y resolver las decisiones que afectan a la inversión: la IA acelera la consolidación, pero no sustituye al acuerdo.

En la conclusión, el planteamiento es explorar mientras la solución es incierta, mantener visibles el resultado para el cliente y la oportunidad de negocio, y consolidar lo aprendido cuando la entrega dependa de una comprensión común. El documento resultante da a los equipos una base compartida para entregar, a la dirección suficiente información para comprometer la inversión, y a los equipos de salida al mercado una idea más clara de lo que hará la solución y de su valor.

El artículo cierra con un apartado de preguntas y respuestas. Distingue el esquema vivo (conecta lo que se aprende sobre cliente, oportunidad, restricciones, costes y decisiones), el caso de negocio (explica por qué merece la pena la inversión) y los requisitos (definen lo que el producto debe hacer). Defiende que es responsabilidad de gestión de producto porque quien ocupa ese rol conecta el problema del cliente con la oportunidad de negocio, mientras que los program managers pueden usar el mismo contexto para coordinar dependencias y seguir la preparación de la entrega, y cada equipo sigue siendo responsable de sus decisiones técnicas y operativas. Y sobre qué ocurre si los requisitos cambian tras el compromiso, responde que estos no son una promesa de inmutabilidad: nuevas pruebas de clientes, hallazgos técnicos o cambios de coste pueden exigir modificar alcance, calendario o inversión, por lo que hay que hacer visible el impacto, actualizar los requisitos y el plan compartidos y obtener el acuerdo de quienes ven afectados sus compromisos.

Nota del editor: el texto descargado corresponde al artículo completo (no es un teaser de paywall), aunque incluye enlaces a otros materiales de la autora que no se han podido consultar, por lo que este resumen se basa solo en el contenido recibido.