Lean Startup: Fundamentos (1/4)

The Lean Startup in a Nutshell I: Foundations

I remembered a specific moment from my very first startup. It was the moment I realized my company was going to fail. My cofounder and I were at our wits’ end. The dot-com bubble had crashed, and we had spent all of our money. We were trying desperately to raise more, and we could not. The scene was perfect: it was raining, we were arguing in the street. We literally couldn’t agree on where to walk next, and so we parted, in anger, heading in opposite directions. (...)

It remains a painful memory. We had begun as friends, and ended as enemies. The company limped along for months after, but our situation was hopeless. Looking back, I know our failure was inevitable, because we had no clue. It seemed we were doing everything right: we had a great product, a brilliant team, amazing technology, and the right idea at the right time. (...) But despite a promising idea, we were nonetheless doomed from day one, because we did not know the process we would need to use to turn our product insights into a great company.

– Eric Ries, Startup Lessons Learned

When I first read about the concept of the Lean Startup in Eric's blog, it was a fragmented set of ideas, case studies and practices – most of them useful, many of them thought-provoking. Little did I know that it would take this collection of thoughts only a few years to turn into a global movement and a coherent theory of entrepreneurship.

And while the orignal story of the Lean Startup yet remains to be written, let me try to give a practioner's overview of both the theoretical foundations of the Lean Startup as well as the specific tools and techniques it employs to achieve maximum efficiency. The Lean Startup in a Nutshell series will walk you through each of the different building blocks of the Lean Startup, and hopefully turn you into a Lean Startup expert in no time.

None of the ideas presented in this series are original ones. They have all been extracted from the works of Eric Ries, Steve Blank, and other evangelists of the Lean Startup movement.

The startup as an experiment

A startup is not a small version of a larger company. It is en entirely different kind of organization, driven by different goals and different needs. In other words: The dollhouse theory of startups is wrong. Neither does a startup need the same departments – engineering, marketing, QA, finance, support, etc. –, nor should it follow the same product development methodology as its hypothetical larger counterpart.

While an established business focuses on executing and scaling a proven model, a startup is essentially an experiment. It is a human institution designed to create something new under conditions of extreme uncertainty – meaning that both the solution to the supposed problem as well as the problem itself are unknown. The purpose of the startup is to find a way of transforming the vision of its founders into a working and sustainable business model before it runs out of money.

The product development methodologies

Every organization strives to solve a problem. In an established business, the problem is well defined. For such a business, both the waterfall and the agile product development methodology may be appropriate, depending on whether the solution to the problem is known in advance or not.

In a startup, all that is certain is the vision of the founders. A startup is thus an organization in search of the right problem to solve. It must develop partial solutions to hypothetical problems while constantly gathering feedback until it is able to figure out what customers really want. The right methodology for a startup is the build-measure-learn feedback loop.

Let us review the three different product development methodologies.

• The waterfall methodology (known problem, known solution)specifies a linear plan of product or service milestones. It goes from requirements to design to implementation to testing. In the waterfall model, progress is achieved by advancing the plan. Using this definition of progress, whether product development results in success or failure entirely depends on whether the solution to the problem is accurately known in advance and whether the problem is actually a problem customers care about.

• The agile development methodology (known problem, unknown solution) is an iterative and incremental approach to software development. It emphasises frequent interactions over extensive documentation and the ability to respond to changes in specification over the linearity of advancing a pre-negotiated plan. It is perfectly suitable for situations where it is known what customers ultimately want, but where the team is unable to predict the best way to get there due to a lack of past experience solving that problem. Progress in the agile methodology is measured by lines of working code.

• The build-measure-learn feedback loop (unknown problem) is the underlying development methodology of the Lean Startup. In essence, it combines agile product development and customer development in a company-wide feedback loop of learning and discovery. In a Lean Startup, progress is measured by validated learning – by the number of full-turns through the entire feedback loop. It is important to understand that unless the whole feedback loop is completed quickly, work carried out in a single stage of the feedback loop (building, measuring, or learning) does not count as actual progress and is very probably a waste of time.

