Mostrando entradas con la etiqueta MVP. Mostrar todas las entradas
Mostrando entradas con la etiqueta MVP. Mostrar todas las entradas

sábado, 30 de junio de 2018

La economía de las pruebas gratuitas


La economía de las pruebas gratuitas

Crecimiento pirateando su proceso de registro de usuario


Kristin Eberth
Director, Marketing & Communications @ PressReader.
The Startup

Todos los fabricantes de startups y SaaS (software como servicio) han tenido este debate en algún momento: ¿deberíamos ofrecer una versión de prueba gratuita para nuevos clientes potenciales, y esperamos convertirlos luego? ¿O deberíamos darles un adelanto de nuestro producto y hacer que paguen por el acceso a todo?

Todos intuitivamente sabemos que una prueba gratuita puede ser efectiva. Siempre estoy súper entusiasmado cuando ocurre la 'Semana del queso' en mi tienda de abarrotes premium local, y aparecen pequeñas mesas de muestras de queso en todas partes. Andaré probando Brie, Parrano y Dutch Maasdammer de todo el mundo, casi felicitándome por haber obtenido muestras gratis de todos estos costosos quesos. Pero sin falta, encuentro uno o dos (o cuatro) quesos que son tan deliciosos que los tengo que comprar, incluso a precios ridículos. Lo siguiente que sé es que estoy manteniendo un stock constante de mis quesos preciados y caros, favoritos, artículos que nunca hubiera recogido si no hubiera tenido la oportunidad de probarlos primero.

A menudo, este método de venta de prueba antes de comprar simplemente funciona, simple y llanamente.

¿El software es realmente tan diferente? Quienes se oponen al método de prueba gratuita a menudo se preocupan de que los usuarios abusen del sistema, creando cuentas nuevas repetidamente con diferentes detalles de inicio de sesión y recortando los ingresos. Se cree que la vista previa de funciones limitadas da a las personas suficiente gusto para dejarlas con ganas de más, pero claramente les exige pagar si desean disfrutar el uso completo de su producto.

No estoy seguro de que esta sea una mejor solución.

Cuando niños, mis amigos y yo traíamos sombreros y gafas de sol cuando nuestras madres nos arrastraron a Costco, y volvíamos a nuestras estaciones de muestras de comida favoritas repetidas veces, con diferentes "disfraces". Pensamos que estábamos engañando a los samplers, pero la verdad es que simplemente no les importaba. La configuración de una estación de muestra para un día probablemente produjo un aumento suficiente en las ventas del producto en cuestión como para repetir el "juego" de los muestreadores. El sistema simplemente no importaba. (Sí, éramos tontos, pero ese no es el punto que estoy tratando de hacer).

¿Cuánto perjudican realmente los ingresos y el crecimiento los usuarios que abusan de las pruebas gratuitas? ¿Cuáles son los beneficios de ofrecer la versión de prueba gratuita de todos modos? Pasemos a la buena ciencia pasada de moda para descubrir.

Psicología: por qué nos gustan las cosas gratis

El principio fundamental que opera aquí es bastante sencillo. Dan Ariely, en su libro Predictably Irrational: The Hidden Forces That Shape Our Decisions, lo explica así:
La mayoría de las transacciones tienen una ventaja y una desventaja, ¡pero cuando algo es GRATIS! nos olvidamos de la desventaja. ¡GRATIS! nos da tal carga emocional que percibimos que lo que se ofrece es inmensamente más valioso de lo que realmente es. ¿Por qué? Creo que es porque los humanos tienen un miedo intrínseco a la pérdida. ¡El verdadero atractivo de FREE! está ligado a este miedo ¡No hay posibilidad visible de pérdida cuando elegimos un GRATIS! artículo (es gratis). Pero supongamos que elegimos el artículo que no es gratis. Uh-oh, ahora existe el riesgo de haber tomado una mala decisión: la posibilidad de una pérdida. Y entonces, dada la elección, optamos por lo que es gratis.

El atractivo de 'libre' es tan convincente que puede motivarnos a elegir una opción sobre otra, incluso cuando sea irracional, económicamente hablando. Si lees el libro de Dan, te encontrarás con algunos buenos ejemplos de experimentos que realizó que prueban esto.

