A partir del post de Luv Sayal sobre el caso de éxito de un iweekend llego a un ensayo de Paul Graham titulado The Hardest Lessons for Startups to Learn. Es un documento que bien merece la pena dedicar un rato a su lectura ya que hay recomendaciones muy interesantes, pero a mi me llamó la atención el texto que usó Luv para enlazarlo: realease early, release often.
El "nuevo" proyecto propio en el que estamos metidos (WTF) lleva ya un tiempo gestándose y una de las primeras cosas que hice fue plantear las ventajas y los inconvenientes de los distintos ritmos de implantación del sistema sobre el proyecto original.
Puedes empezar con una migración gradual, empezando por una primera versión con pocas funcionalidades e ir incorporando las nuevas mediante se van programando, que es más o menos lo que recomienda Paul Graham. Por contra, puedes implantar el sistema una vez el grueso de las funcionalidades ya han sido implementadas.
En cuanto al ruido generado, si vas sacando nuevas funcionalidades vas generando una especie de marea de ruido constante. En cambio con una transformación radical puedes crear un gran "impacto" que se traduzca en un gran ruido. Por contrapartida puede generar también un gran shock ante los usuarios acostumbrados a la web que ellos usaban y tan bien les iba.
Que crees que es mejor, ¿generar pequeñas olas de ruido cada cierto tiempo con una implantación gradual del sistema o implantarlo cuando está muy avanzado para intentar crear una gran ola mediática a pesar del shock que puedan recibir tus usuarios?
Bueno, te dejas que si lo
Bueno, te dejas que si lo haces poco a poco tienes más tiempo para que los usuarios te digan lo que les gusta y lo que no y más margen de maniobra. Si rehaces toda la web y luego a los usuarios no les gusta has perdido mucho más tiempo que si te lo dicen mientras van viendo los cambios.
Otra cosa es que la gente no suele tener imaginación ni paciencia cuando quieres hacer un cambio grande. Les puedes decir los cambios que harán pero es complicado para ellos llegar a imaginarlos y ver cosas incompletas les puede dar falsas impresiones.
Es que quería plantearlo más
Es que quería plantearlo más bien en cuestión de buzz, pero claro... tampoco puedes dejar al margen estos temas.
Un problema que puede
Un problema que puede aparecer cuando esperas demasiado es que alguien se adelante y su proyecto, aunque no tan completo como el tuyo, sea el que se posicione como referencia en el sector. Ya tendrán tiempo para mejorar.
Por el contrario, a nivel de Buzz creo que es mejor esperar un poco y lanzar la bomba. Pero para eso realmente tu producto/servicio/web debe tener una gran calidad.
Hace tiempo que sigo los
Hace tiempo que sigo los ensayos de Paul Graham. Mi favorito es You weren't meant to have a boss (os lo recomiendo)
Sobre lo que comentas, yo creo que hay dos situaciones bien diferenciadas: aparición de un producto nuevo, y "remodelación" de uno existente.
En el primer caso, ir ofreciendo versiones parciales del servicio te puede llevar a lograr algo muy bueno gracias al feedback de los usuarios o, en el peor de los casos, a quedarte a medio camino, debido a que puede que no despiertes el interés general con las primeras versiones -que es en parte lo que le pasó a Pownce, y de lo que tantas veces me he reído estos últimos días, como ya sabes ;)
En el segundo caso -el vuestro- creo que es más beneficiosa la política de lanzamientos frugales que comentas (cambios pequeños y continuados) ya que harán la transición de los usuarios más fácil.
Es mi opinión :)
A nivel de desarrollo, lo
A nivel de desarrollo, lo mejor es ir liberando cada poquito tiempo para tener feedback de los usuarios, tenerlo todo más controlado, generar menos burocracia de por medio, etc. Lo malo es que esto en algunos momentos va en contra del "buzz" que puedas generar.
Para mi lo mejor es el enfoque mixto. Tener una primera versión lo más simple posible pero que, a la par, sea llamativa, lanzarla haciendo todo el ruido posible y, a partir de ahí, ir liberando las nuevas funcionalidades poco a poco. Si el producto gusta, cada pequeña funcionalidad no va a generar muchísimo ruido pero si tendrás un "buzz" constante que en muchas ocasiones es más productivo que tener una ola gigantesca y acabar ahogado ;)
Gracias por enlazar,
Gracias por enlazar, Jordi.
Creo que el titulo del post lo dice todo. Si sigues ese principio, si entiendes bien el problema y ofreces una solucion innovadora, generaras buzz porque estaras aportando valor a tus usuarios. Cualquier release no genera buzz.
Así que yo diria que no te preocupes por el buzz. Ni hace falta pensar en eso. En el articulo de Paul Graham que has enlazado: http://www.paulgraham.com/startuplessons.html, mira el #4. Fear the right things.
Entiende bien el problema, ofrece una solucion buena, hazlo rapido, y pon el producto en las manos de tus usuarios. Recoge el feedback de tus usuarios y empieza el ciclo de nuevo. Unos cuantos ciclos como este haran que tu producto habra ganado la confianza de los usuarios. Eso es lo que genera buzz y convierte a tus usuarios en tus mejores armas de venta.
Luego pueden venir otros con productos mas innovadores pero tendran que convencer a tus usuarios que dejen de utilizar tu producto para utilizar el suyo. Y eso es una tarea monumental. El caso de Twitter, Jaiku y Pownce es el mejor ejemplo.
Curiosamente, tengo esta frase de Warren Buffet puesta en mi blog desde hace unos dias: "First come the innovators, then the imitators and, finally, the idiots."
Asi que como dice Paul Graham, release early, release often.
Y ahora me voy a leer mas Paul Graham... me encanta este tio!! :D
Gracias a todos por vuestros
Gracias a todos por vuestros comentarios!!! Ya os iré contando :)
Pingback
[...] partir de aquí es bueno seguir una política de release early, release often teniendo en cuenta las necesidades y las sugerencias de tus [...]
Enviar un comentario nuevo