The remaining parts of the Lean Startup in a Nutshell series will discuss the specific techniques to accelerate each stage of the feedback loop in detail.

Pivots and innovation accounting

A startup consists of a vision and a strategy (a business model, i.e. a collection of hypotheses) designed to turn that vision into a real-world business that is creating sustainable value. What I particularly like about the Lean Startup framework is that within it, the vision is the only thing that remains untouched. It is thus in perfect alignment with Simon Sinek's model of the power of purpose and the built-to-last concept.

While the startup's vision functions as the guiding light, its strategy is temporary and fluid until it has been validated by subsequent iteration of the build-measure-learn feedback loop. In the Lean Startup model, a change in strategy is called a pivot, and it represents the most fundamental concept of the Lean Startup:

If you look at the real story, you'll discover this weird zig-zaggy path between the initial idea and the successful idea. (...) It's just that successful entrepreneurs, when they run into difficulty, they don't just give up and go home, but neither do they persevere the plane straight into the ground. They do this thing called the pivot. They change some elements of the business while keeping others constant. They keep a new strategy for achieving the same vision. So you pivot the strategy, you stay true to the vision.

And the premise of the Lean Startup is this: If we can reduce the time between pivots, we can increase our odds of success before we run out of money.

– Eric Ries, RailsConf 2011

In order to decide whether to pivot or not after an iteration of the feedback loop, we use innovation accounting. Innovation accounting consists of formulating and testing a set of key metrics – quantitative assumptions – by working backwards through the feedback loop:

1. What are we trying to learn next?
2. What do we need to measure in order to learn that?
3. What do we have to build to be able to measure that?

It is time to pivot whenever further iterations of the feedback loop lead to diminishing returns, whenever it becomes unlikely that the quantitative assumptions needed to validate the current strategy can be met at all.

Innovation accounting brings accountability to entrepreneurship: It enables us to know whether we are actually making progress and whether we are getting closer to realizing our vision or not. It empowers us to set goals and decide when to pivot in advance, and act accordingly once we collect the necessary validated learning.

The remaining parts of the Lean Startup in a Nutshell series will discuss each of the three stages of the feedback loop: Build, Measure, Learn.

The Lean Startup in a Nutshell series

Devianbits

Read more »

Aprendizaje validado

¿Qué es el aprendizaje validado?

Eric Ries afirma en su libro, The Lean Startup, la definición de aprendizaje validad del siguiente modo:

Aprendizaje validado no es una racionalización ex-post ó una buena historia diseñada para esconder una falla.  Es un método riguroso para demostrar progreso cuando uno esta inserto en un mundo de extrema incertidumbre en el cual un emprendimiento crece. El aprendizaje validado se demuestra siempre por mejoras positivas en la métricas del núcleo del emprendimiento.

En los negocios, especialmente durante los inicios de un emprendimiento, enfrentará un montón de fallas, sin importan cuán buenas sean su visión y sus ideas.  Muy a menudo, escondemos esas fallas pensando y creyendo que fueron parte del aprendizaje. Esta es una percepción común para la mayoría de la gente que quiere emprender y convertirse en emprendedores. Ellos creen falsamente que la falla misma es una forma de aprendizaje.

En su libro Ries enfatiza el término aprendizaje validado. Alienta el aprendizaje para que sea medido, como si fuese una métrica. De ese modo, el error no es una medida suficiente del aprendizaje a menos que ese error sea utilizado para mejorar el rendimiento. El aprendizaje validado ocurre cuando usted continúa para ensayar y mejorar sus ideas o productos, y ha resultado en un cambio positivo en su rendimiento. De más está decir, el aprendizaje validado es mensurable al contrario de la excusa usual de esconder las fallas como aprendizaje.

Read more »

Opinión: Escuchar a los clientes correctos

¿Cómo escuchar a los clientes, y no sólo las personas que hablan fuerte?