¿Una prueba gratuita no diluye el valor percibido de mi producto?

No. La gente entiende intrínsecamente que cuando se les permite probar algo gratis, generalmente tiene un costo y solo tienen acceso gratuito durante un tiempo limitado. Piénselo de esta manera: una prueba gratuita no está regalando su producto de forma gratuita, sino que hace que su proceso de adquisición de usuario sea más efectivo. Está facilitando que las personas que necesitan y quieren que su producto se conviertan en clientes de pago. Los llevas parcialmente a bordo sin tener que responder a todas sus preguntas, dudas e inquietudes. Y desde su punto de vista, está asumiendo todo el riesgo si no le gusta su producto, en lugar de forzarlo a incurrir en un riesgo financiero. La versión de prueba gratuita ayuda a minimizar la fricción para los usuarios desde el principio.

Entonces, ¿cómo puedo saber definitivamente si mi empresa debería ofrecer una versión de prueba gratuita o no?

Si ofrece un producto SaaS que depende del pago de los usuarios por los ingresos, hay dos formas de tomar esta decisión.
  1. Haga algunas suposiciones sobre sus usuarios y adivine qué funcionará para usted y qué no. Este enfoque es defectuoso por todo tipo de razones, y menos aún porque sus competidores probablemente estén probando y optimizando su proceso de incorporación, y eventualmente lo vencerán en este juego con el gran poder de las matemáticas básicas. Es 2015. Solo estás limitando tu potencial si vas por esta ruta.
  2. Pruébelo y mire. Inicie una versión de prueba gratuita y mire sus métricas de cerca. Si no aumenta la cantidad de usuarios pagos que está incorporando, revise los puntos que mencioné anteriormente y ajuste su oferta de prueba gratuita. Mide, ejecuta pruebas, evalúa críticamente, repite. Si está considerando un enfoque diferente (como un plan de freemium), A / B prueba los dos sistemas en un conjunto de posibles usuarios y ve cuál se convierte mejor. Ejecutar pruebas como esta es tan simple y asequible que realmente no hay una buena razón para no hacerlo. ¿Por qué hacer conjeturas desinformadas cuando puede tomar decisiones educadas y basadas en datos sobre su negocio?

Diseñando la prueba gratuita perfecta

