Desarrollo de SaaS
Producto mínimo viable: ¿qué debe demostrar tu SaaS antes de invertir más?
Un producto mínimo viable (MVP) es la versión más sencilla de una solución que permite observar si su propuesta funciona en una situación real. Para un negocio que quiere vender software por suscripción, la primera decisión es qué tendría que pasar para justificar la siguiente inversión.
La pregunta que cabe en una orden de renta
Imagina una empresa que renta iluminación para conciertos. El encargado abre un estuche de transporte y compara sus dos reflectores con la orden del evento. Los dos están ahí el miércoles, pero ventas necesita saber si puede prometerlos para el viernes. Uno regresa de otra renta esa mañana y debe pasar revisión. Una foto del estuche o una lista de existencias apenas resuelve la mitad de la consulta.
La idea del negocio es vender un SaaS de disponibilidad a otras arrendadoras. En Obediente empezaríamos con una hipótesis concreta: si ventas puede consultar por fecha las reservas, devoluciones y revisiones pendientes, podrá responder correctamente a más solicitudes sin llamar a bodega. Revisaríamos pedidos recientes con quienes los atendieron. Si la demora real está en autorizar descuentos, conviene descubrirlo antes de desarrollar un calendario.
.jpg){kind=link}
La prueba más pequeña que todavía enseña algo
Si la duda es cómo interpreta ventas una fecha de devolución, podemos preparar una pantalla navegable y pedirle a alguien que resuelva una orden conocida. Si marca el reflector como disponible antes de la revisión, ya sabemos qué regla falta explicar. La guía de prototipos de GOV.UK describe cómo utilizar estas pruebas antes de comprometerse a construir el servicio.
La siguiente duda es si ventas consultará esa información durante un turno de verdad. Para observarlo, podemos acotar el piloto a una familia de equipos y una sucursal. Bodega actualizaría las devoluciones en una vista compartida y ventas registraría su respuesta a cada solicitud. Podríamos mantener algunos pasos manuales durante la prueba. Anotar cuánto trabajo exigen evita confundir una demostración atendida por varias personas con un producto rentable.
Qué contar y qué decisión tomar con el resultado
Como ejemplo, podríamos acordar una primera revisión tras diez solicitudes consecutivas. El criterio propuesto sería que al menos ocho reciban una respuesta correcta sin llamada y que ninguna termine en una doble reserva atribuible al piloto. Bodega contrastaría cada respuesta con lo que realmente pudo entregar. Además, compararíamos el número de llamadas con el de diez solicitudes anteriores de complejidad parecida.
Si cuatro consultas siguen necesitando una llamada porque nadie registró las devoluciones, conviene revisar quién captura ese dato y en qué momento. Si las respuestas son correctas aun cuando se cruzan fechas y cambia el encargado de turno, tendría sentido ampliar la prueba a otra familia de equipos. Diez solicitudes ofrecen una señal operativa inicial. Para valorar si otras empresas pagarían una suscripción, hace falta probar esa decisión con un comprador distinto.
Qué entra en la propuesta de desarrollo
Para operar con pedidos reales, propondríamos acordar quién puede confirmar una reserva, cómo se corrige una devolución y qué ocurre si dos vendedores solicitan el mismo equipo al mismo tiempo. Una prueba de aceptación sería intentar reservar una sola unidad desde dos cuentas y comprobar que solo una recibe confirmación. Facturación, descuentos y recomendaciones pueden quedar para otra etapa si no ayudan a probar la hipótesis.
Antes de incorporar una segunda arrendadora, haría falta separar sus datos, definir cómo obtiene acceso y acordar quién dará soporte. En nuestro servicio de desarrollo de plataformas SaaS delimitamos esas decisiones contigo. A veces el resultado del piloto justifica ampliar el software; otras veces revela que una herramienta interna cubre la necesidad y que la suscripción debe esperar.