Por Eric Ries  

La frecuencia es más importante que hablar con los clientes "correctos", especialmente al principio. Usted sabrá cuando la persona que está hablando no es un cliente potencial - simplemente no entenderán lo que usted les está diciendo. En los primeros días, el truco está en encontrar a nadie entre todos los que se puede entender cuando se habla acerca de su producto.

En nuestro primer año en IMVU, pensábamos que estábamos construyendo un producto de chat  con avatares 3D. Fue sólo cuando le preguntamos a gente al azar que trajimos para las pruebas de usabilidad "¿qué piensa usted de nuestros competidores?" que aprendimos diferente. Como la gente de producto, pensamos en la competencia en términos de características del producto. Así que la comparación natural, pensamos, sería con otros productos basados ​​en avatares 3D, como Los Sims y World of Warcraft. Sin embargo, los primeros clientes todos lo comparaban con MySpace. Esto fue en 2004, y nunca había oído hablar de MySpace, y mucho menos teníamos una comprensión de las redes sociales. Es necesario escuchar que los clientes lo dicen una y otra vez para que podamos tomar una mirada seria, y, finalmente, darnos cuenta de que las redes sociales era núcleo de nuestra actividad.

Más tarde, cuando la empresa era mucho más grande, tenía a todos en nuestros equipos de ingeniería de acuerdo en sentarse en el test de usabilidad una vez al mes. No era un compromiso de tiempo enorme, pero eso significaba que todos los ingenieros estaban en contacto regular con un cliente real, lo que era muy valioso. La mayoría de las personas que construyeron nuestro producto no se era los clientes objetivo. Así que simplemente no había sustituto para ver a los clientes con el producto real, en vivo.

Hoy en día, cuando hablo con los fundadores de emprendimientos, la respuesta más común que llegar a la pregunta "¿usted habla con sus clientes?" es algo así como "sí, yo personalmente respondo a los correos electrónicos de atención al cliente." Eso es ciertamente mejor que nada, pero no es un buen sustituto para llegar de manera proactiva. Como Seth escribe esta semana en el blog de Seth's Blog: Listening to the loud people, los clientes más agresivos no son necesariamente los que uno quiere oírl. Por ejemplo, mi experiencia con los adolescentes es que son muy reacios a llamar o enviar correo electrónico pidiendo asistencia, incluso cuando tienen un problema grave. Simplemente no necesitan otra figura de autoridad en su vida.

No hay que confundir la pasión con el volumen. Las personas que son el alma de un startup en una etapa temprana son evangelistas adoptadores. Estas son personas que entienden la visión de su empresa, incluso antes de que el producto esté a la altura, y, lo más importante, van a comprar su producto, sobre esa base. En algunas situaciones, también son la minoría más que quiere llegar y ponerse en su cara cuando haces algo mal, pero no siempre. Si usted está obteniendo mucha negatividad de alguien, es más probable que sea un troll de internet - no de un evangelista temprano. (Para más información sobre evangelistas tempranos y por qué son tan importantes, vea el artículo de Steve Blank  The Four Steps to the Epiphany)

Aquí está la sugerencia de Seth Godin que quiero enfatizar:

Y aquí hay una cosa que yo haría sobre una base regular: Consigue una cámara de vídeo o tal vez una máquina de copiar y recoger comentarios y sugerencias de las personas que más importan a su negocio. A continuación, muestre los comentarios con el jefe y sus empleados y otros clientes. Hágalo regularmente. La información que expone es la retroalimentación que usted toma en serio.

No es suficiente con mirar los comentarios que viene a través de su escritorio. Usted necesita promover situaciones en las que usted - y todos los que trabajan con usted- es probable que veamos información que realmente importa. Algunas técnicas que he encontrado especialmente útil:

1.       Construya su propia encuesta de seguimiento, utilizando una metodología como  Net Promoter Score (NPS) para identificar y obtener un chequeo de rutina de los promotores (y para descartar a los detractores). Como un buen efecto secundario, NPS le da una tarjeta de informe muy fiable sobre la satisfacción del cliente.

