Mis errores como emprendedor líder en tagUin


En noviembre de 2009 dejé Toprural para liderar un nuevo proyecto que había concebido algunos meses antes. Me fui de Toprural movido por el gusanillo emprendedor y por el deseo de liderar mi propio proyecto. Si no hubiera sido por eso, voluntariamente me hubiera quedado mucho más tiempo ya que sentía que aportaba cosas a la vez que aprendía otras muchas.
En aquel momento las redes sociales verticales estaban en pleno auge y yo venía de participar en dos proyectos muy exitosos, pensaba que mi momento había llegado. Como ya conté en un post anterior, tanto François Derbaix como José Luis Vallejo me apoyaron desde el principio, me ayudaron con el plan de negocio y me enseñaron cómo encontrar financiación. En paralelo, Javier Fernández y Alberto Rodríguez completaban el equipo emprendedor y trabajaban en ls primera beta del proyecto, que vio la luz en junio de 2009 en forma privada para algunos beta testers. Mi rol no era tan técnico como en anteriores proyectos, para eso estaba Javier. En este caso tenía que liderar el proyecto en todos sus aspectos.
Conseguimos 160.000€ de capital semilla aportado por amigos, familiares y algunos business angels lo que suponía un inmejorable punto de partida. No obstante cometí muchos errores que han hecho que hoy tagUin esté en una vía muerta. Entre tantos errores he destacado tres que creo que son los más significativos, aunque si preguntáis a mis socios, seguramente identifiquen otros muchos:

  • No crear un equipo más heterogéneo. Es uno de los errores de libro pero yo lo cometí. Los fundadores teníamos un perfil demasiado parecido y dejamos cojas áreas clave en una startup. Hacer un buen equipo es muy difícil y además uno de los factores de éxito más importante. Como fundador líder debería haber buscado un equipo más complementario.
  • Invertir demasiado pronto en marketing. En una startup que arranca con poco capital, invertir correctamente cada euro es otro de los factores de éxito y yo no lo hice bien. En mi deseo de crecer rápidamente y alcanzar unos objetivos de negocio razonables que nos permitieran cerrar con garantías la siguiente ronda de financiación, invertimos en marketing cuando nuestro producto no estaba suficientemente maduro y eso suponía que cada usuario que captábamos, no lo rentabilizábamos correctamente. Además, el capital inicial que teníamos no nos permitía hacer demasiados experimentos por lo que teníamos una bala y teníamos que acertar en la diana a la primera. Lo he comentado alguna vez a quien me pregunta sobre el tema: es mejor apuntalar y mejorar el producto antes de invertir en marketing. Si no te puede pasar como a nosotros.
  • Arrancar sin capital suficiente como para demostrar a los inversores que el proyecto tiene “tracción”. Este es quizá el punto más controvertido, sobre todo entre los más firmes defensores del emprendimiento low-cost pero me voy a explicar. Cuando un proyecto va orientado al gran público y además necesita de un volumen importante para que el modelo de negocio tenga sentido, hay que tener claro que la inversión necesaria es muy grande. Los inversores que invierten después de la ronda semilla esperan ver que el proyecto ha despejado algunas de las incógnitas del business plan y además ha encontrado un camino hacia el éxito. Mi error fue arrancar tagUin sin capital suficiente como para llegar con garantías a ese punto, sin gasolina para llegar al punto que los inversores esperan de un proyecto invertible en búsqueda de su segunda ronda de inversión. Sin esa gasolina, nos quedamos a mitad de camino, en la vía muerta en la que estamos ahora. Fueron mis ganas de emprender y mi falta de experiencia en el arranque de proyectos lo que me llevó a pensar que con 160.000€ en un proyecto como tagUin se puede llegar a ese punto, pero no creo que sea así.

Estos errores fueron, bajo mi punto de vista, los más importantes, aunque hubo otros. En diciembre de 2010 y de la mano de José Luis Vallejo a través de su empresa Medianet, Javier y yo pasamos a formar parte del equipo técnico que desarrolló un core de ecommerce para Prisa Digital en paralelo a Planeo, el site de ofertas de ocio del Grupo Prisa. Esto suponía aparcar definitivamente tagUin, dejándolo en modo supervivencia. En este momento tagUin tiene unos 40.000 usuarios registrados, aunque muy poco tráfico. De hecho estamos buscando la mejor manera de liquidar el proyecto, vendiéndolo, traspasándolo o cerrándolo.
Mi rol en Prisa fue la de responsable técnico de Planeo y product-proyect manager de ecommerce en Prisa Digital. Esta nueva fase tampoco estuvo exenta de errores. Pero eso lo contaré otro día.

