Estrategia de producto y discovery
Investigación, prototipos y un alcance que se puede cotizar.
Lo que sale es un backlog, las integraciones de las que depende y una estimación con sus supuestos escritos, producida por el mismo equipo que lo construiría.
Qué te llevas al final
Cinco cosas, y cada una es un objeto que alguien puede usar, no la descripción de lo que hicimos.
Un orden de releases
Qué se construye primero, y la razón por la que va primero. Normalmente esa razón es el riesgo en las integraciones y no lo que se ve terminado antes.
Una estimación, con sus supuestos
Qué cuesta la primera release en tiempo y dinero, y la lista de cosas que cambiarían ese número si resultaran distintas.
Un backlog
Épicas e historias al nivel que se puede estimar de verdad, y no una lista de funcionalidades que después hay que volver a deducir.
El mapa de integraciones
De qué sistemas tiene que leer el producto y en cuáles tiene que escribir, qué puede hacer ya cada uno, y cuáles nadie revisó todavía.
Un prototipo que la gente usó
Clickeable, de punta a punta, puesto delante de las personas que lo usarían, no un recorrido mostrado a quienes lo encargaron.
Tres respuestas que esto puede dar, y una nos cuesta el desarrollo
Un discovery que sólo puede terminar de una forma no es un discovery. Es la primera factura de un proyecto que ya estaba decidido.
Constrúyelo, y éste es el orden
El concepto se sostiene, las integraciones son alcanzables y el trabajo puede empezar. Lo que agrega el discovery es la secuencia: qué release va primero, de qué depende y cuánto cuesta la primera.
El caso habitual, y el que todos planifican.
Construye menos
A veces una parte de lo que se pidió ya existe como producto maduro, e integrarlo cuesta una fracción de construirlo. A veces la primera release sólo necesita un tercio del alcance para valer la pena. Las dos respuestas achican el proyecto.
En una plataforma para pacientes que necesitaba consultas por video, recomendamos integrar un proveedor especializado en vez de construirlo desde cero.
Todavía no
La idea es clara para quienes la tienen y no está probada con quienes la usarían. Entonces la salida honesta es un prototipo y un conjunto de hallazgos, y el desarrollo espera a que vuelvan.
Cuándo vale la pena hacerlo
Tres situaciones donde el costo de enterarse después es mucho más alto que el costo de enterarse ahora.
Quienes lo usarían no lo vieron
Un concepto puede ser claro para los fundadores y estar equivocado sobre el flujo de trabajo en el que tiene que encajar. Cuando los usuarios son médicos, o inspectores, o cualquiera cuyo día el producto tiene que sobrevivir, la distancia entre una idea bien argumentada y una usable es donde desaparecen los presupuestos.
Para eso sirve un prototipo: no es una demo, es un instrumento para enterarse temprano.
Tiene que conectarse a sistemas que nadie abrió en años
La capa de integración es donde se deciden estos proyectos. Qué puede exponer ya un sistema, qué no, y quién tiene que aprobar la conexión son preguntas de respuesta larga, y encontrarlas durante el desarrollo convierte un cronograma en una negociación.
El discovery es donde se hacen esas preguntas, mientras las respuestas todavía pueden cambiar el plan.
La primera release tiene que ser defendible ante alguien que no estuvo en la sala
En las instituciones, el alcance lo aprueba gente que no fue parte de la conversación que lo produjo. Un backlog con una razón atada a cada prioridad sobrevive esa reunión; una lista de funcionalidades no.
Esa razón es el entregable. Sin ella, la reunión reabre decisiones que ya estaban tomadas.
Preguntas que nos hacen antes de la primera llamada
¿Podemos ir directo a construir?
Muchas veces sí. Si el producto se entiende, las integraciones se conocen y alguien ya probó el concepto con quienes lo van a usar, el discovery sería papeleo. Preferimos decirlo antes que vender una fase que no cambia nada.¿Tenemos que construirlo con ustedes después?
No. Lo que sale es tuyo: el backlog, la estimación, el prototipo y el razonamiento detrás de cada prioridad. Está escrito para entregárselo a quien lo construya, incluido tu propio equipo.¿Cuánta investigación alcanza?
La suficiente para cambiar una decisión que todavía está abierta. Un estudio que llega después de tomada la decisión, o que no podría haberla cambiado de ninguna manera, es un costo sin retorno, y es la razón por la que la investigación tiene la reputación que tiene dentro de los equipos de producto.¿Y si ya sabemos qué queremos construir?
Entonces el trabajo útil no es validar, es secuenciar y dimensionar: qué va primero, de qué depende y cuánto cuesta. Ése es un proyecto más corto y lo cotizamos como tal.
Cuéntanos en qué estás por gastarlo.
En una sesión de trabajo de 45 minutos te decimos si esto necesita discovery, qué querríamos averiguar primero y qué cambiaría la respuesta. Trae la idea y la fecha que tiene atada.