2.       Cree un foro exclusivo para miembros, donde sólo los clientes calificados (tal vez, los clientes de pago) pueden publicar. Deje que se conecten entre sí, y también con usted. Trate a estas personas como un VIP, y escuche lo que tienen que decir.

3.       Establecer una junta de asesoramiento al cliente. Busque una docena de clientes que "hayan captado" su visión. La forma en que yo he hecho esto en el pasado (cuando yo estaba tratando con clientes muy apasionados) es hacer que elaboran periódicamente un informe de progreso del "estado de su empresa". Yo insistiría en que este informe se incluirá en los materiales en cada reunión de la junta, sin censura y sin tapujos.

Startup Lessons Learned

Read more »

Opinión: ¿Qué hace un CTO emprendedor?

¿Qué hace un director de tecnología (CTO) de un emprendimiento en realidad?

Por Eric Ries  

¿Qué hace su director de tecnología en todo el día? Muchas veces, parece que la gente está pensando que es sinónimo de "el tipo que se le paga para sentarse en la esquina y pensar pensamientos " técnicos" profundos" o "el tipo que llega a sola vez en un reorganizar mi proyecto en el último minuto por un capricho”. He tratado de no estar a la altura (¿o bajeza?) de los estereotipos, pero no es fácil. Carecemos de una definición clara y coherente del trabajo.

Cuando le he pedido a mentores míos que han trabajado en grandes empresas sobre el papel de un CTO, por lo general hablan de la importancia de ser la cara externa de la plataforma tecnológica de la empresa, un evangelista de desarrolladores, clientes y empleados. Eso es un trabajo importante, por cierto, y he tenido que hacerlo de vez en cuando. Pero no creo que la mayoría de los emprendimientos realmente tengan una necesidad de que alguien haga ese trabajo a tiempo completo.

Entonces, ¿qué quiere decir CTO, además de simplemente " técnico fundador que realmente no puede manejar a alguien?"

Siempre he asumido que no tendría que gestionar a nadie. Ser un gerente no sonaba divertido – bien metido, que realmente quiere ser responsable por las acciones de otras personas? Quiero decir, ¿usted ha visto a otras personas? ¡Ellos pueden hacer cualquier cosa! Por lo que inicialmente gravité hacia el título de director técnico, y no vicepresidente de ingeniería. Yo pensé que volvería a traer a un profesional para hacer la gestión y programación de tipo material, y que podría mantenerse enfocado en asegurar que construimos la tecnología realmente impresionante. Pero en el camino, algo extraño sucedió. Se hizo más difícil y más difícil separar el funcionamiento del software de cómo el software está estructurado. Si usted está tratando de diseñar una arquitectura para aumentar la agilidad, ¿cómo puede funcionar si algunas personas no están trabajando en Test-Driven Development (TDD) y los demás? ¿Cómo puede funcionar si algunas personas usan el pre-building y otros usan el “5 why’s” para tomar decisiones? ¿Y qué pasa si el despliegue tarda una eternidad? Algunas opciones pueden mejorar el rendimiento del software a expensas de la legibilidad, la capacidad de despliegue, o la escalabilidad. ¿Debiera tomarlos? Estos me sonaban a problemas técnicos, pero cuando lo hace cualquier tipo de análisis causal resultaban ser problemas de la gente. Y no hay realmente ninguna manera de abordar los problemas de la gente desde la barrera.

Así que terminé aprendiendo la disciplina de dirigir a otras personas. Resulta que yo no era demasiado malo en ello, y me di cuenta qué tan gratificante que puede ser. Pero desde que pasó un largo tiempo en un rol híbrido CTO / VP de Ingeniería, todavía tengo esa molesta pregunta. ¿Qué se supone qué el CTO debe hacer?