Si configuro una versión de prueba gratuita para mi producto de software y mi competencia no, todo lo que sabemos en este punto es que probablemente sea más fácil conseguir que la gente pruebe mi producto que él. De alguna manera, este es un argumento lo suficientemente bueno para un programa de prueba gratuito en sí mismo. Una de las reglas de oro de la mercadotecnia es lograr que más personas fluyan hacia su embudo de ventas. Si puede aumentar el número de personas que están expuestas a su producto ofreciendo una prueba gratuita, ya se está moviendo en la dirección correcta. Incluso si su proceso de conversión apesta, probablemente aún obtendrá más usuarios pagos simplemente moviendo a más personas a través de su embudo. Sin embargo, hay más que eso. Las pruebas gratuitas son increíblemente optimizables. Considera probar cosas como:

  1. Duración de la prueba
    Su objetivo debe ser determinar exactamente cuánto tiempo les toma a los usuarios tener un momento de '¡ay!' Con su producto, y optimizar su prueba gratuita para aprovecharlo. Está buscando el punto de inflexión crítico después del cual la mayoría de los usuarios pasan de ser casualmente interesados ​​a enganchados. Twitter es el ejemplo famoso: cuando los nuevos usuarios siguen a una masa crítica de personas, es mucho más probable que se conviertan en usuarios regulares de Twitter. (¿Te imaginas lo aburrido que sería Twitter si no estuvieras siguiendo a alguien?) Esta es la razón por la cual Twitter incorporó esto en su proceso de incorporación, con gran éxito. Para productos más complejos, puede tomar un poco más de tiempo. Una herramienta de gestión de proyectos como Basecamp requiere más tiempo para que todo un equipo cambie sus hábitos de trabajo y vea el valor de una nueva herramienta. Busque los comentarios cualitativos y cuantitativos de sus usuarios para definir claramente el momento "¡ajá!" Para su producto, y asegúrese de que la prueba gratuita les brinde el espacio suficiente para llegar a ese punto. Y si su producto no tiene un momento de '¡Ajá!' Tienes peces más grandes para freír. Intenta leer Nir Eyal's 'Hooked: Cómo crear productos que formen hábito' para obtener ayuda. 
  2. Extensiones
    ¿Qué pasa si un usuario potencial se registra para su versión de prueba gratuita, se pone un poco ocupado y se olvida de probar su producto, y luego regresa solo para encontrar que se acabó su tiempo? Parece un desperdicio desviar una buena pista que está genuinamente interesado en lo que estás vendiendo. Una extensión de prueba gratuita es una buena manera de superar esto. Trak.io acortó su versión de prueba gratuita de 30 días a 14 días, y luego implementó una extensión de prueba gratuita para los usuarios que no encontraron tiempo para probar su producto en las primeras 2 semanas. Encontraron un gran éxito con este método, y han escrito sobre él con detalles muy útiles. 
  3. Apoyo.
    Siempre es difícil mirar su propio producto con ojos nuevos. Pero es crucial que haga que su experiencia de usuario sea lo más simple y fácil de descubrir posible, para que nunca pierda la oportunidad de enganchar a un usuario. Solicite comentarios constantemente de nuevas personas que nunca antes han probado su producto. Considere forzar a los usuarios a dar algunos pasos clave (como el requisito de Twitter de seguir a otras 5 personas) antes de otorgar acceso al resto de las funciones. Pruebe varios consejos de herramientas y tutoriales, y asegúrese de que su sistema de soporte sea lo más robusto y accesible posible. Esto es especialmente importante en el complejo mundo del software empresarial / B2B, donde UX y la simplicidad a menudo son las que más chupan. ¡No pierda buenos usuarios debido al mal soporte! 
  4. Colección de pago
    Su departamento de finanzas probablemente argumentará que debe obtener la información de la tarjeta de crédito de sus usuarios de prueba de inmediato y comenzar a facturarlos cuando expire la versión de prueba. Pero recuerde, requerir esa información por adelantado simplemente agrega otro punto de fricción a su proceso inicial de incorporación. Es posible que obtenga clientes potenciales de mayor calidad de esta manera. También puede darse el caso de que un proceso de registro sin fricción y sin tarjeta de crédito atraiga a más usuarios potenciales a su redireccionamiento. Vale la pena probar para averiguarlo. 
  5. Ofertas de suscripción por primera vez.
    Considere facilitar que los usuarios de prueba paguen su producto ofreciéndoles un descuento en su primer mes / año / lo que sea una vez que expire su prueba. Para que todo el marketing-ninja lo conozca, envíeles un correo electrónico cuando expire su versión de prueba y ofrézcales otro mes gratis si refieren x número de amigos para registrarse.

En resumen, si realiza una prueba exhaustiva y pone un esfuerzo real en la optimización de su proceso de integración de usuarios, debería poder maximizar realmente cada interacción con sus posibles usuarios. ¡Una prueba gratuita es solo una cosa con la que puedes experimentar!

domingo, 22 de enero de 2012

Lean Startup: Construir (2/4)


The Lean Startup in a Nutshell II: Build

