{"id":491,"date":"2018-12-04T16:37:51","date_gmt":"2018-12-04T16:37:51","guid":{"rendered":"https:\/\/ingenieriadesoftware.es\/?p=491"},"modified":"2018-12-05T09:34:26","modified_gmt":"2018-12-05T09:34:26","slug":"otra-manera-tener-exito-startup-tecnologica","status":"publish","type":"post","link":"https:\/\/ingenieriadesoftware.es\/otra-manera-tener-exito-startup-tecnologica\/","title":{"rendered":"La otra manera de tener \u00e9xito con una startup tecnol\u00f3gica"},"content":{"rendered":"

El mito de la empresa unicornio (empresas con valoraciones por encima los mil millones de d\u00f3lares) siempre sigue el mismo patr\u00f3n: fundadores que trabajan hasta la extenuaci\u00f3n y que no paran de levantar rondas de financiaci\u00f3n millonarias con productos que pr\u00e1cticamente no tienen ingresos, por mucho que tengan much\u00edsimos usuarios.\u00a0 Hace nada el mismo Elon Musk se jactaba de trabajar 80 horas a la semana<\/a>.<\/p>\n

Pero, por suerte, hay otra manera de hacer las cosas. No es tan conocida pero s\u00ed mucho m\u00e1s razonable. Los l\u00edderes de la corriente “no tienes que dejarte la piel para conseguir el \u00e9xito con tu startup tecnol\u00f3gica” son Jason Fried<\/a>\u00a0y David Heinemeier Hansson<\/a>, creadores de la herramienta de gesti\u00f3n de proyectos Basecamp<\/a>\u00a0y, en el caso de David, tambi\u00e9n muy conocido por ser el creador de Ruby on Rails<\/a>.<\/p>\n

Su filosof\u00eda se puede resumir en 40 horas a la semana es tiempo m\u00e1s que suficiente para crear y crecer una startup tecnol\u00f3gica<\/strong>\u00a0basada en la comercializaci\u00f3n de un producto software. El c\u00f3mo conseguirlo lo explican en su libro Getting Real<\/a>\u00a0(gratis si les dais vuestro email).\u00a0\u00a0A continuaci\u00f3n os hago un resumen r\u00e1pido de las ideas principales del libro Getting Real. Como ver\u00e9is, sus opiniones van muchas veces en contra la opini\u00f3n predominantes hoy en d\u00eda pero a mi me parecen muy acertadas. Ya me cont\u00e1is cu\u00e1l es vuestra opini\u00f3n si os anim\u00e1is a dejar de lado los suculentos sueldos de los Googel, FB y cia\u00a0<\/a>\u00a0y lanzaros a la aventura (en ese caso, estos 10 mandamientos os pueden tambi\u00e9n ser \u00fatiles<\/a>)<\/p>\n

Consejos para intentar hacerte rico con tu app y sobrevivir al intento<\/strong><\/h2>\n

Menos es m\u00e1s<\/h3>\n

Competir con otros programando m\u00e1s funcionalidades, gastando m\u00e1s, contratando m\u00e1s,… s\u00f3lo te har\u00e1 perder. Haz menos que tu competencia: menos funcionalidades, menos opciones, menor estructura, menos reuniones, menos promesas …<\/p>\n

Adem\u00e1s cuanto menos “masa” (estructura, empleados, deudas,…) m\u00e1s f\u00e1cil ser\u00e1 cambiar para adaptarte a nuevas oportunidades (tipo lean startup<\/a>)<\/p>\n

Construye un software que t\u00fa mismo necesites<\/strong><\/h3>\n

Seguramente uno de\u00a0 los pocos consejos con el qu\u00e9 todo el mundo estar\u00eda de acuerdo. Si construyes algo para ti mismo, ser\u00e1s tu propio usuario y podr\u00e1s saber qu\u00e9 es importante y qu\u00e9 no, como m\u00ednimo para un usuario representativo (t\u00fa)<\/p>\n

Fin\u00e1nciate a ti mismo<\/h3>\n

Si pides dinero a otros, tendr\u00e1s que rendirles cuentas (y perder tiempo e independencia con eso). Intenta hacer lo mismo con menos recursos. Adem\u00e1s el tener estas restricciones externas estimular\u00e1 tu creatividad e innovaci\u00f3n. Tener dinero a raudales hace que muchas veces vayas a lo f\u00e1cil y hagas como todos.<\/p>\n

Adem\u00e1s, sin dinero lanzar\u00e1s antes tu producto y te preocupar\u00e1s mucho m\u00e1s para conseguir tus primeros usuarios de pago. Yo s\u00f3lo veo ventajas.<\/p>\n

Fija el tiempo y el dinero, s\u00e9 flexible con el alcance<\/h3>\n

Decide cuando vas a lanzar el producto. Y como hemos visto en el punto anterior, ten tambi\u00e9n limitaci\u00f3n con el dinero que puedes gastar. No sacrifiques ninguna las dos, en todo caso, adapta el alcance de lo que va a incluir esa primera versi\u00f3n. Esto te va ayudar tambi\u00e9n a priorizar correctamente.<\/p>\n

B\u00fascate un enemigo<\/h3>\n

A veces saber lo qu\u00e9 NO quieres ser es la mejor manera de clarificar hacia donde quieres ir. Busca lo qu\u00e9 crees que tus competidores hacen mal y convierte eso en uno de los puntos fuertes de tu app.<\/p>\n

Si no sientes la pasi\u00f3n, d\u00e9jalo<\/h3>\n

Si el software que est\u00e1s creando no te excita, d\u00e9jalo. Forzarte a trabajar en algo que no te apasiona no es la manera de tener una startup de \u00e9xito alrededor de ese producto<\/p>\n

Los tres mosqueteros<\/h3>\n

Para la primera versi\u00f3n de la app, junta un equipo de tres personas: un programador, un dise\u00f1ador y un tercero que pueda hablar con los dos. Si no te ves capaz de crear la app con s\u00f3lo un equipo de tres, reduce el alcance de esa primera versi\u00f3n.<\/p>\n

S\u00e9 t\u00fa mismo<\/h3>\n

No act\u00faes como si fueras una gran empresa. S\u00e9 personal y amigable. Elimina formalidades. Simplifica procesos. Ac\u00e9rcate al cliente, no trates de impresionarle.<\/p>\n

Define bien tu gran idea<\/h3>\n

Necesitas tener una visi\u00f3n muy clara de tu producto. \u00bfQu\u00e9 lo hace especial? Tener esto claro ayudar\u00e1 a tomar todas las dem\u00e1s decisiones.<\/p>\n

Ignora los detalles<\/h3>\n

No t\u00e9 preocupes por las peque\u00f1as cosas cuando est\u00e9s empezando. No dejes que te despisten del objetivo importante.<\/p>\n

Ignora los problemas que no tienes<\/h3>\n

Evita planear para todas las cosas que pueden suceder en un futuro. No t\u00e9 preocupes sobre como vas a escalar la web para cuando tengas 100.000 usuarios cuando no tienes ni diez. Toma decisiones justo en el momento en qu\u00e9 haga falta. Adem\u00e1s toda decisi\u00f3n es temporal, la puedes cambiar luego. Y si te equivocas tampoco matar\u00e1s a nadie (suponiendo que est\u00e9s creando una aplicaci\u00f3n web y no\u00a0 un software para cirug\u00eda cerebral)<\/p>\n

Busca los consumidores ideales<\/h3>\n

Focal\u00edzate en el sector del mercado que es perfecto para tu startup. Si intentas contentar a todo el mundo, acabar\u00e1s decepcion\u00e1ndolos a todos.<\/p>\n

Crea un software con car\u00e1cter<\/h3>\n

Que sea dogm\u00e1tico, con ideas claras. Qui\u00e9n tenga una opini\u00f3n diferente de la que el software promueve que busque otra soluci\u00f3n.<\/p>\n

Personifica tu producto. Tu producto tiene su propio voz. Eso lo hace reconocible a tus clientes.<\/p>\n

Implementa la mitad de funcionalidades, no funcionalidades a medias<\/h3>\n

Ve a lo esencial. Cuando crees que ya tienes la lista de funcionalidades obligatoria para la primera versi\u00f3n, c\u00f3gela y div\u00eddela en dos. Lo mismo para las opciones de configuraci\u00f3n. En la mayor\u00eda de casos, no va a importar.<\/p>\n

Para conseguirlo, di que no a cada petici\u00f3n para integrar una nueva funcionalidad. Cada vez dices que s\u00ed a una nueva feature<\/em>\u00a0est\u00e1s adoptando un hijo. Y te va a salir caro. No vas a poder darlo en adopci\u00f3n.<\/p>\n

Adem\u00e1s muchas de las veces que un cliente te pide una funcionalidad “clave” resulta que al final no era tan importante y si le dices que no se olvida de ella r\u00e1pidamente.<\/p>\n

Y sigue con esta filosof\u00eda a lo largo de la vida del producto. Madurar el producto no significa a\u00f1adir m\u00e1s funcionalidades.<\/p>\n

Construye un producto que puedas gestionar<\/h3>\n

No prometas lo que no puedas dar, ya sea porque no sabes, porque va a salir muy caro (ej: planes gratuitos) o porque no tienes la infraestructura.<\/p>\n

Pregunta a los clientes que es lo que NO quieren<\/h3>\n

A lo mejor resulta que hay funcionalidades que nadie quiere o usa. Pregunta y si es el caso elim\u00ednalas inmediatamente. Menos lastre!<\/p>\n

Saca algo al mercado cuanto antes<\/h3>\n

Tener algo que se pueda “tocar” (ejecutar) es la mejor manera de tener feedback (real) y conseguir un cierto momentum tanto interno (con los empleados) como externo (potenciales clientes).<\/p>\n

Nada mejor que testear tu idea con una app que la gente pueda utilizar.<\/p>\n

De bocetos a HTML a c\u00f3digo<\/h3>\n

Cada uno de estos tres niveles ofrece un buen equilibrio entre la calidad del feedback y el coste de realizarlo. Empieza con bocetos r\u00e1pidos para un feedback inmediato, convi\u00e9rtelo a mock-ups<\/em> de HTML para un feedback m\u00e1s elaborado y acaba, una vez todos los comentarios integrados, con la primera versi\u00f3n del c\u00f3digo.<\/p>\n

Esta estrategia tambi\u00e9n asegura que primero empiezas el producto por su interfaz. La interfaz ES el producto.\u00a0<\/strong>Esto se aplica tambi\u00e9n a las interfaces de administrador que en mucho casos son fe\u00edsimas.<\/p>\n

No compartimentes tu equipo pero d\u00e9jalos trabajar<\/strong><\/h3>\n

Aseg\u00farate que la comunicaci\u00f3n fluye y no se crean silos.<\/p>\n

Eso s\u00ed que la comunicaci\u00f3n no vaya en detrimento de la calidad del trabajo. Dales tiempo ininterrumpido de concentraci\u00f3n (estilo “deep work”<\/a>). Es entonces cuando la magia aparece. Nada de mensajes, slack, chat,… durante largos periodos de tiempo.<\/p>\n

A\u00fan mejor, no hagas reuniones.<\/p>\n

Celebra las peque\u00f1as victorias<\/h3>\n

Son la mejor manera de mantener al equipo motivado. Para asegurarte que hay cosas a celebrar puedes, por ejemplo, hace releases a menudo.<\/p>\n

Contrata poco y tarde<\/h3>\n

Tampoco deber\u00edas tener dinero para contratar mucho (si has ido siguiendo los consejos). Cuanto m\u00e1s tarde contrates mejor, sabr\u00e1s tambi\u00e9n mejor qu\u00e9 necesitas exactamente y qu\u00e9 perfil ir\u00eda bien teniendo en cuenta la cultura de la empresa.<\/p>\n

Y antes de contratar a nadie, pon los candidatos a prueba con un peque\u00f1o proyecto donde van a trabajar como freelance<\/em>. Mira tambi\u00e9n (pero sin obsesionarse) sus contribuciones a proyectos open source.<\/p>\n

Elige a generalistas por encima de especialistas.<\/p>\n

Y contrata a los que sepan escribir. No porqu\u00e9 todos tengan que dedicarse a escribir blog posts sino porque\u00a0el escribir bien es una qualidad importante en muchos aspectos del desarrollo.<\/strong><\/p>\n

La primera impresi\u00f3n tiene que ser la buena<\/h3>\n

Dise\u00f1a pensando en como ser\u00e1 la experiencia de usuario la primera vez que alguien utilice tu app.<\/p>\n

Para esto, nada mejor que tener una mentalidad defensiva. Piensa en todo momento las cosas raras que puede hacer tu usuario y prep\u00e1rate para ellas. Aunque el software funcione bien el 90% del tiempo, el cliente se acordar\u00e1 del d\u00eda en qu\u00e9 le dej\u00f3 tirado.<\/p>\n

Despu\u00e9s de la versi\u00f3n 1.0 lanza otra a los 30 d\u00edas, donde demuestres que est\u00e1s escuchando a los clientes y haciendo lo posible para mejorar esa primera impresi\u00f3n.<\/p>\n

El c\u00f3digo tan simple como puedas<\/strong><\/h3>\n

Cada vez que a\u00f1ades c\u00f3digo, la complejidad del software crece exponencialmente.<\/p>\n

Una estrategia para simplificar es cubrir menos casos y escenarios de la funcionalidad que el c\u00f3digo resuelve. Si consigues cubrir el 80% de la funcionalidad original con un 20% del c\u00f3digo que ten\u00edas, ves a por ello.<\/p>\n

Menos c\u00f3digo implica menos bugs, menos soporte, cambios m\u00e1s f\u00e1ciles,..<\/p>\n

Quieres programadores felices<\/h3>\n

No hay nada m\u00e1s productivo para la empresa que tener los programadores contentos. Esto tambi\u00e9n pasa por darles las herramientas que necesitan y por darles voz a la hora de escoger algo tan importante como los lenguajes\/frameworks a usar.<\/p>\n

Deja que los datos se vayan<\/h3>\n

No intentes esclavizar a tus consumidores (vendor lock-in<\/em>). Ofrece maneras de exportar tus datos via JSON, XML, APIs…<\/p>\n

A veces, ver\u00e1s como esto se utiliza para integrar tu producto en otras plataformas (m\u00e1s clientes) en lugar de para pasarse a la competencia.<\/p>\n

Evita perder el tiempo con documentos muertos<\/h3>\n

No crees documentos que van\u00a0 a acabar siendo in\u00fatiles o desactualizados. Esto se aplica tambi\u00e9n a los modelos, aseg\u00farate que cualquier modelo se haya hecho desde una perspectiva \u00e1gil<\/a><\/p>\n

Ofrece algo gratis y sin enga\u00f1os<\/strong><\/h3>\n

Deja que la gente experimente tu producto sin tener que pagar por ello. Si les gusta y soluciona un problema que tienen acabar\u00e1n pagando.<\/p>\n

Es tambi\u00e9n importante que el empezar a experimentar sea lo m\u00e1s r\u00e1pido posible (no pidas al cliente ning\u00fan tipo de informaci\u00f3n que no sea estrictamente necesaria).<\/p>\n

Y el cancelar deber\u00eda ser a\u00fan m\u00e1s r\u00e1pido. Y sin enga\u00f1os.<\/p>\n

Todo software necesita una web que lo promocione<\/strong><\/h3>\n

El producto no se vende ni se descubre s\u00f3lo. Dedica a la web del producto el mismo “cari\u00f1o” que al producto mismo.<\/p>\n

Utiliza esta web para atraer clientes potenciales a\u00fan antes de tener el producto listo.<\/p>\n

Oc\u00fapate tu mismo del soporte<\/h3>\n

Una vez tienes clientes, no los pierdas. Es importante que entiendas a la perfecci\u00f3n qu\u00e9 partes de tu app les hacen “sufrir”. Aseg\u00farate que todos tus programadores dan tambi\u00e9n soporte aunque sea ocasionalmente. Y nunca lo externalices.<\/p>\n

Para minimizar la necesidad de soporte, aseg\u00farate que los FAQ y la ayuda inline dan toda la informaci\u00f3n necesaria. Tener un foro tambi\u00e9n puede ayudar.<\/p>\n

 <\/p>\n

Si os ha gustado la filosof\u00eda de Basecamp, os recomiendo leer tambi\u00e9n sus otros libros: Remote<\/a>\u00a0(como tener una empresa donde la gente trabaje a distancia) y sobretodo, Rework<\/a> y It doesn’t have to be crazy at work<\/a>, donde siguen elaborando en estas ideas ya desde un punto de vista m\u00e1s general, con consejos para todo tipo de empresas.\u00a0<\/em><\/p>\n<\/span>","protected":false},"excerpt":{"rendered":"

No hace falta morir en el intento ni trabajar 80 horas a la semana para conseguir triunfar creando una app o un software de \u00e9xito. Basta con seguir los consejos que aqu\u00ed os presentamos. <\/p>\n","protected":false},"author":2,"featured_media":492,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"off","_et_pb_old_content":"

El mito de la empresa unicornio (empresas con valoraciones por encima los mil millones de dolares) siempre sigue el mismo patr\u00f3n: fundadores que trabajan hasta la extenuaci\u00f3n y que no paran de levantar rondas de financiaci\u00f3n millonarias con productos que pr\u00e1cticamente no tienen ingresos, por mucho que tengan much\u00edsimos usuarios.\u00a0 Hace nada el mismo Elon Musk se jactaba de trabajar 80 horas a la semana<\/a>.<\/p>

Pero, por suerte, hay otra manera de hacer las cosas. No es tan conocida pero s\u00ed mucho m\u00e1s razonable. Los l\u00edderes de la corriente \"no tienes que dejarte la piel para conseguir el \u00e9xito con tu startup tecnol\u00f3gica\" son Jason Fried<\/a>\u00a0y David Heinemeier Hansson<\/a>, creadores de la herramienta de gesti\u00f3n de proyectos Basecamp<\/a>\u00a0y, en el caso de David, tambi\u00e9n muy conocido por ser el creador de Ruby on Rails<\/a>.<\/p>

Su filosof\u00eda se puede resumir en 40 horas a la semana es tiempo m\u00e1s que suficiente para crear y crecer una startup tecnol\u00f3gica<\/strong>\u00a0basada en la comercializaci\u00f3n de un producto software. El c\u00f3mo conseguirlo lo explican en su libro Getting Real<\/a>\u00a0(gratis si les dais vuestro email).\u00a0\u00a0A continuaci\u00f3n os hago un resumen r\u00e1pido de las ideas principales del libro Getting Real. Como ver\u00e9is, sus opiniones van muchas veces en contra la opini\u00f3n predominantes hoy en d\u00eda pero a mi me parecen muy acertadas. Ya me cont\u00e1is cu\u00e1l es vuestra opini\u00f3n si os anim\u00e1is a dejar de lado los suculentos sueldos de los Googel, FB y cia\u00a0<\/a>\u00a0y lanzaros a la aventura (en ese caso, estos 10 mandamientos os pueden tambi\u00e9n ser \u00fatiles<\/a>)<\/p>

\u00a0<\/p>

\u00a0<\/p>","_et_gb_content_width":"","footnotes":""},"categories":[37],"tags":[198,200,199,201],"hashtags":[],"_links":{"self":[{"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/posts\/491"}],"collection":[{"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/comments?post=491"}],"version-history":[{"count":0,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/posts\/491\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/media\/492"}],"wp:attachment":[{"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/media?parent=491"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/categories?post=491"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/tags?post=491"},{"taxonomy":"hashtags","embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/hashtags?post=491"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}