Esta es mi opinión. La tarea principal del CTO es asegurarse de que la estrategia de tecnología de la compañía sirva a su estrategia de negocios. Si esto suena demasiado simple o demasiado genérico, piense por un segundo si los hay compañías que usted conoce hace la inversa. ¿Alguna vez has oído a un técnico el uso de galimatías para hacer que suene como una idea de negocio que él o ella no le gustaban y era prácticamente imposible de implementar? Eso es lo que se debe tratar de evitar.

Voy a tratar de dividirla en cinco habilidades específicas.

• Selección de plataforma y diseño técnico - si su estrategia de negocio es crear un emprendimiento de bajo capital, altamente iterativo es mejor utilizar herramientas fundamentales que la hagan fácil en lugar de difícil. ¿Masivas bases de datos propietarias? No lo creo. ¿Puede la compañía meterse en sus herramientas cuando fallen y corregirlas? Si no, ¿quién va a insistir en cambiar a software libre y de código abierto? Cuando los proyectos son para despegar del suelo, quién puede consultar con el equipo para asegurarse de que sus planes son viables?  ¿Quién se hará responsable por el impacto de sus proyectos en la plataforma en su conjunto?       
• Ver el panorama general (en detalles gráficos) - El director técnico debe ser la persona en la sala que se puede mantener en su cabeza todo lo que su tecnología puede y no puede hacer. Eso significa saber lo que está escrito y lo que no, lo que la arquitectura puede y no puede soportar, y cuánto tiempo se tardaría en construir algo nuevo. Eso es más que dibujar diagramas de arquitectura, sin embargo. Ser capaz de ver la macro y micro al mismo tiempo es una característica de todos los técnicos realmente grande que he tenido el privilegio de trabajar con ellos.
• Proporcionar opciones - otra característica de un buen director técnico es que nunca dicen "eso es imposible" o "nunca haría eso." En su lugar, se encuentran las opciones y puede comunicar a todos en la empresa. Si el CEO quiere cambiar por completo el producto con el fin de servir a un nuevo segmento de clientes, usted necesita a alguien en la sala que pueden digerir las necesidades de la nueva (propuesta) de negocios y diseñar los costos de cada uno de los enfoques posibles. Algunos técnicos tienen una tendencia sólo para "decidir por ti" y le dará la "mejor" opción, pero eso es peligroso. No se puede tener un diálogo honesto, si una de las partes conoce todas las respuestas.
• Encontrar el 80/20 - esta fue mi parte favorita del trabajo. A veces, estás en una reunión en la que alguien quiere construir una nueva característica del producto. Y en su mente, lo tiene todo especificado de rabo a cabo. Sus rebanadas, sus cubitos, y probablemente hasta como hará para lavarte tu coche también. En mi mente, se están acumulando los costos (de un mes para que una parte, dos meses para que la otra parte, uh oh!). En un mal día, acababas de darles la noticia aleccionadora. Pero un buen día se veía de este modo. En el momento que entendía cual era el  objetivo de la característica adicional para los clientes, a veces podía ver una manera de obtener el 80% del beneficio al 20% del costo. "¿Sería usted capaz de aprender lo que usted necesita saber si esta característica sólo estuviese en rodajas, pero no en cubitos? Porque si no es necesario agregar un módulo de corte en cubitos, se puede reutilizar el condensador de flujo a través de las llamaradas solares ...." Me quedé sorprendido constantemente sobre la frecuencia con la respuesta fuese algo así como "¿en serio? ¿Cortar en cubos es lo caro? ¡Sólo lo dije como un capricho nomás!"