In this part of the Lean Startup in a Nutshell series, we discuss how to accelerate the first stage of the build-measure-learn feedback loop where we build code from ideas. Each technique is designed to help us build faster and eliminate waste.
Minimum viable product
In product development, the Minimum Viable Product or MVP is a strategy used for fast and quantitative market testing of a product or product feature, popularized by Eric Ries for web applications. — Wikipedia
Or, as defined by Eric Ries himself,
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. — Eric Ries, StartupLessonsLearned.com
The MVP caters to early-adopter customers:
The minimum viable product is that product which has just those features and no more, that allows you to ship a product that early adopters see and—at least some of whom—resonate with, give you money for, and start to give you feedback on. —Eric Ries, Venture Hacks interview
The MVP falls in between the maximum-feature approach—building a complete product implementing the entire vision of the startup founders—and the "release early, release often" mantra—shipping code immediately, listening to customers, implementing what customers want, repeating the process.
The MVP presupposes a clear long-term vision of a product or service which solves a core problem. It represents the smallest effort of building a product that delivers the promise of that vision to early adopters—the people who have the same visioning power as the entrepreneurs, who will be the most forgiving, and who will fill in—in their minds—the features which aren't yet there.
An MVP can be a crappy first web application, a clickable screen design, a paper prototype, or just a text, video, or graphic describing the problem and the solution embodied in the vision for the product.
Agile development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
— The Agile Manifesto 
Talking in depth about agile development would require a blog post of its own—or probably even an entire book. Let me thus assume that you are familiar with the basic aspects of the agile methodology (XPScrumTDD) and talk instead about how agile development relates to customer development.
All agile development methodologies, be it XP or Scrum or Kanban, at some point need to answer the question, "What is the most important work we should do right now?". Usually, the answer to this question takes the form of a backlog, a collection of stories to be worked on in the next iteration.
In a Lean Startup, the backlog is fed as part of the company-wide feedback loop, by the new hypotheses derived from actual customer feedback.
Continuous deployment
Remember, a Lean Startup optimizes the total time through the company-wide feedback loop. Imperative to that aim is not to "get stuck" in the build phase for longer periods of time than necessary. Whenever you're working on a current release, make it as minimal as possible. Your aim is to learn as quickly as possible whether the work you are doing makes sense.
Continuous deployment is the natural extension (and completion) ofcontinuous integration:
For those of you with some background in lean manufacturing, you may notice that integration risk sounds a lot like work-in-progress inventory. I think they are the same thing. Whenever you have code that is un-deployed or un-integrated, it's helpful to think of it as a huge stack of not-yet-installed parts in a widget factory. The more code, the bigger the pile. Continuous integration is a technique for reducing those piles of code.
— Eric Ries
What continuous deployment adds to that is to actually deliver the code to the customer to get the company-wide feedback loop running again. It means to overcome the anxiety of occasionally releasing a broken or malfunctioning product and to embrace the power of being fast and flexible enough to fix problems as they occur.
Of course, some development environments—such as the iTunes App Store—restrict the developer's ability to do continuous deployment. In that particular case, try to gain back the freedom of continuous deployment by having an alternate version of the product—a web-based client—running at a faster pace of iteration, or by relocating part of the product's magic from the client side to the server side.
Open-source components
There are two kinds of philosophies: the closed-source world of Microsoft Windows and proprietary systems, and the open-source world of harnessing the world's knowledge and giving back accordingly. I tend to resonate much more with the second philosophy, and it is at the very heart of the Lean Startup.
Leverage open-source technology to its full extent not only to keep costs down, but to increase the speed and versatility of product development early on. Open source operates using the model of commons-based peer production which is proven to be incredibly effective at creating and nourishing extensive collaborative communities and cooperative ecosystems.
If I were to include one specific tool here, it would be GitHub.
The cloud
Cloud technologies—such as cloud computing, cloud storage, SaaS offeringsand IaaS offerings—enable young tech companies to start with zero overhead and practically zero cost while being able to scale considerably onceproduct/market fit is achieved.
Today, there is almost no point in setting up your own data centers upfront, before having validated that you are actually building something people want. My newest startup uses open-source technology (e.g. Ruby on Rails) and cloud IaaS (e.g. Heroku) exclusively in order to achieve a high speed of iteration at low cost.
I believe that the advent of powerful scalable cloud infrastructures with pay-as-you-go models basically supersedes—and renders less important—Eric Ries's concept of just-in-time scalability. If you are interested in the story of just-in-time scalability, enter Eric Ries.
Cluster immune system
The concepts of agile development and continuous deployment may seem quite radical to project managers of older schools, having practiced thewaterfall-style approach to product development. When you think of a product juggernaught such as the Microsoft Windows operating system, for instance, how could you possibly even dare to think about deploying this piece of software continuously?
What if someone breaks an important feature during a deploy? What if someone interrupts the e-commerce flow of an online store system? What if someone hides the "Payout" button in an online payment system, turning the entire business into a hobby (borrowing from Eric Ries)?
These concerns are all valid—unless there are proper defenses in place to guard against such potential dangers. Test-driven development and strict continuous integration rules are among the first lines of defense. The cluster immune system is later-stage, more sophisticated, line of defense.
A cluster immune system is designed to track bad deployments—changes having unintended consequences—to the production environment in real time. It continuously measures the business's core metrics and automatically rejects and reverts changes affecting these metrics in a negative way.
A good cluster immune system would understand that a recent code change made the average order volume drop to about 50% of the original value. It would then revert the change, returning the system to the previous working state. It would also interrupt the deployment pipeline so that further changes would become impossible. It would send an e-mail to the author of the change as well as the whole development team to inform them about the problem. It would only allow deployment to resume once a human got to the root cause of the problem and understood and fixed it.
Building a cluster immune system isn't easy. It doesn't happen in a single day. Cluster immune systems should be built iteratively as well, starting simple and becoming more complex over time. Their development should be driven by the needs of the development team and the particular technology stack used by the team.
Conclusion
Building products in a Lean Startup requires technology and methodologies which enable the development team to iterate as rapidly as possible while remaining as flexible as possible at the same time. The speed of iteration is to be counter-balanced by defensive methods designed to remove anxiety from the team. Making mistakes is vital in a Lean Startup. Design the development environment so that mistakes can never have disastrous consequences.