Anuncios

Mis errores como CTO en Toprural


Tal y como hice en el post anterior donde repasé mis errores como CTO en BuyVIP, voy a repasar mis errores como CTO en Toprural, como parte de la serie de posts auto críticos que inicié con este post.

Me incorporé a Toprural en junio de 2008 después de dejar voluntariamente BuyVIP. Me encontré con un equipo técnico ya montado de 10 personas de los que 8 se dedicaban a desarrollo y que estaban repartidos en dos equipos: los que estaban desarrollando desde cero un nuevo Toprural en nueva tecnología y los que estaban manteniendo el antiguo Toprural. El foco era cumplir el plan de migración al nuevo Toprural (15 meses que terminaron siendo 18) junto con la implantación de un ERP (finalmente fue Microsoft Dynamics NAV) y el reciclaje del equipo encargado del mantenimiento del antiguo Toprural. No fue un aterrizaje fácil ya que una parte grande del equipo técnico no entendía la necesidad de un CTO, pensaban que no necesitaban jefe y lo peor, pensaban que la empresa dependía de ellos, lo que generaba un ambiente de ellos contra el mundo. Afortunadamente con el tiempo fueron entendiendo mejor la situación y se terminaron destapando las manzanas podridas del equipo. Allí me encontré a gente muy brillante técnicamente y alguno evolucionó de manera impresionante, siendo mi sustituto como CTO tras mi salida. A Paco le deseo lo mejor en su nueva etapa fuera de Toprural y espero que algún día podamos volver a trabajar juntos.
En esta nueva etapa me sentía muy a gusto y con la confianza de la dirección. Tanto François como Rafa creían en mi y en mi criterio y yo pude aprender mucho de ellos. Sin duda fueron buenos tiempos. Los principales errores que destaco de aquella época son:

  • No traerme a todo mi equipo de confianza. Creo que es esencial tener confianza ciega en las personas más importantes de tu equipo. En esta nueva aventura me acompañaron, algunos meses más tarde, dos de las personas de mi equipo de BuyVIP aunque una de ellas se volvió bastante pronto a BV tras no gustarle lo que allí encontró (incluso creo que yo mismo fui una de las cosas que no le gustó, aunque ya me conocía). Me costó demasiado tiempo sentirme alineado con mi equipo y eso nos impidió ir más rápido y mejor. Finalmente lo conseguí parcialmente al poder confiar plenamente en el trabajo que hacía el que fue mi sustituto.
  • No tener buen ojo con los fichajes. No todos los fichajes fueron malos ni mucho menos. Algunos fueron realmente buenos, pero unos cuantos fueron un error completo y lo peor fue que conseguí el efecto contrario al buscado: En lugar de alinearse conmigo, se alinearon con las manzanas podridas.
  • No despedir a quien debía cuando debía. Este punto suena muy duro y habrá gente que piense que soy un insensible o cosas similares pero nada más lejos de la realidad. El despido es un drama para todas las partes. Para la empresa porque tiene que prescindir de un profesional al que una vez quiso en el barco y que tiene que suplir con otra persona, con el trastorno que eso supone. Para el trabajador… Un palo muy duro. Aunque muchas veces es la mejor solución para todas las partes implicadas. El tema del despido requeriría un post aparte que escribiré cuando acabe esta serie. El caso es que debía haber limpiado la casa de manzanas podridas y haber dejado a los realmente buenos e implicados, fichando y renovando al equipo, aunque a corto plazo supusiera un retraso en loa planes. En estos casos te terminas dando cuenta que todo el tiempo que retrasas esta decisión es tiempo perdido.

