¿Cuándo es su MVP “lo suficientemente bueno” para ponerse delante de clientes potenciales?

Necesitaría saber más sobre su producto para dar una mejor respuesta, pero haré una basada en mi experiencia, SaaS B2B .

Probablemente esté centrando demasiado esfuerzo en crear el producto para que sea un producto listo para la venta (verifique esto: La compresión de Templeton), mientras está en una fase de validación, debe tener una base de usuarios lo suficientemente pequeña como para corregir los síntomas de su errores en su lugar, veamos un ejemplo.

Si se supone que su producto genera una factura en PDF, pero en algunos casos lo hace mal, su equipo de Atención al Cliente / Éxito del Cliente puede revisar todos los PDF a mano y corregirlos en el acto. Esto significa que puede implementar un control para ocultar el resultado al cliente hasta que sea validado por el ser humano, mientras que sus errores se corrigen, comienza a aflojar el control y utiliza diferentes mecanismos, como un botón de “informe de problemas” para “molestar” al Cliente. miembro del equipo.

Esta “validación humana” se usa ampliamente en Startups que todavía están descubriendo el producto, porque en MUCHOS casos, los errores en los que está invirtiendo energía ahora no existirán después de las iteraciones de validación, especialmente cuando está en la fase MVP.

El ciclo de retroalimentación con sus clientes cambiará el producto , no invierta demasiado en arquitectura e ingeniería mientras está en el descubrimiento de productos (MVP iterativos).

Cuando tiene un producto listo para la venta, se supone que debe aumentar las ventas y preocuparse por refactorizar y rediseñar su producto.

Confía en mí, tu SRP también tendrá algunos errores, si no muchos, pero la clave es mitigar el impacto que causa en tus clientes, ahora mismo puedo pensar en 3 formas principales de hacerlo:

  1. No permita que el cliente vea el error (implemente flujos como “validación humana”, para que pueda corregir el síntoma);
  2. No permita que el cliente “sienta” el error (haga que su equipo de CS actúe activamente tan pronto como ocurra, para que el cliente no perciba ningún daño. Sus primeros usuarios deberían valorarlo como un soporte al cliente proactivo );
  3. No tenga ningún error en absoluto (invierta en ingeniería para solucionarlo o cambie la forma en que funciona el sistema para que el error quede obsoleto);

La ejecución variará según el producto y el modelo comercial, pero la esencia sigue siendo la misma.

Al final, lo que importa es entregar el valor que está pagando su cliente.

No estoy de acuerdo con la opinión de que sus primeros usuarios no deberían pagar por su MVP, he vendido MVP que ni siquiera estaban cerca de “Sales Ready” y para mí es la única forma en que puedo confiar en que el cliente realmente valora mi producto lo suficiente. para pagarlo

Cuando coordiné pruebas beta, me gusta formar un grupo sub-beta. Estos son amigos / familiares y usuarios particulares que parecen particularmente apasionados (los ingenieros recientemente retirados son un sueño). Mi sub-beta obtiene versiones muy tempranas y muy toscas (incluso a veces con errores críticos) con el completo entendimiento de que esto apesta, está lleno de errores y es probable que no esté listo para una producción real, pero estoy entusiasmado con lo que Lo he hecho y quiero obtener algunos comentarios tempranos. Cuando les envío una forma de probar mi producto, me gusta enumerar todos los errores que conozco para que puedan tomar la decisión más informada sobre si incluso quieren probarlo.

Fuera de ese pequeño grupo selecto (a quien recompenso de la manera más extrema posible), tengo cuidado con mi grupo beta por dos razones:

1) Es muy fácil perder el 25% de su grupo beta con una mala versión. Demonios, los beta testers desaparecen a una frecuencia alarmante incluso cuando el producto funciona.
2) Enviar una notificación demasiado pronto les recuerda el problema y, en ocasiones, puede motivarlos a investigar otras soluciones antes de estar realmente listo para resolver el problema.

El mayor problema no son los errores, sino el beneficio. Si el software resuelve el problema del cliente el 50% del tiempo, hágalo. Un cliente que necesita desesperadamente una solución soportará accidentes esporádicos. Sus quejas también le dirán qué errores son más críticos que otros.

Pruebe con al menos 5 usuarios potenciales, obtenga sus comentarios y tome esta decisión como base.

No quieres vender un producto mínimo viable, por cierto. Desea vender un producto adorable mínimo, que entusiasme a las personas. Algunos de sus errores pueden ser cruciales / perjudiciales para eso, otros no. Deja de adivinar cuáles y obtén esa retroalimentación. Hacer que los clientes potenciales se registren no es suficiente para esto. Los necesita para iniciar sesión y usarlos repetidamente para obtener la información que necesita.

Debe ponerlo en frente de los clientes cuando espera que los comentarios que le dan sean valiosos.

Si tiene tantos errores que el único comentario que obtiene es “corregir los errores”, entonces está perdiendo el tiempo. Ya sabes que necesitas corregir tus errores.

Por otro lado, si puede esperar que los clientes puedan superar un escenario básico con éxito, entonces vale la pena probar con ellos para ver qué piensan del escenario.

Piense en el tipo de comentarios que está tratando de obtener y adapte su corrección de errores para ese fin.

Deje que sus clientes potenciales respondan eso por usted. Presente su idea / producto a clientes potenciales y obtenga 20 de ellos para inscribirse o incluso mejor pagar por adelantado.
Si están dispuestos a pagar incluso sin el producto que se está construyendo, eso demuestra que está resolviendo un problema lo suficientemente grande para ellos de manera significativa. Si no están dispuestos, el problema que está resolviendo no es significativo para sus clientes o querrían algo más del MVP.
En cualquier caso, lo sabrá en una etapa mucho más temprana y no necesita adivinar qué es lo suficientemente bueno para sus clientes.

Creo que estás complicando demasiado esto.

Un MVP es realmente la menor cantidad de código y diseño que necesita para obtener usuarios. No has mencionado nada de eso.

No puedo decirte exactamente cuándo es porque no conozco tu producto, ya sea tecnología B2C o B2B o cualquier otra cosa.

Tome lo que tiene ahora, siéntese con 3 usuarios potenciales en una habitación y haga que comiencen a usar el producto. Vea en qué dirección van. Y luego corrija los errores que son molestos o problemáticos para ellos. Olvídate del resto por ahora.

Estoy de acuerdo con usted … los errores importantes y críticos pueden ser tratados, con el equilibrio en marcha. ¿Ha proporcionado acceso público a algunos o todos los problemas de trello? Cuando la gente sabe que usted lo sabe y lo tiene en proceso, se sienten más cómodos con algunos errores aquí y allá si es nuevo … y bien podría ser más indulgente.