martes, 22 de noviembre de 2011

Precios: Experimentos en un lean startup


Por Ash Maurya, un emprendedor lean que dirige un emprendimiento llamado CloudFire. Si lo desea, pase por el blog de Ash y sus tweets @ashmaurya. – Nivi

Cuánto cobrar por su producto es a la vez una de las cosas más complicadas y de las más importantes de hacerla bien. No sólo su modelo de precios debe mantenerlo en el negocio, sino que también que señalan su imagen de marca y posicionamiento. Y es más difícil de iterar en los precios que en otros elementos de su negocio. Una vez establecido un precio, bajarlo es usualmente más fácil que subirlo.
¿Debiera cobrar por mi MVP?
La mayoría de la gente elige diferir la “cuestión del precio” porque no piensan que ellos (ó el producto) están listos. Algo que oí muchas veces es que el mínimo producto viable (MVP) es por definición (vergonzosamente) mínimo. ¿Cómo se les puede ocurrir cargarle un precio?
Un producto mínimo no es sinónimo de un producto a medio hacer o defectuoso. Si usted ha seguido el proceso de desarrollo del cliente, su MVP debiera haber atacado los 3 principales problemas que los clientes han identificados como importantes y debiera resolverlos bien. You can ensure that by dedicating 80% of your efforts to improving existing features versus cranking out new ones.
Steve Blank cuece la exploración precio justo en las entrevistas de los clientes iniciales. El precio, como todo lo demás, se basa en un conjunto de hipótesis que tienen que ser probadas tempranamente. Steve sugiere que haga a los clientes potenciales si se tendría que utilizar el servicio de forma gratuita. Esto es para evaluar si la propuesta del valor del producto es convincente en absoluto. A continuación pregunta si utilizarían el servicio por $ X/año. ¿De donde salió ese X? Usted simplemente puede poner un precio y ajustarlo a lo largo del camino, ó usa el excelente guide to software pricing de Neil Davidson para empezar con una sugerencias de precios mejor argumentadas. Una vez que su MVP está construido, Steve le pide que venda su producto a adoptadores tempranos. No hay validación del cliente más clara que una venta.
Sean Ellis, por otro lado, argumenta que alcanzar la gratificación inicial del usuario (ajuste del producto/mercado) es la primera cosa que importa y sugiere mantener el precio afuera de la ecuación para no crear fricciones innecesarias:
“Creo que es más fácil evolucionar hacia ajustar el producto/mercado sin un modelo de negocio en su lugar (los usuarios son libres de probar de todo sin preocuparse por el precio). Tan pronto como haya suficientes usuarios diciendo que estarían muy decepcionados sin su producto, entonces es esencial poner en práctica rápidamente un modelo de negocio. Y será mucho más fácil para trazar el modelo de negocio de valor para el usuario percibe.”
Tanto Steve como Sean abocan por la eliminación del precio de la ecuación - pero en diferentes puntos. Steve elimina los precios durante el proceso de descubrimiento de los clientes, pero sugiere que se cobre por sus MVP. Sean elimina el precio de la MVP y le sugiere que fije precios luego que ajuste el producto/mercado. Puedo ver los méritos de ambos enfoques y preguntar cuál sería bueno para mi producto: CloudFire: Compartir fotos y video para padres muy ocupados.
¿Por qué no usar freemium?
En la superficie, freemium parece lo mejor de ambos mundos: Haga que los usuarios prueben el servicio sin tener que preocuparse acerca de los precios, luego aumente las ventas haciéndolos ingresar en el plan de mejor calidad más tarde. Sin embargo, muchas personas cometen el error de revelar demasiado en la forma gratis, lo que lleva a que haya conversiones bajas o nulas. Es la naturaleza humana - todos queremos gustar.
Más importante aún, todavía no tienen suficiente información para saber cómo fijar el precio o segmento el conjunto de características. Hice este error con mi primer producto, BoxCloud: un cliente visionario temprano me llamó y me dijo, "Me gusta mucho su producto y quieren pagar por él, pero su precio no lo requiere." Después de unas cuantas iteraciones más para segmentar el conjunto de características, he decidido renunciar al plan gratuito y simplemente ofrezco planes de premium con un período de prueba. Las ventas subieron al igual que la calidad de la información, que atribuyo a la diferencia entre la retroalimentación de los clientes frente a los usuarios.
(Hiten Shah compartió una historia similar conmigo acerca de su experiencia con Crazy Egg. Incluso 37signals ha fuertemente desenfatizado sus planes gratuitos hasta hacerlo casi nítidamente en sus páginas de precios.)
Lincoln Murphy acaba de publicar un trabajo largamente memorable sobre “The Reality of Freemium in SaaS” en al cual cubre muchos aspectos importantes para sopesar cuando se considera Freemium, tales como el concepto de quid pro quo donde incluso los usuarios gratuitos tienen que dar algo a cambio. En servicios con grandes efectos de red, la participación es suficiente. Pero la mayoría de las empresas no tienen altos efectos de red y equivocadamente persiguen usuarios en vez de clientes. Lo que más me gustó de este trabajo es el reconocimiento por parte de Lincoln de que "Freemium es una táctica de marketing, no un modelo de negocio."
Creo firmemente que, especialmente para los productos SaaS, empezando con gratuitos y mostrando el Premium más tarde (todo muy usado a esta altura) está puesto al revés. Si usted sabe que va a cobrar por su producto, comience por validar si alguien va a pagar primero. No hay mejor indicador de éxito y conduce a menos residuos en el largo plazo. Centrándose en la parte premium de un modelo freemium en primer lugar le permite realmente conocer su propuesta de valor única - el material por el que pagarán. A continuación, puede volver e inteligentemente ofrecer un plan gratuito (si usted todavía lo desea) con más inteligencia y con correctas métricas de éxito claramente definidas. Incluso si usted piensa que tiene un plan de precios uni-dimensional como lo hice yo (por ejemplo, número de proyectos), sería más útil para ello usar usuarios pagos debido a que los experimentos de fijación de precios toman un tiempo mucho más grande que otros tipos de experimentos.
Evaluando precios en entrevistas
¿Cómo hago para poner a prueba todo esto? El cambio mental más grande en el proceso de un lean startup va a pensar que usted sabe algo y probar todo lo que usted piensa que sabe.
Así que siguió el consejo de Steve Blank, y construyó algunas de las preguntas de fijación de precios en las entrevistas iniciales de los clientes cara a cara. Debido a que CloudFire es un producto re-segmentado en un mercado ya existente, los clientes potenciales se distinguen por la  competencia de precios. Esto tenía que ser equilibrado contra el valor percibido de nuestra propuesta de valor única -             Ahorro de tiempo con el intercambio rápido y más fácil de un montón de fotos y vídeos. A través de estas entrevistas se determinó que, al igual que sus necesidades de compartir, mis clientes potenciales valoraban esquemas de precios simples sin problemas y $ 49/año para la cantidad de fotos y videos que quieran compartir era un precio justo que estaban dispuestos a pagar. Ese fue el precio que le puse una vez que mi MVP estaba listo.
Prueba de precios en la web
Yo quería correr la misma serie de pruebas de fijación de precios con los visitantes web que hice durante mis entrevistas. Faltándome pruebas A/B por hacer y de una versión gratuita y otra paga del  MVP, la cual es técnicamente ilegal (actualización) e injusto para hacerle pagar a los clientes, decidí hacer un split-test (prueba A/B) de 3 productos diferentes con 3 precios diferentes:
1.       $49/año para compartir fotos y videos ilimitados
2.      $24/año para compartir fotos ilimitadamente
3.      GRATIS para 500 fotos
Los dos primeros planes tienen un período de evaluación de 14 días gratis pero en el caso de la tercera opción es gratis para siempre. Aquí algunas de las variaciones que testeé:
Original: Plan simple ilimitado
Estea es la opción simple que descubrí durante las entrevistas de descubrimiento del cliente. La usé como control.