Me marché de Toprural a finales de 2009 para montar tagUin. Después de pasar por dos empresas exitosas de Internet, no pude contener más el gusanillo emprendedor y decidí dar el salto, dejar un buen trabajo para montar un proyecto propio. Tuve la suerte de que muchos amigos e inversores apostaron por mi y por el proyecto, pero no estuvo exento de errores, aunque esta vez no fueron tanto técnicos o de gestión de equipos… pero eso lo cuento en el siguiente post.

Mis errores como CTO en BuyVIP


Me incorporé a BuyVIP en febrero de 2007. Primero como empleado de Medianet, empresa socia fundadora de BuyVIP, siendo CTO part-time compartiendo tareas con otros proyecto de dicha empresa. Pero rápidamente las necesidades de la empresa requerían una dedicación a tiempo completo y pasé a la plantilla de BuyVIP. En aquel momento toda la tecnología estaba externalizada en Medianet y hacía falta que BV tomara dicho control por lo que mi primera preocupación fue crear equipo propio. Para ello conté con varias personas que conocía de etapas anteriores y en las que confiaba. Era la primera vez que era CTO y de ahí vinieron muchos de mis errores. Los que más destaco son:

  • Falta de seniority. No es tanto un error mío sino una característica inherente a mi situación en aquel momento. Era la primera vez que era CTO y además no había tenido ningún espejo en el que mirarme. Por suerte, este tipo de “errores” se corrigen con el tiempo y con ejercicios de autocrítica como esta serie de posts. Ya lo he comentado en algún post anterior, un CTO no es un programador venido a más o como en mi caso en aquel momento, un jefe de proyecto venido a más.
  • No pensar a lo grande. En un proyecto como BuyVIP en el que todo va muy rápido y el crecimiento es enorme hace falta pensar a lo grande y concebir la estrategia técnica de la misma manera. Siempre intenté dar los pasos adecuados cimentados en base sólida pero en algunos momentos en BuyVIP ese no era el mejor camino.
  • No imponer más mi criterio. Derivado del primer error comentado y en un entorno donde el CEO de la empresa tiene un carácter y un empuje muy importantes y que intenta imponer su criterio en todos los órdenes de la empresa, me dejé influir en muchos aspectos en contra de mi criterio y creo que de esa influencia vinieron las peores decisiones o acciones tomadas en el departamento técnico. Debería haber sabido demostrar que mi criterio era el correcto y no dejarme influenciar. Este punto fue la principal razón de mi salida voluntaria de BV en junio de 2008.
  • No pedir ayuda. Hay veces que hay que reconocer que te hace falta ayuda. Yo quería hacerlo lo mejor posible y quería hacerlo demostrando que podía hacerlo con mi equipo pero en aquella situación lo mejor hubiera sido reconocer que hacía falta un CTO con más experiencia y ponerme a rebufo suyo para ganar experiencia y conocimientos.

De todo se aprende. Muchas veces repaso situaciones de aquella época y pienso cómo las hubiera afrontado ahora. Las cosas hubieran sido diferentes aunque a toro pasado todo se ve de otra manera.

Tal y como he dicho antes, me fui voluntariamente de BV en junio de 2008. Tomé la decisión de marcharme un par de mese antes y así lo comuniqué. El nivel de estrés que tenía junto con mi falta de feeling con la dirección de la empresa me hicieron tomar esta decisión. El siguiente paso fue incorporarme a Toprural como CTO. Pero eso lo cuento en el siguiente post…

Lo que quieres no siempre es lo que necesitas


Hace unos días ponía en twitter que una cosa es lo que quieres y otra bien distinta lo que necesitas. Esto es aplicable en todas las áreas pero hoy quiero desarrollar un poco mejor este concepto en el ámbito del desarrollo de software.

El negocio suele saber lo que quiere
Es habitual que el equipo de negocio sepa más o menos lo que quiere. El problema es que la mayoría de las veces nos transmiten al equipo técnico directamente cómo implementar la solución en lugar de la necesidad de negocio. Esto provoca que si en el equipo técnico no hay un perfil con la experiencia y conocimiento suficiente, se suele implementar directamente lo que propone el negocio. Bajo mi punto de vista es un error ya que, saben lo que quieren pero no lo que necesitan. O dicho de otra manera, saben cuál es la necesidad del negocio pero no la mejor y más eficiente manera de cubrirla.

