- Problema: el cliente objetivo sufre el dolor con frecuencia y con consecuencias significativas.
- Público: puedes identificar y llegar a personas que comparten ese problema y ese detonante.
- Solución: el flujo de trabajo actual les ayuda a avanzar mejor que su solución alternativa.
- Intercambio: darán tiempo, acceso, un cambio de comportamiento o dinero a cambio del resultado.
Casos de usoEspañol
Ciclo de validación post-MVP
Valida la idea SaaS que realmente construiste, no el pitch que tienes en la cabeza.
Trae la landing page, la demo, el repositorio, la presentación, la lista de espera o el producto en bruto. Identifica la suposición con más probabilidades de volver irrelevante el producto actual, ejecuta una prueba aprobada y deja que el comportamiento cambie la siguiente decisión.
Cuándo aplica
Separa cuatro suposiciones que los fundadores suelen mezclar.
Un producto puede superar una suposición y fallar en otra. Diagnostica el riesgo actual antes de elegir una prueba.
- Una puntuación de IA de una sola vez presentada como prueba de demanda.
- Una estadística amplia del tamaño del mercado sin evidencia de que el cliente al que puedes llegar vaya a actuar.
- Elogios de personas que no pueden o no quieren usar el producto.
- Otro sprint de funcionalidades sin una suposición explícita ni una prueba de aceptación.
El flujo de trabajo completo más pequeño
Pasa del artefacto a una única prueba falsable.
La validación es una secuencia de decisiones, no un certificado. Cada ciclo debería hacer que la siguiente inversión sea más fácil de justificar, o más fácil de detener.
- 01
Revisa el artefacto actual
Describe qué hace el producto ahora, a quién se dirige, el progreso que promete, el primer evento de valor y la acción que se le pide al visitante.
- 02
Enumera las suposiciones como afirmaciones comprobables
Escribe las suposiciones de problema, público, solución e intercambio de modo que cada una pueda ser contradicha por evidencia observable.
- 03
Elige la suposición más riesgosa
Selecciona la suposición que sea a la vez incierta y capaz de hacer que el siguiente ciclo de desarrollo sea un desperdicio. Explica por qué tiene prioridad sobre las demás.
- 04
Investiga el contexto de la decisión
Usa investigación con fuentes enlazadas para encontrar las alternativas actuales, el lenguaje de los clientes, las comunidades, los detonantes y la evidencia contradictoria. Trátala como contexto, no como prueba de demanda.
- 05
Diseña la prueba real más pequeña
Pide a personas cualificadas que realicen una acción: probar el flujo de trabajo, compartir datos, agendar un seguimiento, regresar, recomendar a alguien o pagar. Define primero el umbral y la condición de parada.
- 06
Aprueba y ejecuta la acción acotada
Revisa el objetivo, el contenido, el canal, el coste y los criterios de aceptación exactos. Mantén las publicaciones públicas, los mensajes directos, el email, los cambios de código y los despliegues dentro de sus rutas de aprobación reales.
- 07
Decide si continuar, ajustar o detenerte
Continúa cuando el comportamiento respalde la suposición; ajusta cuando el público o el flujo de trabajo estén cerca pero no sean correctos; detente cuando falten el problema central, el acceso o el intercambio.
Control verificable
Ejemplo de tarjeta de aprobación: prueba de la suposición más riesgosa
Esta es una tarjeta de tarea ilustrativa, no un resultado de cliente declarado ni un experimento completado.
- Objetivo
- Comprobar si la promesa actual de la landing page corresponde a un problema recurrente para fundadores SaaS en solitario que ya lanzaron un producto.
- Acción
- Ejecutar una investigación aprobada sobre diez planteamientos públicos actuales del problema y, después, preparar un lote de conversaciones con cinco personas para una revisión aparte.
- Objeto
- Fundadores SaaS en solitario de habla inglesa con una URL activa y evidencia reciente de un problema de demanda posterior al lanzamiento.
- Criterio de aceptación
- Devolver las URL de las fuentes, el lenguaje exacto del problema, la contraevidencia, cinco objetivos cualificados y una prueba propuesta. No tratar la frecuencia en la investigación como prueba de disposición a usar o pagar.
- Condición de parada
- Detenerse si menos de tres fuentes coinciden con el público y el detonante definidos, o si la evidencia apunta a un problema distinto del que promete la landing page.
ModificarRechazarAprobar el alcance exacto
Plantilla de traspaso de validación
Haz que la cadena del artefacto a la decisión sea revisable.
Completa este traspaso con evidencia observada del producto y la prueba reales. Los campos vacíos o contradictorios son útiles; la certeza inventada no lo es.
- Artefacto de entrada
- Enlaza la URL exacta, la instantánea del repositorio, la presentación, la demo o la versión de la landing page revisada.
- Suposición más riesgosa
- Formula una suposición falsable de problema, público, solución o intercambio.
- Por qué este riesgo
- Explica por qué un error invalidaría o redirigiría el siguiente ciclo de desarrollo.
- Prueba aprobada
- Registra el objetivo, la acción, el contenido, el canal, el coste, el umbral de aceptación y la condición de parada.
- Evidencia obtenida
- Separa el comportamiento observado, las afirmaciones directas, la falta de respuesta, los fallos, la contraevidencia y lo que sigue siendo desconocido.
- Decisión
- Elige continuar, ajustar o detenerte; indica la evidencia que respalda la elección y la siguiente acción permitida.
Tabla de decisión
Usa una escalera de validación, no una única puntuación combinada.
La evidencia se vuelve más fuerte a medida que el cliente cede más tiempo, acceso, hábitos, reputación o dinero.
Contexto
Fuentes creíbles establecen la categoría, las alternativas y el lenguaje.
Evidencia del problema
Personas cualificadas describen la frecuencia, las consecuencias y una solución alternativa actual.
Compromiso
Dan tiempo, datos, acceso, una recomendación o aceptan un siguiente paso.
Primer valor
Completan el flujo de trabajo objetivo y experimentan el progreso previsto.
Regreso
Repiten el comportamiento después del primer intento asistido.
Pago
Pagan para seguir recibiendo el valor.
Límites actuales del producto
Planifica con lo que realmente funciona hoy.
Ningún informe de investigación ni evaluador automatizado puede validar la demanda por sí solo. La validación sigue siendo específica del público, el estado del producto, la oferta, el canal y la evidencia recopilada en la prueba.
Investigación
DisponibleLa investigación aprobada puede estudiar mercados, competidores, quejas públicas y clientes potenciales, con resultados enlazados a sus fuentes.
X / Twitter
Disponible con OAuthEl trabajo aprobado en X/Twitter puede publicar y recopilar respuestas a través de una cuenta conectada.
Email en frío
Beta · requiere GmailLa ejecución de email depende de Gmail y del modo de aprobación que se muestra en la tarea.
Usa la investigación y borradores revisables, y deja la publicación pública en manos del fundador.
Anuncios
Solo planificaciónSe puede planificar una hipótesis de anuncios, pero Soloop hoy no compra ni gestiona la campaña.
Código
Disponible tras aprobaciónEl Coding Agent puede implementar y probar el cambio de producto aprobado en un sandbox.
Continúa el ciclo
Usa el siguiente recurso cuando cambie la decisión.
Preguntas frecuentes
Preguntas antes del siguiente paso.
¿Puedo validar una idea SaaS antes de construirla?
Puedes poner a prueba el problema, el público, el lenguaje y la disposición a comprometerse antes de construir. Este flujo de trabajo se centra en fundadores con un artefacto real, porque las personas pueden reaccionar a una promesa o un flujo de trabajo concretos en lugar de a una descripción abstracta.
¿Una lista de espera demuestra que la idea está validada?
No. Una lista de espera puede mostrar atención y darte personas a las que contactar, pero el uso, el regreso y el pago de personas cualificadas son señales más fuertes. Mide cada una por separado.
¿Soloop da una puntuación de validación SaaS?
No. Soloop no se presenta como un evaluador mágico de ideas. Ayuda a estructurar la investigación y la ejecución aprobadas para que el fundador pueda tomar una decisión a partir de evidencia revisable.
Trae el producto que ya tienes
Trae la suposición que necesitas poner a prueba.
Copia este brief, reemplaza los corchetes y pégalo en la página de inicio de Soloop después de seleccionar «Empieza con un proyecto». Este enlace no transfiere tu brief automáticamente. Primero comenta la prueba; la investigación y otras acciones necesitan su propia ruta de aprobación.
Este es el producto que ya construí: [URL, demo o repositorio]. Creo que [público específico] lo necesita porque [evidencia]. Mi suposición menos segura es [suposición]. Ayúdame a elegir una pequeña prueba de comportamiento, el resultado que me haría cambiar de opinión y una condición de parada. Separa la investigación pública de lo que debemos aprender de personas reales. Propón cualquier ejecución para que yo la revise primero.Empieza con un proyecto