Qué es un discovery de producto y qué deberías tener al terminarlo
Antes de escribir código conviene saber qué se va a construir, para quién y por qué. El discovery es la etapa que convierte una idea o una necesidad en decisiones concretas, y su valor se mide por lo que deja al terminar.
Equipo Eudaimonia4 min de lectura
Imaginemos este pedido: «Necesitamos que los clientes puedan reservar turnos». ¿Incluye reprogramaciones? ¿Los profesionales administran su propia agenda? ¿Qué pasa si se cancela un turno ya pagado? La idea inicial puede ser clara y, aun así, dejar abiertas decisiones que cambian el trabajo y el presupuesto.
El discovery de producto sirve para investigar esas preguntas y acordar cómo avanzar. No tiene que despejar todas las dudas: tiene que dejar claras las decisiones que permiten empezar, los supuestos que falta comprobar y quién va a resolverlos.
Para qué sirve un discovery
Un discovery no se evalúa por la cantidad de documentos que genera. Su propósito es despejar las dudas que más pesan para que las decisiones de alcance, prioridad e inversión se tomen con fundamento. En concreto, busca responder:
Qué problema se resuelve y cómo se va a medir si se resolvió.
Para quién: qué usuarios intervienen, qué necesitan y en qué contexto van a usar el producto.
Qué se construye primero y qué puede esperar.
Cómo se construye: qué arquitectura, integraciones y tecnologías tienen sentido.
Cuánto cuesta y cuánto lleva, con un nivel de precisión razonable para decidir.
También puede mostrar que la idea necesita cambiar, que hay un camino más simple o que el problema real es otro. Llegar a esa conclusión antes de comprometer el desarrollo permite decidir con más margen.
Cuándo conviene hacerlo
No todos los proyectos necesitan el mismo nivel de discovery, pero es especialmente valioso cuando:
Se trata de un producto nuevo o de una línea de negocio que todavía no existe.
Intervienen varias áreas o tipos de usuarios con necesidades distintas.
El producto depende de integraciones con sistemas existentes.
Hay reglas de negocio complejas, regulaciones o datos sensibles.
Hace falta un presupuesto o un plan confiable para aprobar la inversión.
Cómo se trabaja
Un discovery combina conversaciones con el negocio, análisis técnico y validación temprana. Las actividades más habituales son:
Entrevistas y talleres con las personas que conocen el problema: responsables del negocio, usuarios, áreas operativas y equipos técnicos.
Relevamiento de procesos y sistemas existentes, para entender qué se reemplaza, qué se integra y qué restricciones hay.
Definición de flujos y casos de uso, incluyendo los escenarios alternativos y no solo el recorrido ideal.
Prototipos de baja o media fidelidad para validar la experiencia con usuarios reales antes de construirla.
Análisis técnico de arquitectura, integraciones, riesgos y alternativas de implementación.
Priorización de funcionalidades según valor, complejidad y dependencias.
La duración depende del tamaño del problema: puede ir de un par de semanas para un producto acotado a varias semanas cuando hay múltiples áreas, integraciones o regulaciones involucradas.
Qué debería quedar al terminar
Los entregables cambian según el proyecto. Para el ejemplo de los turnos, lo útil sería poder responder estas preguntas con material que el equipo pueda consultar:
¿Qué problema se quiere resolver y cómo se medirá? Por ejemplo, reducir el tiempo que lleva asignar un turno, con una medida de la situación actual para comparar.
¿Quién hace qué? Flujos de pacientes, profesionales y administración, incluidos cambios y cancelaciones.
¿Qué entra en la primera versión? Funciones priorizadas y decisiones explícitas sobre lo que se posterga.
¿Cómo se pondrá a prueba la propuesta? Un prototipo o flujo revisado con quienes van a usarlo, y las dudas que esa revisión dejó abiertas.
¿Qué condiciona la construcción? Integraciones, reglas, riesgos, responsables de resolverlos y una estimación que indique sus supuestos.
Puede quedar más de un documento o un tablero compartido. El formato importa menos que poder encontrar una decisión, saber quién la tomó y reconocer qué sigue siendo una hipótesis.
Errores comunes
Convertirlo en un documento que nadie lee: un discovery útil produce material que el equipo consulta durante la construcción, no un informe que se archiva.
Pensar solo en el caso en que todo sale bien: en el ejemplo de los turnos, las cancelaciones, las reprogramaciones y las ausencias son las que más mueven el costo y los plazos.
Dejar afuera a quienes operan: los usuarios finales y las áreas operativas suelen conocer restricciones que no aparecen en las reuniones con la dirección.
Separar lo funcional de lo técnico: una experiencia ideal puede ser inviable por una integración o una restricción de datos. Conviene analizarlas juntas.
Pretender que no quede ninguna duda: siempre habrá preguntas que solo se responden construyendo. Lo que importa es saber cuáles son, qué riesgo implican y quién se ocupa de cada una.
Discovery y desarrollo no son etapas aisladas
Lo que se aprende en el discovery sigue validándose durante la construcción. Un buen plan se construye de forma incremental, con entregas que permiten confirmar supuestos y ajustar prioridades sin perder la dirección. Por eso también es una de las herramientas más efectivas para evitar que un proyecto se desvíe de su presupuesto.
Antes de cerrar esta etapa, vale hacer una prueba simple: pedirles a negocio y al equipo técnico que describan por separado qué se va a construir primero. Si las respuestas no coinciden, todavía hay una decisión por tomar.
Imagine this request: “We need customers to be able to book appointments.” Does that include rescheduling? Do professionals manage their own calendars? What happens if a paid appointment is canceled? The initial idea may be clear while leaving decisions open that change the work and the budget.
Product discovery helps investigate these questions and agree on how to proceed. It does not need to eliminate every uncertainty. It should clarify the decisions needed to start, the assumptions still to be tested, and who will resolve them.
What discovery is for
Discovery is not judged by the number of documents it produces. Its purpose is to resolve the most consequential uncertainties so decisions about scope, priorities, and investment rest on solid ground. Specifically, it aims to answer:
What problem is being solved and how success will be measured.
For whom: which users are involved, what they need, and the context in which they will use the product.
What to build first and what can wait.
How to build it: which architecture, integrations, and technologies make sense.
How much it will cost and how long it will take, at a level of precision appropriate for the decision.
Discovery may also reveal that the idea should change, that a simpler path exists, or that the real problem lies elsewhere. Reaching that conclusion before committing to development gives the team more room to decide.
When it is useful
Not every project needs the same depth of discovery, but it is especially valuable when:
The project is a new product or a business line that does not yet exist.
Several departments or user groups have different needs.
The product depends on integrations with existing systems.
There are complex business rules, regulations, or sensitive data.
A credible budget or plan is needed to approve the investment.
How the work is done
Discovery combines conversations with business stakeholders, technical analysis, and early validation. Common activities include:
Interviews and workshops with people who know the problem: business owners, users, operations staff, and technical teams.
Reviewing existing processes and systems to understand what will be replaced, what must be integrated, and what constraints exist.
Defining flows and use cases, including alternative scenarios instead of only the ideal journey.
Low or medium fidelity prototypes to validate the experience with real users before building it.
Technical analysis of architecture, integrations, risks, and implementation options.
Prioritizing features by value, complexity, and dependencies.
Duration depends on the size of the problem: it might take a couple of weeks for a focused product or several weeks when multiple departments, integrations, or regulations are involved.
What you should have at the end
Deliverables vary by project. For the appointment example, useful material would let the team answer these questions:
What problem are we solving, and how will we measure it? For example, reducing the time required to assign an appointment, with a baseline for comparison.
Who does what? Flows for patients, professionals, and administrators, including changes and cancellations.
What belongs in the first version? Prioritized features and explicit decisions about what is deferred.
How will we test the proposal? A prototype or flow reviewed with its future users, plus the questions that review left open.
What constrains the build? Integrations, rules, risks, owners responsible for resolving them, and an estimate that states its assumptions.
The result may be several documents or a shared board. The format matters less than being able to find a decision, know who made it, and see what remains a hypothesis.
Common mistakes
Turning it into a document nobody reads: useful discovery produces material the team consults while building, not a report filed away.
Considering only the happy path: in the appointment example, cancellations, rescheduling, and no-shows have a major effect on cost and timing.
Leaving out the people who operate the process: end users and operations teams often know constraints that never surface in leadership meetings.
Separating functional and technical questions: an ideal experience may be impossible because of an integration or data constraint. Analyze them together.
Trying to eliminate every unknown: some questions can only be answered by building. What matters is knowing what they are, the risk they carry, and who owns each one.
Discovery and development are connected
What the team learns in discovery continues to be validated during development. A sound plan grows incrementally, with releases that test assumptions and let priorities change without losing direction. This is also one of the most effective ways to prevent a project from going over budget.
Before closing this phase, try a simple check: ask business stakeholders and the technical team separately to describe what will be built first. If their answers differ, a decision is still outstanding.
Diseño y construcción de productos digitales
¿Estás pensando en construir un producto digital?
Te ayudamos a definir el alcance, validar la idea y construir un producto preparado para crecer.
Las causas más comunes de desvíos de costos y plazos en proyectos de software (alcance difuso, integraciones subestimadas, dependencias ocultas) y prácticas concretas para estimar y controlar mejor.
Cómo Eudaimonia desarrolló Llamando al Doctor, una plataforma de telemedicina integrada con AWS para conectar a pacientes y médicos mediante videollamadas.