Rascando y profundizando
Si los técnicos queremos hacer bien nuestro trabajo debemos evitar quedarnos en la info que nos transmite el equipo de negocio y rascar hasta encontrar y entender la necesidad que quiere cubrir el negocio. A partir de ahí debemos concebir la mejor solución y explicarsela al negocio, “pariendo” conjuntamente el camino a seguir. Para ello hace falta tener en el equipo técnico perfiles que sepan de negocio, que entiendan lo que hace falta y que tengan la experiencia suficiente para saber el camino a seguir. Este tema es especialmente crítico en una startup donde el time to market y el presupuesto son muy ajustados, donde no hay tiempo ni dinero para hacer pruebas. Esta experiencia y conocimiento debe venir del CTO. Por eso creo que el CTO de un startup no debe ser un programador con ganas de emprender si no un profesional con largo recorrido técnico y experiencia en el mismo sector de actividad.

No siempre es tan fácil
Pero no siempre es fácil trabajar de esa manera. Para que eso sea posible es imprescindible que desde negocio se confíe en el equipo técnico, que estén dispuestos a aceptar que los técnicos podemos aportar soluciones al negocio y que nuestra experiencia es tan válida como la suya aunque con diferente punto de vista. ¿ Creéis que esto es posible? Difícil, pero posible. Por experiencia puedo decir que muy pocas veces he podido trabajar así pero que cuando lo he hecho los resultados han sido buenos y rápidos o lo que es lo mismo, bueno y barato. Y también por experiencia puedo decir que es más fácil trabajar así en una empresa pequeña o una startup que en una gran empresa donde el trabajo de los técnicos está muy distante del negocio y el negocio no quiere escuchar al equipo técnico. Por eso prefiero las startups!!!

Qué hace falta para ser CTO


En mi anterior post sobre equipo técnico en una startup, Luis Clemente me preguntaba sobre qué hace falta para llegar a ser CTO. Tal y como le contestaba a él en ese comentario, esa reflexión tiene contenido suficiente como para escribir un post y por ello aquí estoy reflexionando sobre, lo que bajo mi punto de vista, hace falta para llegar a ser CTO.

No quiero parecer que hago una descripción de mis aptitudes y cualidades profesionales, ya que alguna de las que mencionaré yo no las tengo, pero cuando me las encuentro en otros profesionales las aprecio mucho y creo que son importantes.

Formación

El primer punto que considero básico es la formación. No quiero decir que para ser CTO hace falta ser Ingeniero Informático o de Telecomunicaciones, pero si considero casi imprescindible tener una base técnica que nos permita entender y desarrollar nuestras funciones sin limitaciones.  Como CTO vamos a necesitar saber de desarrollo, sistemas, infraestructuras, etc… además de otros conocimientos más relacionados con gestión económica, estrategia y negociación, aunque estas últimas es más normal adquirirlas durante nuestra trayectoria profesional. No descuidéis vuestra formación en ningún momento ya que en nuestra profesión tenemos que estar en continuo aprendizaje.

Experiencia

Como decía mi abuela: “más sabe el diablo por viejo que por diablo”. En el ámbito profesional muchas veces tenemos capacidad de resolver problemas o aportar soluciones cuando basamos nuestros criterios en experiencias anteriores de las que hemos aprendido qué funciona y qué no, aunque más veces aprendemos qué es lo que no funciona que al contrario. Por ello creo que un buen CTO suele ser un profesional con unos 10 años de experiencia.

Mi primer puesto de CTO fue en BuyVIP en el 2007 cuando tenía unos ocho años y medio de experiencia y aunque en aquel momento pensaba que estaba sobradamente preparado, ahora me doy cuenta que no me hubieran venido nada mal un par de años más de experiencia. Por el contrario al incorporarme en Toprural creo que tenía una madurez profesional mayor además de más experiencia y conocimiento y pude desempeñar algo mejor mis funciones, aunque quién mejor lo puede juzgar son mis jefes.

Por ello creo que no hay que tener prisa en llegar a un puesto de dirección. En varias ocasiones en mi carrera me he encontrado con buenísimos profesionales que han llegado a puestos de dirección demasiado pronto y no han tenido la madurez profesional suficiente como para asumir las responsabilidades del puesto y aceptar la presión y el stress de una forma natural, lo que en muchas ocasiones desembocó en un profesional quemado, que no hace bien su trabajo y que sufre un parón muy grande en su progresión profesional.