• Crecer a los líderes técnicos - Me gusta formalizar esta responsabilidad al final designando a algunos ingenieros como "técnico líderes" y delegar en ellos el trabajo de guiar a la dirección técnica de los proyectos más y más. Esta es la única forma de escalar. También me obligó a poner en claro qué aspectos de la dirección técnica de nuestra compañía eran realmente principios importantes, y que eran simplemente artefactos de cómo llegamos allí. Con varias personas tratando de trabajar con el mismo estándar, tenía que ser mucho más nítidos en nuestras definiciones. ¿Fue el hecho de que estábamos utilizando principalmente PHP esencial, o se podría agregar nuevas herramientas escritas en otros idiomas? ¿Fue un hecho importante o irrelevante que la mayoría de nuestro código web era de procedimiento y no orientada a objetos? ¿Y qué si alguien quería escribir su módulo en el estilo de programación orientada a objetos? Mediante la delegación y la formación, creamos un cuerpo de líderes que intervenir para proveer servicios tipo CTO a sus subordinados. Y trabajando juntos, creamos un equipo cuyo conjunto era mayor que la suma de sus partes.

Quiero agregar una última idea, aunque reconozco que es objeto de controversia, en la frontera en el límite entre la CTO y vicepresidente de ingeniería. No sé lo mucho que estoy influenciado por haber llevado dos sombreros, pero creo que es lo suficientemente importante como para salir en una extremidad y agregar.

• Aprópiese de la metodología de desarrollo - en una instalación de desarrollo de productos tradicionales, el vicepresidente de ingeniería o algún otro directivo a tiempo completo sería el responsable de asegurarse de que los ingenieros escribieran las especificaciones adecuadas, bien conectadas con control de calidad, y también ejecutaran la  "trenes" de cronogramas  para las versiones. Pero creo que en un emprendimiento lean, la metodología de desarrollo es demasiado importante para ser considerado "sólo de gestión". Si el equipo se va a utilizar TDD o escalabilidad JIT (just-in-time), por ejemplo, estas decisiones tienen un impacto enorme en cómo la arquitectura debe parecerse. Como mínimo, creo que el CTO y los líderes de tecnología tienen que ser responsables por los análisis de los defectos por análisis causal usando los 5 why’s. De lo contrario, ¿cómo pueden saber cuáles son sus puntos débiles y asegurarse de que el equipo y la arquitectura los arregle? Esa tarea requiere de alguien que ve todo el panorama.

Su director de tecnología (CTO) puede ser un gran arquitecto, evangelista, diseñador de la interfaz o depurador increíble. Esos son grandes habilidades para tener y tengo curiosidad de ver que funciona o no para usted. Yo seré el primero en admitir que mi experiencia es limitada, así que estoy recogiendo anécdotas. ¿Ha trabajado con o para un gran director de tecnología? ¿Qué los hizo tan excepcional? ¿Qué es una cosa un nuevo director de tecnología por primera vez podría aprender de ellos?

StartUp Lessons Learned

Read more »

Definición: Minimum Viable Product

Producto Mínimo Viable: una guía

 

For minimum viable product we are recommend of start with Hello world... (twitter)

Una de las más importantes técnicas de puesta en marcha una lean startup se llama el producto mínimo viable (Minimum Viable Product). Su poder sólo es comparable con la cantidad de confusión que genera, porque en realidad es bastante difícil de hacerlo. Sin duda, me tomó muchos años darle sentido.

Yo estuve encantado de ser invitado a dar una charla breve sobre el MVP en el meetup inaugural del círculo de lean startup aquí en San Francisco. Debajo encontrará el video de mi intervención, así como las diapositivas completas incrustadas. Pero yo quería decir unas palabras en primer lugar.

En primer lugar, una definición: el producto mínimo viable es la versión de un nuevo producto que permite a un equipo para recoger la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo.

Algunas advertencias en principio. El MVP, a pesar del nombre, no se trata de la creación mínima de producto. Si su objetivo es simplemente el resolver un problema muy puntual o construir algo para un lanzamiento rápido, realmente no necesita el MVP. De hecho, el MVP es bastante molesto, ya que impone una carga extra. Tenemos que manejar para aprender algo de nuestro primer producto de la iteración. En muchos casos, esto requiere una gran cantidad de energía invertida en hablar con los clientes o leer indicadores y métricas.

