Tu MVP no es mínimo, viable ni un producto

Tu MVP no es mínimo, viable ni un producto

Cada vez que hablo sobre productos mínimos viables con fundadores de empresas emergentes impulsadas por productos, a menudo me encuentro en una conversación frustrante. El término MVP es un nombre profundamente inapropiado; un buen MVP no es viable, y ciertamente no es un producto. Lo más probable es que tampoco sea tan mínimo como quisieras, ahora que lo pienso.

En el mundo de las startups esbeltas, los fundadores tienen que estar muy concentrados en descubrir cómo fallar lo más rápido posible. Idealmente, fallas en fracasar, lo que significa que terminas con un negocio en funcionamiento. Muchos de los enfoques de “tratar de fallar” implican mirar sus oportunidades comerciales y contemplar dónde podría fallar su negocio en el futuro. Entonces ve y averigua esa parte.

No sirve de nada construir la mejor plataforma del mundo para vender Beanie Babies si toda la base de clientes ya está contenta con eBay y no cambiaría, incluso si su producto es superior. No es bueno crear un gran candado específicamente para scooters de viaje compartido si resulta que a las compañías de scooters no les importa si los roban. Sería genial si hubiera una manera de averiguar si alguien compraría su producto antes de escribir una sola línea de código.

Entonces, ¿dónde entran los MVP? Como startup, tienes una hipótesis; un MVP es la menor cantidad de trabajo que puede hacer para confirmar o disipar su hipótesis. Eric Ries, sí, el tipo que escribió “The Lean Startup”, usa el MVP de Dropbox como ejemplo. No era un producto completo, lleno de características. No era un producto con muchas características eliminadas. Era un video que mostraba cómo podría funcionar un producto. La respuesta a ese video fue la confirmación que la empresa necesitaba: si lo construyen, podrán encontrar una base de clientes para su producto aún por construir. Así que eso es lo que hicieron: Construyeron el producto y se convirtió en un gran éxito.

Diseñando un buen MVP

Diseñar un buen MVP significa pensar fuera de la caja. ¿Qué tan poco código puedes escribir? ¿Puedes salirte con la tuya sin hacer ningún diseño? Si su pregunta más importante es si puede atraer clientes por un costo de adquisición de clientes que tenga sentido, ¿podría ejecutar solo una campaña publicitaria y una página de pago, y luego simplemente reembolsar a quien realiza un pedido? Si eso suena divertido pero le preocupa el riesgo de la marca, ¿podría crear una marca falsa y obtener una respuesta para su producto?

El truco es pensar detenidamente en la hipótesis: ¿qué debe ser cierto sobre su producto, el mercado, el espacio problemático al que ingresa, los clientes que espera atraer y el panorama competitivo? ¿Qué tan seguro está de que sus suposiciones son correctas? Diseñar un buen MVP es un arte, pero comienza con una muy buena pregunta. Aquí están algunos ejemplos:

¿Podemos reducir cuatro horas de tareas contables manuales a un script que se puede ejecutar en tres minutos? Este es un MVP técnico: probablemente necesite piratear algún código para ver si puede automatizar tareas manuales de manera confiable.
¿Podemos encontrar a alguien que esté dispuesto a pagar para automatizar esta tarea? En algunos casos, la respuesta será “no”: sí, puede ahorrarle tiempo a un contador junior, pero en algunas industrias, a las personas simplemente no les importa cuánto tiempo dedican los empleados junior a realizar tareas manuales. En este caso, debe determinar si puede encontrar entre 20 y 30 clientes que estén dispuestos a pagar por ello. Recuerde que alguien que dice “oh, eso suena como una buena idea” es diferente de ellos metiéndose la mano en los bolsillos y realmente pagándole dinero.
¿Importa el diseño para este producto? Una gran cantidad de software B2B es terriblemente feo. No es que no existan buenos diseñadores, sino que simplemente no es una prioridad; las personas que tienen que usar el producto pueden preferir un mejor diseño o una UX más sencilla, pero a los que toman las decisiones no les importa, y los usuarios no tienen voz. En otras palabras: no gaste la mitad de su presupuesto de desarrollo en hacer algo más fácil de usar, si no puede encontrar un caso de negocios para ello. Especialmente si resulta que sin darte cuenta terminas desarrollando el conjunto de funciones incorrecto en el proceso.
¿Un titular nos copiará y nos destruirá? Si tiene varios titulares en su espacio, investigue un poco y vea cómo han reaccionado ante otras nuevas empresas. Si tienden a adquirirlos, genial. Si tienden a copiar sus características e innovaciones y luego aplastarlas, menos bien. Un poco de Google (y, por supuesto, leer TechCrunch para su industria) puede ahorrarle muchos dolores de cabeza en el futuro. Si los titulares están robando innovaciones de forma rutinaria, invierta más en patentes y reserve algo de dinero para abogados.
¿Esta característica tiene sentido para nuestros clientes? Puede ser que una minoría muy ruidosa de sus clientes pida la misma función, pero no sería la primera empresa en lanzar una nueva función con gran fanfarria solo para encontrarse con un encogimiento de hombros colectivo. Los clientes ruidosos no hablan por toda su base de clientes, por lo tanto, sea juicioso en la forma en que arregla su cartera de pedidos: si una característica no agrega un valor significativo a los objetivos comerciales generales de su empresa, no la priorice sobre las que sí lo hacen. Una forma de diseñar un MVP en torno a esto es simplemente agregar un botón a su interfaz de usuario y realizar un seguimiento de cuántas personas hacen clic en él. Lanza un “¡próximamente!” mensaje cuando se hace clic en él, por ejemplo. Sí, es molesto para los usuarios, pero es mucho más “económico” que gastar varios ciclos de desarrollo agregando una característica que casi nadie usará.

En pocas palabras, la clave es pensar con mucho cuidado sobre cuál es la pregunta y luego pensar en formas elegantes y discretas de hacer esa pregunta. En lugar del código de envío, ¿podría funcionar una encuesta? ¿Podría una demostración en video brindarle las respuestas que necesita? ¿Puede llamar a 50 clientes y hacerles preguntas circunspectas y ver si sugieren la característica que está pensando como una posible solución al problema? Pueden sorprenderlo de dos maneras: sus clientes pueden querer abrumadoramente lo que está sugiriendo (¡genial!), o pueden odiarlo (también genial: significa que no tiene que perder tiempo y dinero desarrollando algo que ellos no quieren). quieren) o pueden tener una forma completamente diferente de resolver el problema que da en el punto óptimo, es más barato de desarrollar y los ayuda a sentirse involucrados con su proceso.

No tengo una sugerencia para un mejor nombre para MVP, simplemente no caigas en la trampa de pensar en él como un producto, siendo viable o, necesariamente, siendo pequeño, simple o fácil. Algunos MVP son complejos. Sin embargo, la idea es gastar la menor cantidad posible de sus valiosos recursos para obtener una respuesta a sus preguntas.


Source link