Steve Blank: No es una versión beta, es un producto con requisitos mínimos

Hay tantas cosas que nos gustaría integrar en nuestro software para que después nuestros clientes las «prueben»... En general, se denomina «versión beta» y revela funciones que quizás no deseemos más adelante. ¿Por qué no proporcionar al cliente un producto con los requisitos mínimos? Se trata de algo más que una simple redacción.

Read this article in: Deutsch, English, Español

Hace algún tiempo publiqué un artículo muy detallado sobre «Requisitos mínimos para tu producto», que me gustaría recomendarte una vez más. Por simplicidad, en este artículo lo llamaremos «RMP», lo que se traduce aproximadamente en requisitos mínimos de producto. En nuestros dos últimos posts, los hemos dividido un poco más en términos de productos físicos y digitales, ¿de qué se trata exactamente?

Si has planificado e implementado parcialmente todas las funciones posibles de tu producto, ya puedes pensar en cuáles pueden ser relevantes para tus clientes potenciales. Pero no dejes que se te vaya de las manos y concéntrate en lo mínimo posible. En nuestro caso fue el reproductor de vídeo con capacidad de combinar múltiples pistas de voz. Cuando lo terminamos, recibimos los primeros comentarios de nuestros clientes y gradualmente desarrollamos características más relevantes. Siempre nos aseguramos de que cualquier elemento pueda usarse, comercializarse y monetizarse de la manera más autosuficiente posible.

En el pasado, todo esto era inconcebible y básicamente siempre ocurría de acuerdo con el esquema X. Idearon un concepto, calcularon los costos, luego establecieron el financiamiento, lo desarrollaron, lo probaron y al final empezaron a vender. Ya tratamos sobre esto, que también se llama «proceso de cascada». Durante muchos años, el hecho de que los ordenadores se volvieran cada vez más rápidos y que las aplicaciones fueran cada vez más ágiles ha sido un factor a tener en cuenta. Este hecho hace posible que hoy en día podamos planificar el software con mucha más facilidad para luego desarrollarlo en aplicaciones con requisitos mínimos. Mientras que en el pasado tenías que entregar regularmetne betas a tus clientes (¡desafortunadamente esto vuelve a suceder hoy en día mira Windows 10...!), en la actualidad puedes centrarte en la parte central de muchas áreas.

 

 

La diferencia esencial existe en el flujo de trabajo. Como describí anteriormente: Idea/concepto ⇨ Desarrollo ⇨ Alpha ⇨Comprobar ⇨ Beta ⇨ Comprobar ⇨ Venta del paquete completo. Tomemos el concepto del RMP, no lo definiremos como una versión objetivo 1.0, lo registraremos en el tablero de dibujo y, de ese modo, incorporaremos todas las ideas del fundador. Nos dirigimos a los clientes y les preguntamos qué es lo importante para ellos en este momento, a la hora de utilizar el producto y qué les es útil. Entonces decidimos las funciones que instalamos.

La regla de oro: incluso si parece un producto beta, ¡no usamos esa palabra! Es un producto, que hemos desarrollado perfectamente para el cliente, con sus requisitos minímos; estamos orientados al cliente de principio a fin.

 

El director general, Bernd Korz (en inglés) ha escrito este artículo. Con su experiencia como emprendedor, comparte su visión sobre las lecciones que ofrece Steve Blank. Síguenos para leer un nuevo artículo cada semana sobre las conferencias de Steve Blank.

Más información sobre Steve Blank:

 

#alugha

#multilingual

#everyoneslanguage

More articles by this producer

Videos by this producer

0:23
0:38
1:01
This website uses cookies to ensure you get the best experience on our website. Learn more in our privacy policy.