En segundo lugar, el uso de la definición de palabras como máximo y el mínimo significa que decididamente no es una fórmula. Se requiere un juicio para determinar, en cada contexto, hasta donde el MVP tiene sentido. Como he hablado en una entrevista anterior, el MVP original de IMVU nos tomó seis meses para ponerlo en el mercado. Eso fue una mejora muy grande en una empresa anterior, donde pasamos casi cinco años antes de lanzarlo. Sin embargo, en otra de las situaciones pasamos dos semanas en la construcción de una característica particular que absolutamente nadie quiso. En retrospectiva, dos semanas fueron demasiado tiempo. Podríamos haber descubierto que nadie quería el producto mucho antes. Como mínimo, una prueba de humo sencilla de AdWords hubiese revelado cuan totalmente errado estaba el concepto.

Minimum Viable Product

View more presentations from Eric Ries

Read more »

Organizaciones de software: La Lean Startup

Lean Startup o emprendimiento ultraligero

“Lean Startup" es un término acuñado por Eric Ries, su método aboga por la creación de prototipos rápidos diseñados para poner a prueba hipótesis sobre el mercado, y utilizar la retroalimentación de los clientes para evolucionar mucho más rápido que a través de las prácticas más tradicionales de desarrollo de productos, tales como el modelo de cascada. No es raro ver a Lean Startups liberar el código nuevo a los tiempos de producción de muchas veces al día [1], a menudo usando una práctica conocida como la implementación continua [2].

Según el New York Times, "El término ‘lean startup" fue acuñado por el Sr. Ries, de 31 años, ingeniero, empresario y blogger. Su inspiración, dice, fue el proceso de manufactura lean, afinado en las fábricas japonesas hace décadas y centrada en la eliminación de cualquier obra o inversión que no produzca valor para los clientes. "[3]

Lean startup es a veces descrito como Lean Thinking aplicada al proceso empresarial [4]. Un principio central del pensamiento Lean es reducir los residuos. Los procesos lean startup reducen los residuos mediante el aumento de la frecuencia de contacto con clientes reales, por lo tanto, de las pruebas y evitan suposiciones incorrectas del mercado tan pronto como sea posible [5]. Este enfoque trata de mejorar las tácticas empresariales históricas, reduciendo el trabajo necesario para evaluar los supuestos sobre el mercado, y disminuyendo el tiempo que toma una empresa para encontrar la tracción del mercado. Esto se conoce como producto viable mínimo (MVP).

En The Entrepreneur's Guide to Customer Development, Brant Cooper y Patrick Vlaskovits añaden un cuarto elemento, y que es el uso de potentes herramientas de análisis y de bajo costo y fácil de usar. Si bien algunas características de los lean startups se ​​han practicado durante años, la confluencia de estas tendencias es un reciente fenómeno que aumenta la velocidad de iteración o el "número de ciclos de aprendizaje por dólar", como el foco de negocios que ajustan productos a mercados. [6]

La definición de empresa ultraligera es una empresa que reduce al máximo los costes y el tiempo de salida de un producto al mercado.

La idea de la startup ultraligera es sacar un producto básico lo antes posible, ponerlo a prueba entre los clientes potenciales y recoger su feed back constantemente para desarrollarlo en función de las necesidades. Eso nos permite verificar la viabilidad en el mercado de un producto reduciendo al máximo la inversión de salida y reduciendo las tasas de fracaso.

Eric Ries, uno de los principales promotores del concepto “lean startup”

Algunas de las características de las startups ultraligera, existen hace mucho tiempo pero lo realmente innovador es la unión de todas. Los pasos para montar una empresa ultraligera son los siguientes:

·         Prototipo rápido (Rapid Prototyping): Utiliza cualquier cosa que tengas en tus manos para crear una maqueta visual de tu producto explicando las funciones y características. Un dibujo en un papel, un gráfico en powerpoint, pueden servir perfectamente. Lo importante es que el producto sea visualizable (es más fácil entender algo viéndolo que si nos lo explican). Si tu producto va sobre web o teléfono móvil, MockFlow puede convertirse en tu mejor aliado.