Buenos mentores

Ya que hemos empezado con los refranes, voy a usar uno más: “al que a buen árbol se arriba, buena sombra le cobija”. Es decir busca siempre los mejores jefes posibles e intenta aprender de ellos. En este concepto creo que yo he tenido excelentes jefes y mentores de los que he aprendido y sigo aprendiendo mucho. Por mencionar algunos: Alejandro García y Paco Romero en Capgemini, José Luis Vallejo y Gustavo García en BuyVIP y François Derbaix y Rafael Pérez-Olivares en Toprural.

A todos ellos los identifique como profesionales con más experiencia que yo y con excelente aptitudes en algunas áreas. Lo que hice fue intentar siempre aprender el máximo de ellos en cada oportunidad que tuve e intentar que no se me pegaran algunos de sus defectos (todos tenemos defectos). Sin duda ellos tienen gran parte de culpa en mi perfil profesional.

Por el contrario me he encontrado con algunos profesionales que tienen un potencial enorme y un recorrido importante, pero que, o bien no han tenido buenos jefes y mentores, o bien no han aprendido de ellos lo que deberían. Esta circunstancia les lleva muchas veces a tener experiencias y ejemplos no demasiado buenos y a imitar esos comportamientos cuando están en una situación similar.

Sin duda es esencial tener buenos jefes y aprender el máximo posible de ellos.

Jugador de equipo

Bajo mi punto de vista el trabajo técnico es un trabajo en equipo y en gran medida nuestros resultados, éxitos o fracasos dependen del trabajo y rendimiento del equipo. Por ello creo que es importante ser jugador de equipo en fases previas a ser CTO y aprender a trabajar por y para el equipo. Eso nos llevará a tener una actitud hacia los compañeros muy buena que arrastraremos cuando lleguemos a ser CTO.

Una vez que hemos llegado y en nuestros primeros meses en ese puesto creo que es básico tomarlo con la mayor humildad posible tratando de seguir haciendo equipo, respetando y apoyando al máximo a los compañeros. Sin duda obtendremos mejor rendimiento de todos y mucho más cohesión y mejor ambiente de trabajo.

Orientación a resultados

Mi experiencia es que los puestos directivos son mayoritariamente orientados a resultados. Es decir, no nos van a medir por cuánto trabajamos si no por si obtenemos los resultados adecuados. Esta orientación es importante que se adquiera cuanto antes mejor en nuestra trayectoria profesional y aprendamos a trabajar por objetivos. Si estamos acostumbrados a trabajar nuestro horario y si el trabajo sale bien y si no pues también, sin duda tendremos experiencias muy traumáticas en nuestro camino hacia ser CTO.

Visión comercial y de negocio

En este punto voy a ser un poco polémico, pero creo que merece la pena. Es habitual encontrar profesionales del área técnica que no quieren saber nada del cliente, del negocio y de la estrategia. Si éstos llegan a ser CTO’s no creo que sean demasiado buenos en su trabajo ya que un puesto directivo requiere de una visión mucho más amplia que la técnica para entender los objetivos de la empresa y poder aportar con la tecnología para conseguirlos. Igual estos profesionales de los que hablo podrán ser excelentes arquitectos técnicos o algún otro puesto de alto nivel que sea simplemente técnico, pero para ser CTO hay que tener otra visión mucho más cercana al negocio y poder aportar a mejorar el negocio con la tecnología. Esta visión y orientación al negocio no se adquiere de un día para otro y es importante ir cultivándola durante nuestra carrera profesional. Si trabajáis en consultoría, no perdáis la oportunidad de participar en reuniones con clientes y en cualquier caso intentad siempre plantearos de qué manera ayuda vuestro trabajo al negocio de vuestra empresa.

 

Creo que no me dejo ninguno de los atributos que creo necesarios para llegar a ser CTO. Como siempre me encantará conocer vuestra opinión y si consideráis que me falta algún atributo, no dudéis en comentarlo.

Equipo técnico en una startup


