Antes de que un equipo SaaS comprometa el presupuesto de su MVP, hay una pregunta que decide si ese dinero está bien invertido: ¿pagará de verdad el cliente para el que piensa construir? El descubrimiento de producto la responde primero, mediante entrevistas con las partes interesadas, mapas del recorrido del cliente y prototipos ligeros que validan el problema y un único comprador concreto antes de escribir una sola línea de código de producción. Suele durar de 2 a 6 semanas.
La decisión suele recaer en un responsable de producto que define el alcance de un nuevo módulo o en un fundador con una idea financiada y una fecha de lanzamiento. Empezar a construir de inmediato parece más rápido, sobre todo ahora que el desarrollo asistido por IA puede producir una primera versión funcional en poco tiempo. Sin embargo, un desarrollo rápido no aporta nada a una idea sin validar: un producto SaaS puede estar bien construido y aun así fracasar si se diseñó para un perfil de cliente que nadie puso a prueba. El descubrimiento lo detecta en la fase de prototipo, donde un cambio de rumbo cuesta días de trabajo de diseño.
Qué implica realmente el descubrimiento de producto
El descubrimiento de producto responde a dos preguntas, en este orden. Primero, ¿el problema es lo bastante doloroso como para que alguien pague por resolverlo? Segundo, ¿cuál es el producto más pequeño que lo resuelve para un comprador concreto? Redwerk las trata como pasos separados, porque un equipo que se salta la primera acaba diseñando una solución para un problema que solo dio por supuesto.
Entrevistas con las partes interesadas
Son conversaciones con las personas que sufren el problema, con quienes pagarían por resolverlo y con las partes interesadas internas que tienen que vender, dar soporte o integrar el producto. En el SaaS B2B del mercado medio rara vez son la misma persona: un responsable de operaciones sufre el problema, un director financiero firma el contrato y el departamento de TI decide si la integración está permitida.
El objetivo son pruebas de intención, y la trampa habitual es confundirla con el interés. La intención se manifiesta en comportamientos, como que un cliente potencial comparta cuánto le cuesta su solución provisional actual, le presente al responsable del presupuesto o acepte un piloto de pago.
Mapa del recorrido del cliente
Un mapa del recorrido describe, paso a paso, cómo gestiona hoy el cliente objetivo el problema: las herramientas que usa, los traspasos entre personas y dónde se pierden el tiempo y se producen los errores. Para un producto SaaS, este mapa decide con qué tiene que conectarse el producto (el CRM, el sistema de facturación, la hoja de cálculo que sostiene la mitad del proceso). También muestra el paso en el que el software ahorra más esfuerzo, que se convierte en el núcleo del MVP.
Prototipos ligeros
Los wireframes interactivos o una maqueta sencilla se presentan a las mismas personas que fueron entrevistadas. Un prototipo comprueba si el flujo de trabajo propuesto tiene sentido para el usuario antes de que nadie escriba código de backend, y cambiarlo cuesta unos pocos días de diseño. Cambiar ese mismo flujo después de lanzar el MVP obliga a rehacer la base de datos, la API y la interfaz.
Métodos de validación de ideas SaaS que distinguen el interés de la intención
La validación de ideas SaaS es la parte del descubrimiento que convierte las entrevistas en pruebas sobre las que puede actuar quien controla el presupuesto. Los mismos métodos sirven para un nuevo módulo dentro de una plataforma consolidada y para las ideas de micro SaaS que un equipo pequeño puede lanzar por su cuenta. Estos son los que mejor funcionan en SaaS B2B:
- Entrevistas sobre el problema antes de presentar la solución. Pregunte cómo gestiona hoy el cliente el problema y cuánto le cuesta en horas, personal o ingresos perdidos. Describa el producto solo al final, si es que lo hace.
- Pruebas de compromiso. Una carta de intenciones, un piloto de pago, un acuerdo de socio de diseño o una preventa con descuento son pruebas más sólidas que una larga lista de entrevistas entusiastas.
- Auditorías de soluciones provisionales. Si el cliente ya paga por una solución parcial, o ha montado un proceso con hojas de cálculo en torno al problema, el dolor es real y ya tiene presupuesto.
- Recorridos del prototipo con el rol de usuario real. Observe cómo la persona que usaría el producto a diario prueba el flujo interactivo. Los puntos donde duda son los puntos donde el alcance del MVP necesita trabajo.
- Un filtro de perfil único. Cada hallazgo se contrasta con un único perfil de cliente objetivo. Los comentarios de fuera de ese perfil se registran y se aparcan para más adelante.
Qué determina la duración y el esfuerzo de un proceso de descubrimiento
El trabajo inicial se divide en dos etapas, la validación del problema y la forma de la solución, las dos primeras de las siete etapas del desarrollo de productos SaaS. La forma de la solución es el núcleo del proceso de descubrimiento, con sus entrevistas con las partes interesadas, mapas del recorrido y prototipos ligeros, y el equipo es pequeño: el fundador (o, dentro de una empresa consolidada, el product owner), un estratega de producto o analista de negocio y un responsable de UX. La mayoría de los proyectos de fase de descubrimiento de Redwerk duran de 2 a 6 semanas, según la complejidad del producto, las integraciones y cuánta validación necesite todavía la idea.
Validación del problema
Un problema confirmado por cuya solución alguien pagará
Fundador y 1 o 2 asesores expertos en el sector
Se confunde el interés con la intención
Forma de la solución (descubrimiento)
Una hipótesis de valor con un comprador definido
Fundador, estratega de producto o analista de negocio, responsable de UX
El producto intenta servir a varios perfiles de cliente a la vez
Alcance y desarrollo del MVP
Una parte del producto que se puede construir y probar
Product owner, de 2 a 4 desarrolladores, un ingeniero de QA y un diseñador
El exceso de funcionalidades alarga el calendario antes del lanzamiento
El punto exacto en el que cae un proyecto de descubrimiento dentro del rango de 2 a 6 semanas depende de cuatro factores:
- cuántos segmentos de clientes se entrevistan (uno es más barato, y mejor, como explica la siguiente sección)
- qué grado de acabado necesitan los prototipos
- con cuántos sistemas existentes tiene que integrarse el producto
- si hay código heredado que auditar antes de diseñar nada nuevo
Si el descubrimiento demuestra que el comprador elegido no pagará, el equipo habrá invertido unas pocas semanas de un equipo reducido en aprenderlo. Aprender lo mismo después del lanzamiento significa que el presupuesto del MVP ya está gastado y que el producto necesita un nuevo rumbo.
El error más común en el descubrimiento de producto
El fallo más común en esta etapa es intentar resolver para tres perfiles de cliente distintos a la vez. Parece sensato desde el punto de vista comercial, ya que más compradores potenciales parecen más ingresos, pero el resultado es un producto mediocre para todos.
La amplitud perjudica la validación de tres maneras:
- La señal de las entrevistas se promedia. Tres perfiles describen tres dolores distintos, y los requisitos que se sintetizan a partir de ellos no encajan exactamente con ninguno de los tres.
- Los comentarios sobre el prototipo se vuelven tibios. Cada grupo considera el flujo parcialmente relevante, y es fácil interpretarlo erróneamente como una validación moderada.
- El alcance del MVP crece. Cubrir las funcionalidades imprescindibles de cada perfil aumenta el presupuesto de desarrollo y retrasa el lanzamiento.
Para elegir el perfil que se validará primero, busque:
- el dolor más agudo y más frecuente
- un responsable del presupuesto al que realmente pueda llegar durante las entrevistas
- un segmento lo bastante acotado como para poder enumerar las diez primeras empresas a las que vendería
Acotar da la sensación de reducir el mercado, pero es una decisión de secuencia: un producto que conquista un segmento puede ampliarse a segmentos adyacentes cuando la retención demuestra que el núcleo funciona.
Cómo el descubrimiento de producto acelera el desarrollo SaaS
Los fundadores y los responsables de producto suelen ver el descubrimiento como semanas invertidas antes de que empiece el trabajo de verdad. Ese tiempo se recupera durante el desarrollo. Los servicios de desarrollo SaaS de Redwerk empiezan con una fase de descubrimiento que abarca el análisis de negocio, la arquitectura, las historias de usuario, el diseño inicial y el alcance del MVP, de modo que el desarrollo avanza más rápido y la primera versión se mantiene centrada y rentable.
El descubrimiento elimina del desarrollo el tipo de trabajo más lento, que son las decisiones tomadas a mitad de sprint:
- Decisiones de arquitectura cerradas pronto. La multitenencia, el aislamiento de datos y el modelo de facturación son caros de cambiar cuando los primeros clientes ya están en la plataforma. El descubrimiento los resuelve cuando todavía son un diagrama.
- Historias de usuario que los desarrolladores pueden estimar. Un equipo que empieza con historias priorizadas y un alcance del MVP acordado puede dar rangos de esfuerzo que se cumplen.
- Menos pantallas rehechas. Un problema de flujo detectado en un prototipo interactivo cuesta una revisión de diseño, mientras que el mismo problema detectado después del lanzamiento cuesta un sprint.
- Sorpresas de integración detectadas sobre el papel. El descubrimiento mapea las API y los sistemas de los que depende el producto antes de que el equipo se comprometa con un calendario.
Tampoco necesita una especificación completa para empezar. La mayoría de los equipos que acuden a Redwerk para el descubrimiento traen una idea, un mercado objetivo y una fecha límite, y la especificación es uno de los resultados del descubrimiento.
Cuándo acortar u omitir el descubrimiento
Una fase de descubrimiento completa de 2 a 6 semanas no es la decisión correcta en algunas situaciones:
- Ya tiene clientes de pago que piden una funcionalidad o un módulo concreto, y el trabajo consiste en definir su alcance.
- El producto es una herramienta interna para un grupo conocido de usuarios con el que puede hablar cualquier día.
- Una preventa o un piloto de pago ya ha validado al comprador, y lo que falta es el diseño técnico.
En esos casos, un taller breve de definición del alcance y una revisión de la arquitectura cubren el riesgo. El descubrimiento completo compensa su coste cuando el comprador, el problema o la forma de la solución siguen siendo una suposición.
Del descubrimiento de producto al MVP
Un proceso de descubrimiento terminado entrega al equipo de desarrollo un paquete, y la calidad de ese paquete decide lo rápido que avanza el MVP. En Redwerk suele incluir:
- un perfil de cliente objetivo bien definido y una hipótesis de valor contrastada con él
- un alcance del MVP priorizado
- un esquema de la arquitectura y las decisiones tecnológicas
- notas de integración para cada sistema externo con el que interactúa el producto
- un prototipo interactivo validado con usuarios reales
- una hoja de ruta con rangos de esfuerzo para el desarrollo
Para ver con más detalle cada uno de estos documentos y cómo acortan los plazos, consulte los entregables de la fase de descubrimiento que reducen el tiempo de desarrollo.
A veces el descubrimiento deja abierta una cuestión técnica, por ejemplo si una API de terceros puede soportar la carga prevista o si una funcionalidad de IA es lo bastante precisa para lanzarse. Una breve prueba de concepto la responde antes de empezar a desarrollar el MVP, de modo que el equipo se compromete con el plan de desarrollo sabiendo que la parte más arriesgada funciona.
La siguiente etapa es convertir ese alcance en una primera versión. Nuestra guía de MVP SaaS explica cómo construir el producto mínimo viable y hacerlo crecer hasta convertirlo en una plataforma completa.
Cómo realiza Redwerk el descubrimiento de producto para SaaS
El descubrimiento es la etapa del desarrollo de productos SaaS en la que equivocarse sale más barato. Redwerk lo aborda como la primera etapa del desarrollo de productos SaaS, con su propio alcance, equipo y presupuesto, y ha completado más de 250 proyectos de descubrimiento. Un analista de negocio o estratega de producto trabaja junto a un responsable de UX, usted está al tanto de los hallazgos de las entrevistas y de los comentarios sobre el prototipo en todo momento, y el proyecto termina con un plan de desarrollo que su equipo directivo puede aprobar.
Si tiene una idea SaaS y quiere saber si se sostiene antes de comprometer el presupuesto de desarrollo, hable con Redwerk sobre una fase de descubrimiento.
Preguntas frecuentes
¿Qué es el descubrimiento de producto?
El descubrimiento de producto es la etapa previa al desarrollo en la que un equipo confirma que merece la pena resolver un problema, elige un cliente objetivo y prueba una forma de solución con ese cliente. Normalmente incluye entrevistas con las partes interesadas, mapas del recorrido del cliente y prototipos ligeros, y termina con un alcance del MVP priorizado.
¿Cuánto dura el descubrimiento de producto para un producto SaaS?
La mayoría de las fases de descubrimiento duran de 2 a 6 semanas. La duración depende de la complejidad del producto, del número de integraciones que hay que mapear y de cuánta validación necesita todavía la idea.
¿El desarrollo asistido por IA hace innecesario el descubrimiento de producto?
No. Las herramientas de programación con IA aceleran el desarrollo, pero no pueden decirle si un cliente va a pagar. Un desarrollo más rápido lleva antes al mercado una idea sin validar, lo que hace que el descubrimiento sea aún más útil.
¿Cuál es la diferencia entre el descubrimiento de producto y un MVP?
El descubrimiento valida el problema, el comprador y la forma de la solución mediante entrevistas y prototipos, sin código de producción. Un MVP es el primer producto funcional, construido a partir del alcance que produjo el descubrimiento y lanzado a clientes reales.
¿Necesito una especificación detallada antes de empezar el descubrimiento de producto?
No. El descubrimiento es de donde sale la especificación. Los equipos suelen empezar con una idea, un mercado objetivo y una serie de supuestos, y terminan con historias de usuario, un esquema de la arquitectura y un alcance del MVP.
Descubra cómo ayudamos a AWE Learning a migrar de las instalaciones a la nube y a llegar a usuarios fuera de EE. UU. implementando una solución SaaS escalable