·         Pon a prueba tu idea: Presenta tu idea a tanta gente que sea posible. Especialmente a aquellos que pueden ayudarte a poner en marcha tu proyecto (inversores, amigos, otros emprendedores, clientes potenciales). No te obsesiones con lo que has diseñado (piensa que es sólo el punto de partida), escucha con detenimiento todas las sugerencias constructivas e introduce las mejoras que creas conveniente.

·         Pierde el miedo a que te roben la idea. La mayoría de los inversores saben que la persona y la ejecución son mucho más importantes que la idea. Por otra parte, debes tener confianza que no hay nadie mejor que tú para hacer que tu idea se convierta en realidad.

·         Acumula recursos: Si has pasado la prueba anterior, ahorra o consigue dinero para que las personas de tu equipo puedan trabajar tranquilamente entre 5 y 6 meses (tu producto tiene que estar fuera y vendiendo antes de que acabe ese periodo).

·         Lanza tu producto lo antes posible: Identifica las funcionalidades básicas de tu producto y lánzalo tan pronto como éstas sean sólidas. Piensa que con el lanzamiento no has hecho más que empezar y que, si tu idea funciona, tu trabajo consistirá en mejorar tu producto. Si puedes aprovechar soluciones en open source, hazlo (y si funciona tu idea piensa como puedes aportar en el futuro a la comunidad). Se acabó la época en la que había que reinventar la rueda cada vez.

·         Sal a vender en cuanto puedas: En cuanto tengas un producto, no esperes ni un segundo en salir a vender. Cuando lo hagas, es posible que al principio tu producto no funcione pero si escuchas detenidamente, es muy probable que los propios clientes te estén indicando que es lo que falla con tu producto y qué es lo que realmente necesitan. También te permitirá encontrar la mejor manera de hacerles entender que, aquello que ofreces, les permitirá ganar dinero o vivir mejor (al fin y al cabo, los negocios se reducen a eso).

·         Utiliza las redes sociales para crear una comunidad de amigos, entusiastas y clientes. Escucha todo lo que tengan que decir y pregúntales siempre que tengas una duda. No hay nada más poderoso que convertir a tus clientes en parte de la empresa. Si tu producto es bueno y te preocupas porque tu trabajo y tu servicio sean excelentes, el boca a boca se convertirá en tu mejor herramienta de marketing.

·         Empieza de nuevo: Una vez hayas lanzado tu producto y empezado a vender, analiza qué ha funcionado y qué ha ido mal y empieza desde el principio para lanzar nuevas funcionalidades y mejorar tus procesos y tus servicios.

Referencias

1.      "The Promise of the Lean Startup". Encontrado el 2009-08-11.

2.      "Continuous Deployment at IMVU: Doing the impossible fifty times a day". Encontrado el 2009-02-10.

3.     Lohr, Steve (2010-04-24). "Lean Start-Ups Aim to Find Customers Quickly". The New York Times. Retrieved 2011-06-10.

4.      "What is Lean about the Lean Startup?". Encontrado el 2009-12-16.

5.     "Achieving Flow in a Lean Startup". Encontrado el 2009-12-08.

6.     "The Entrepreneur's Guide to Customer Development". Encontrado el 2010-04-02.

Enlaces

§  The Lean Startup Wiki

§  TechCrunch TCTV coverage of The Lean Startup

§  Interview w/ Eric Ries of Startup Lessons Learned on The Web 2.0 Show. Eric habla acerca de la metodología y emprendedorismo del "Lean Startup".

§  The Lean Startup - First Blog Post Eric Ries introduce el término "Lean Startup" en este post de su blog, Startup Lessons Learned.

§  Philosophy Helps Start-Ups Move Faster coverage in the Wall Street Journal.

§  BusinessWeek - Embrace the Lean Startup Model

§  Diamon.com

Read more »