Variación 2: Planes múltiples
Segmenté el producto en 2 ofertas: fotos y videos ilimitados y fotos ilimitadas solamente. Quería evaluar la sensibilidad del precio y determinar su interés en compartir vídeos. No hubo mucha gente a la que entrevisté que estuviesen tomando muchos videos, pero todos pensaban que iban a tomar más videos en el futuro.

Variación 3: Freemium
Esta tiene los 2 planes de arriba junto con un plan gratuito limitado. Si, este plan es freemium. Quería medir si un plan gratis limitado conduciría desproporcionadamente redirigiría el correcto tipo de tráfico (padres ocupados en mi caso).

Variación 4: Sin precios durante el período introductorio
He añadido una cuarta variación para probar el consejo de Sean Ellis en la eliminación de los precios hasta en forma de producto/mercado, pero he probado de otra manera. No me sentía cómodo en ofrecer el producto completo a un precio y de forma gratuita, al mismo tiempo. Así que en lugar de incluir esta página con mis pruebas A/B, incluí las pruebas con los nuevos padres que entrevisté.

Los Resultados
Primer lugar: El plan original simple— Segundo lugar en las conversiones y la que mejor rendimiento tuvo en general. Sorprendentemente, la página original fue la de mejor performance general.
Segundo lugar: Variación 3: Freemium – mayoría de conversiones pero segundo lugar en general. No sorprendentemente, la variante freemium conduce a la mayoría de las conversiones pero solo gana al plan original por 12% tiene una más baja retención. Las estadísticas de referencia combinadas con polling/correo aleatorio reveló una mayoría de usuarios que se unió eran solo curiosos (y no padres).
Tercer lugar: Variación 2: Planes múltiples – menos conversiones y el de peor performance general. La gente reaccionó menos favorablemente a los dos planes pagos.
Sin inicio: Variación 4: Sin precio durante el período introductorio. Los padres que entrevisté no entendieron el período introductorio sin explicación y fueron reacios a intentar probar el servicio sin saber cuánto iba a terminar costando el servicio. Sondeados más adelante, no estaban dispuestos a invertir el tiempo la construcción de galerías web e invitando a otros sólo para encontrar que el servicio podría ser un precio fuera de sus expectativas.
Lo que aprendí
Paga el alinear los precios con su posicionamiento global. Nuestra propuesta de valor única se basa en ser "libre de problemas y simple" y la gente parecía esperar que en el modelo de fijación de precios eso se reflejara también. Muchos de nuestros clientes actuales ya estaban pagando por su servicio de intercambio existente por lo que el salto de gratis a pago no era muy grande. Mientras que Sean sugiere la eliminación de precio antes de que el consumidor enfrente al producto, él sugiere siempre cargarle un precio para los clientes de empresas para obtener su compromiso. Este es otro caso donde el precio tiene que ser explícito. Usando el modelo de Cindy Alvarez, nuestros clientes parece ser Pobre en Tiempo, Ricos en Efectivo. Ofrecerles ensayos sin problemas y gratis era suficiente para remover el riesgo de compromiso. Garantías de devolución del dinero puede se otro modo de disminuir aún más este riesgo.
La mayor lección aprendida, sin embargo, es lo precisas que fueron mis conclusiones iniciales de las entrevistas al cliente, en comparación con todas las hipótesis que le siguieron. El precio es más arte que ciencia y sus resultados pueden variar, pero siempre que sea posible salir del edificio, habla con un cliente, y considerar pruebas de precios mejor antes que después.

lunes, 21 de noviembre de 2011

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

domingo, 20 de noviembre de 2011

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.
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

§  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.

Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Best Hostgator Coupon Code