Esta semana en Talent Hackers hemos querido conectar tecnología, producto y negocio. Y la mejor manera de hacerlo era conocer un poco más a Jordi Martí, Tech Manager de LIFULL Connect. ¿Y por qué? Jordi es el mejor ejemplo de profesional inquieto, que le gusta la tecnología, el desarrollo de producto y entender su impacto en el crecimiento de un negocio. Eso le ha llevado a llevar muchos pet projects entre manos y a liderar diversos equipos de desarrollo. En definitiva, a no parar quieto y a ofrecernos una entrevista entretenida donde haremos un «viaje» por distintas etapas.
Como él se presenta, Jordi Martí, tiene «un nombre muy catalán para alguien nacido en San Sebastián, y que vive en Bilbao. Mucha gente se sorprende cuando les digo que ya tengo 45 años, y eso me recuerda con orgullo la cantidad de tiempo que he vivido cerca de los ordenadores, tanto jugando con ellos como desarrollando».
Soy una persona que le gusta meterse en jaleos e involucrarse en nuevos asuntos, siempre con la intención de aprender, y compartir esos aprendizajes con la gente que me rodea. Mi pasión es poder usar la tecnología y descubrir que aquello que hago impacta de forma relevante en las personas que conozco. Es por eso que me encanta entender todo el ciclo de desarrollo de producto y de un negocio: desde “picar teclas” hasta “cómo hacer que eso pueda dar dinero”.
Tabla de contenidos
Para ti, Jordi, ¿cómo es trabajar muy de la mano de negocio y producto? ¿Cuáles han sido los mayores retos?
Durante mis más de 20 años de experiencia profesional en el mundo del software, he tenido muchas vivencias y retos en diferentes momentos de la vida que me han llevado a estar convencido de que, independientemente del rol que desempeñamos a la hora de aportar a un producto, todas las personas somos “product developers”. Por supuesto, hay personas con mayores capacidades y que disfrutan más haciendo determinadas tareas (las que englobamos dentro de “Product Manager” o de “Ingeniería de Software”, o de “Experiencia de Usuario”), pero en general todas las personas colaboramos conjuntamente y realizamos nuestras tareas conjuntamente con un único fin: aportar al producto, para hacer progresar el negocio.
Aquí tienes un artículo sobre Product Manager en el blog de Talent Hackers.
Por lo tanto, desde mi punto de vista, independientemente del rol y las tareas que ejecutamos, todas las personas debemos entender el negocio para saber cómo lo hacemos progresar con aquello que aportamos.
A lo largo de mi experiencia, he vivido muchos retos diferentes relacionados con este tema, principalmente por el estado diferente en el que se encontraba el mundo del software en cada uno de estos momentos.
Hace 20 años, cuando terminé la carrera universitaria.
Cuando terminé la carrera universitaria, hace 20 años, comencé a trabajar en una empresa de servicios de internet, en la que querían desarrollar un producto propio. No existía una cultura de producto y emprendimiento como la que conocemos ahora, y el contexto del mercado era el de la famosa burbuja puntocom. Muchas empresas se lanzaron a desarrollar negocios en internet, por el potencial que la Nueva Economía parecía traer. Sin embargo, no estábamos acostumbrados a descubrir y entregar software de una forma que nos permitiera aprender de forma rápida si el producto que construímos era el que nuestros clientes querían. Las empresas se iniciaban en garajes de dudosa salubridad y las heroicidades se forjaban alrededor de jornadas maratonianas de desarrollo que terminaban en cena con pizzas, día tras día. Desde mi punto de vista, creo que el mundo del software aprendió, en ese momento, que para construir el producto de un negocio saludable, debía encontrar un modo más sostenible de hacer software (económica y personalmente).
En el mundo de la consultoría.
Varios años después los invertí en el mundo de la consultoría, como muchas personas de mi edad. En ese momento, a través de estas grandes consultorías, desarrollamos los productos de nuestros clientes. Muchas personas del mundo del desarrollo nos esforzamos en aprender cómo gestionar mejor el proyecto de nuestros clientes (y los conflictos que surgen en una relación de cliente – proveedor), en vez de aprender a cómo desarrollar mejor el producto del negocio de nuestros clientes. Además, en nuestro país se venía de una cultura muy orientada al desarrollo industrial o de proyecto.
Aquí aprendí lo valioso que es el foco (un proyecto, un producto, un objetivo, una visión, un cliente), y entender la necesidad de negocio que se quiere cubrir detrás de cada proyecto. Sin saberlo, quería dedicarme de lleno a resolver los problemas de mis clientes, uno a uno, entendiendo de primera mano el problema. Quería ser desarrollador de su producto. Sin embargo, el contexto no era el más apto, ya que este mindset industrial y la relación cliente – proveedor me impedía, en aquella época, colaborar con el cliente de forma iterativa en su producto.
Fundando Init.
Hace 16 años, y fruto de todos estos aprendizajes (aunque probablemente sin saber verbalizarlos como lo hago actualmente), junto a otros dos socios fundamos una compañía (Init) que me permitió aprender todo esto de primera mano. Fue el momento de entender el mundo Agile, de descubrir Lean Startup, de hablar de emprendimiento e intraemprendimiento, …
Y reconocer un patrón en mi trayectoria profesional: lo que buscaba era resolver los problemas de la gente a través de la tecnología.
Todas estas metodologías tienen en común un mismo objetivo: que en el mundo digital es clave entregar software cuanto antes de forma que podamos realizar experimentos que nos informen de cómo vamos mejorando la vida de nuestros usuarios. Y para poder hacer esto, es necesario tener determinadas prácticas técnicas (las famosas prácticas XP) que nos permitan realizar cambios y ponerlos en producción cuanto antes, y determinadas prácticas y herramientas centradas en el usuario final para el descubrimiento de producto.
En los últimos meses, he cambiado de empresa con el fin de poder avanzar en mi desarrollo personal relacionado con esto último. Creo que actualmente el reto en el mundo del desarrollo de producto es que todas las personas alrededor de un mismo producto debemos aprender a colaborar de forma conjunta, escalable y sostenible; para así aportar al negocio. Mi apuesta es que para conseguir eso, todas las personas debemos olvidarnos de etiquetas, roles, puestos, perfiles y tareas, y anteponer los resultados del producto a nuestro ego.
¿Cuáles consideras que son las habilidades necesarias para desarrollar producto? ¿Qué consejos darías a los techies que quieran dar este paso para acercarse más al negocio?
Creo que lo más necesario para una persona que quiera “desarrollar producto”, es entender y experimentar, de primera mano, los valores y principios “ágiles”. Puede parecer evidente, pero no lo es tanto. En el desarrollo de software hay realidades que a priori pueden parecer anti-intuitivas. Algunos ejemplos que pueden dar una idea de lo que quiero decir:
- Para entregar más rápido, es mejor hacer menos.
- Que las personas trabajen conjuntamente y sobre un mismo tema, a la larga es más eficiente.
- La diversidad en un equipo genera mayor riqueza en el resultado, y por tanto, mayor calidad.
- En vez de pensar en el producto en exceso, es mejor empezar y aprender en el camino.
- …
Todo esto es mucho más entendible cuando experimentamos y entendemos en primera persona estos “principios ágiles”. Por lo tanto, recomendaría a cualquier persona a vivir experiencias que les permitan entenderlo: asistiendo a eventos, leyendo libros, leyendo artículos, colaborando en productos pequeños (open source, pet projects, etc.). Cualquier excusa que nos haga entender de primera mano por qué queremos entregar pronto y de forma contínua para construir la mejor solución para un tipo de usuario.
Todo este mindset creo que cristaliza muy bien en el concepto que Eduardo Ferro ha denominado como “safe small steps”: la habilidad de las personas desarrolladoras de producto de poner en producción pequeñas funcionalidades incrementales de forma segura, con el fin de aprender sobre nuestro producto.
Para cualquier persona que quisiera profundizar más en el detalle de cómo construir producto, recomendaría las siguientes lecturas:
- Entender y profundizar en las prácticas XP, por ejemplo, a través de los libros Extreme Progamming Explained de Kent Beck, o el libro DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations.
- Entender y profundizar en el descubrimiento de producto, a través de la lectura de libros como Inspired, de Marty Cagan, o Continuous Discovery Habits, de Teresa Torres.
Creo que tener actitudes y valores relacionados con la humildad, el aprendizaje y desaprendizaje, la colaboración, la curiosidad (y ganas de meterse en líos), el deseo de resolver problemas reales, la persistencia, la búsqueda de soluciones a través de diferentes puntos de vista (para lo cual la diversidad es fundamental), y el rigor en el análisis son claves para poder desempeñar nuestro trabajo de una forma que nos llene y satisfaga más en nuestro día a día.
No todas las personas tenemos la capacidad de tener todas esas cualidades simultáneamente, y por eso es indispensable que trabajemos colaborativamente con otras personas que aporten aquello de lo que carecemos.
Jordi, en ese empeño en seguir desarrollándote y explorando otros caminos, has desarrollado diversos pet projects. Cuéntanos algo sobre ellos y cómo los has desarrollado.
En mi caso, desarrollar pet projects es un medio para el aprendizaje, donde puedo realizarlo en un contexto menos restrictivo que el trabajo real. A mi me funciona bien este modo de aprendizaje porque puedo poner en práctica inmediatamente temas que quiero testear y obtener feedback de forma rápida; y además, tengo rachas en las que puedo, y me gusta, aplicar parte de mi tiempo libre a ello.
Aquí me gustaría recalcar que, aunque a mi me funciona, puede que a otras personas no, y si es así, también está bien. Para progresar en el mundo del desarrollo, no es necesario realizar pet projects en tu tiempo libre; hay otras formas de aprender que pueden funcionar mejor en otras personas. Eso me gustaría dejarlo claro. El tiempo libre pertenece a cada persona, y cada una define cómo y dónde lo quiere invertir. Nadie puede ni debe decirnos lo contrario. He visto mucho burnout en las redes sociales que no debemos ignorar.
Cuando desarrollo pet projects, una de las razones es para aprender tecnologías diferentes, pero ésta no es la razón principal en la mayoría de los casos. Generalmente lo hago porque veo una oportunidad para resolver un problema, una necesidad o un nuevo ámbito, y quiero ver rápidamente si lo que tengo en mente aportaría algo. Por eso creo que mis pet projects generalmente están muy relacionados con desarrollo de producto (ver si somos capaces de resolver un problema), negocio (ver si al resolver el problema podemos generar un modelo de negocio viable) y tecnología (ver cómo las herramientas actuales permiten resolver dicho problema de forma eficiente), todo junto.
En este notion tengo recopilados los pet projects de los que más orgulloso estoy, aunque actualmente estoy bastante volcado en Escapes Online.
Con Escapes Online lo que hago es teatralizar sesiones de juego en formato escape room a personas que están en sus casas. Vi la oportunidad en medio del confinamiento y me divierto mucho haciéndolo. Lo hago a grupos de 2 – 6 personas, y así también conozco mucha gente.
La aplicación en sí está desarrollada con front VueJS yhace uso de firebase como backend. Esta aplicación permite mostrar las fotografías que voy encontrando durante mi teatralización, y así, el grupo puede interactuar de forma remota. El uso de Firebase es clave para poder mostrar las fotos y los puzzles en tiempo real. Algunos puzzles son interactivos y son “minijuegos” dentro del escape room.
En mi github se puede ver el código fuente de esa aplicación para los 3 escape rooms que realizo, aunque cuidado con los spoilers. Por ejemplo, https://github.com/heedrox/escape-maldicion-museo.
Lo que más me aporta de esta experiencia es que haya gente dispuesta a pagar por algo que he realizado, y que tras la experiencia, me indiquen que han disfrutado mucho. Eso es lo que quiero decir cuando digo que en mis motivaciones principales “busco aportar impacto relevante”. No tiene por qué ser a millones de personas, me aporta lo mismo que personas a mi alrededor se me acerquen y me digan que han disfrutado mucho con una experiencia creada por mí.
Otros proyectos que nacieron como pet projects de los que también estoy muy orgullo son:
Escape Rooms conversacionales vía Google Assistant, como Ric Escape, Anomalía Dimensional y La Mansión de Los Espíritus.
Karmacracy (en 2012), justo en el boom de las redes sociales y los acortadores, encontramos un modo de recompensar a las personas al compartir contenido, a través de diferentes mecanismos, donde la gamificación jugaba un papel muy importante. Fue una época muy divertida, y de mucho aprendizaje. Aunque yo había emprendido ya con Init, lanzar Karmacracy desde “un garaje”, fue una experiencia que disfruté muchísimo. Llegamos a la decena de miles de usuarios, y diseñamos un modelo de negocio innovador, donde recompensamos a las personas con dinero real por compartir enlaces en sus redes sociales. No conseguimos encontrar el modo de hacerlo escalar, pero lo que sí escaló fue todo lo que aprendí en ese momento. Creo que si en aquel momento hubiéramos tenido los conocimientos que tenemos hoy sobre desarrollar producto (y lo que significa), habría marcado una diferencia.
itortv: poca gente sabe que es el origen de mi nick en twitter. En el boom de la serie LOST, desarrollé un portal y una app móvil para localizar torrents y subtítulos en fuentes confiables, antes de la aparición del streaming. Logré que miles de usuarios se dieran de alta. Lo más curioso es que la realicé principalmente pensando en mis necesidades. Que otra gente se diera de alta “fue un efecto colateral” del que estoy enormemente orgulloso. Tanto que me da pena cambiarme el nick de twitter.
¿Qué consejos darías a alguien que quiere lanzarse a desarrollar un nuevo proyecto?
Cada persona es un mundo diferente, y el motor que mueve a cada una también. Por lo tanto, estos consejos pueden no valer para todo el mundo.
- Crear una visión en torno al nuevo proyecto. Yo soy una persona muy “dirigida por la visión”. Todo nuevo proyecto pasa por una fase de ilusión que, tras los primeros días o semanas, acaba por convertirse en rutina. Ya no disfrutas lo mismo aprovechando esa hora libre que tienes para hacer esta parte que te parece un reto. De repente, el proyecto pasa a ser un poco más aburrido, porque las partes más innovadoras o más desafiantes ya están resueltas; o porque lo has dejado aparcado unos días, y te cuesta volver a él. Para esos momentos, a mi me resulta muy útil volver a recuperar la visión, recordarla y partir de ella. La visión puede ser:
- Imaginarme a un conjunto de personas disfrutando de la experiencia que he desarrollado, diciéndome “lo bien que lo han pasado”.
- Utilizar el proyecto como excusa para aprender de una tecnología.
- Ser capaz de resolver una pregunta que a priori puede parecer ambiciosa y compleja.
- Salud y ser sostenible: Al comenzar un nuevo proyecto, probablemente la ilusión puede generar una ansiedad incontrolable. Quieres invertir todo tu tiempo libre en el proyecto, lo cual incrementa la ansiedad. A mi me ha pasado a menudo centrarme tanto en un nuevo proyecto que he descuidado también las relaciones personales o el deporte. Lo bueno de los pet projects es que siempre están allí. Hay tiempo para todo: para quedar con tu grupo de amistades, hacer deporte, dormir bien y avanzar en ese proyecto que te absorbe.
- Pequeños pasos: Intentar acometer un pet project excesivamente desafiante puede generar frustración y el deseo de tirar la toalla. Intenta dividir el proyecto en pequeños pasos menos desafiantes. Si la tecnología es muy compleja, puedes probar a experimentar con ella en un contexto diferente hasta que te familiarices con ella.
- Si no sabes hacer algo, busca ayuda. Si la tecnología o cualquier otro aspecto sobre el que te basas es demasiado complicado, puedes pedir ayuda de diferentes formas. Hay personas voluntarias que pueden estar deseando ayudarte, o incluso excelentes profesionales que desean sacarse un sobresueldo a través de clases particulares. En mi caso, yo actualmente estoy adentrándome en el mundo del Machine Learning a través de un profesor particular. Había intentado varias veces aproximarme a esa tecnología y no lo conseguía por su curva de aprendizaje pronunciada, hasta que pensé ¿no habrá profesores particulares de Machine Learning? Y así fue. Estoy muy contento con la decisión.
- Obtén feedback cuanto antes: comparte tu proyecto con tus personas cercanas cuanto antes. Si ellas no están convencidas de lo útil que es tu solución, ¿por qué crees que vas a convencer a otras personas que están más lejos de ti? Dales tu producto a estas personas, que lo usen, observa su comportamiento, … Obtén toda la información de ellas tan pronto como puedas. No esperes a tener un producto final. Dales trocitos de tu producto para ver si esos trocitos tienen algo de valor para ellas.
- Compartir, compartir, compartir: construir una comunidad en torno a tu producto es muy complejo. Tu producto debe ser la primera solución que los usuarios piensen tan pronto como tengan una necesidad concreta, y para ello, hay que dar a conocer el producto, lo cual requiere dinero e inversión en publicidad. Hasta entonces, puedes intentar lograr una primera base de early adopters compartiendo información sobre tu proyecto desde el comienzo. Yo lo he probado por ejemplo, dando sesiones de live coding en twitch, o generando una comunidad a través de una newsletter.
- Si se ha acabado, se ha acabado. Un pet project no termina nunca: acaba encerrado en un cajón. Y eso genera una sensación de culpabilidad contínua: ¿debería abrir ese cajón? ¿debería renovar el dominio? ¿Estoy tirando a la basura todas las horas invertidas en el proyecto? Si esa visión que te generaste al comienzo del proyecto ya no te motiva lo suficiente, es hora de pasar página. No renueves el dominio. No te sientas culpable. Quédate con todo lo aprendido. Lo más probable es que dentro de varios meses, ya no te acuerdes de él.
Por cierto, comprar el dominio es lo último que debes hacer en un pet project. 😎
Y por último, ¿con quién te irías de cañas para hablar de tecnología y de la vida?
Me encanta hablar de tecnología y de la vida con personas con las que he compartido y comparto pasión por nuestro trabajo, y con quienes disfruto mucho de su compañía. Y más si es con una caña de por medio. Quiero mencionar no sólo a la gente del equipo en el que estoy en LIFULL Connect sino también a Xabi Saez de Ocariz, Fran Mosteiro, Marta Manso, Aitor Alzola, Luis Artola, Alex Epelde, Gorka Etxebarria, Jordi Gómez…
Y me encantaría también con gente que he conocido gracias a las redes sociales,a los pet projects y a los eventos: Diana Hernández, Diana Aceves, Ari, Jorge Baumann, a todas las personas que he conocido en eventos agile / crafters / de producto, y las del discord brillitech.