Hace un par de días leía el artículo Uno de los mayores problemas de las Startups es encontrar Programadores!!! que ha escrito Juan Macias en su blog. Me parece un artículo muy bueno y recomiendo su lectura.

Tras leerlo detenidamente me vinieron a la mente un montón de reflexiones que me gustaría compartir con vosotros.

Un programador es lo que es

Como bien apunta Juan en su post, un programador es aquel que es capaz de traducir a un lenguaje de programación aquellos requisitos bien definidos que le llegan. En función de su nivel, necesitará un diseño técnico más o menos elaborado, pero no podemos pedirle que de un pequeño resumen de media página sea capaz de crear toda la estructura técnica que necesita una empresa.

Un error muy común con el que me he encontrado entre los emprendedores que están emprendiendo por primera vez es pensar que con un programador con dos años de experiencia es suficiente para los primeros meses o años de vida de una startup y no hay nada más lejos de la realidad. Precisamente al principio hay que tomar decisiones muy importantes que deben ser tomadas por alguien con experiencia y criterio.  Si contamos con un programador, obtendremos lo que un programador es capaz de hacer.

El coste de un CTO

Creo que cuando un emprendedor busca equipo para su startup está siempre pensando en el coste que tendrá cada recurso y sin duda un programador con dos años de experiencia es mucho más barato que un CTO con experiencia contrastada y 10 años de trabajo a sus espaldas, pero de cada uno obtendrá cosas distintas. Como hemos comentado anteriormente, del programador obtendrá una codificación al lenguaje de programación elegido cuanto menos correcta, pero del CTO obtendrá una visión mucho más cercana al negocio, teniendo claro cómo hay que montar la arquitectura técnica para obtener un rendimiento y escalabilidad adecuada, definiendo qué funcionalidad es más crítica y definiendo correctamente las prioridades de desarrollo, siendo capaz de determinar si es mejor hacer el desarrollo in-house o externalizarlo en una factoría en India, etc… Es decir, del CTO obtendrá una visión estratégica necesaria en todo momento en una startup. ¿Qué coste tiene esto? Pues sin duda mucho más elevado que el coste del programador, pero a cambio se obtendrá lo que realmente se necesita. Creo que una alternativa viable es buscar un profesional o empresa de base técnica dispuesta a apostar por el proyecto y en la que haya una parte de remuneración económica y otra en participaciones. Un modelo similar a este es el que siguió BuyVIP con Medianet y creo que ha sido un buen modelo para ambas empresas.

Alternativas viables

En los últimos meses me han preguntado varias veces si es mejor contar con un equipo de desarrollo in-house o externalizar el desarrollo necesario para arrancar una startup. En todos los casos mi respuesta ha sido la misma: creo que ambas alternativas son buenas aunque cada una tiene sus pros y contras. En cualquier caso creo que lo mejor es contar desde el principio con un buen CTO (con participación en la empresa) que decida qué camino tomar y ejecute desde el principio al fin el plan que permita obtener los resultados necesarios. Es decir, cualquier alternativa es viable siempre que esté dirigida y gestionada por una persona con conocimiento y experiencia suficiente. Si dejamos este trabajo en manos de un CEO sin background tecnológico o un programador sin la suficiente experiencia, lo normal es que las cosas no salgan como uno espera y necesita.

Oportunidad de negocio

Sinceramente creo que hay oportunidad de negocio para una incubadora de base tecnológica. Es decir, una empresa con experiencia y conocimiento suficiente como para asesorar, desarrollar y participar, así como para invertir en startups en fase semilla, inversión parcial en trabajo y capital. Es decir, un socio tecnológico que pueda acompañar a una startup desde el principio hasta fases más avanzadas en las que debería elegantemente retirarse y recoger lo sembrado. Sin duda las sinergias entre startups serían muy beneficiosas para todas las partes.

No dudo que ya lo haya, de hecho me costa que Medianet y algunas otras consultoras tecnológicas ejercen esta función en algunos proyectos, pero en base a mi contacto con otros emprendedores creo que hacen falta más empresas/incubadoras de este tipo. Espero poder triunfar con tagUin y con los beneficios montar algo de este tipo.

Llegados a este punto me gustaría conocer vuestra opinión y experiencia creando un equipo técnico para una startup.