Entrevistamos a Javier Boo, CTO de Aiwin, una empresa que está rediseñando la forma en la que se interactúa con la empresa combinando arte, juego y tecnología.

Con Javier tratamos algunos aspectos del Producto Digital desde la perspectiva más técnica.

Entrevista a Javier Boo de Aiwin

Cuéntanos sobre tu experiencia laboral

Mi experiencia laboral empezó allá por el 2007, en el mundo de los ERPs y portales de RRHH. La verdad es que es una época de la que no guardo muy buen recuerdo a nivel profesional -no así a nivel personal- ya que en dicho mundo se coarta mucho la creatividad técnica de un desarrollador. Finalmente, conseguí desprenderme de ese mundo y empezar a realizar proyectos de desarrollo web a medida. A la vez, aprendí a gestionar el ciclo de vida de desarrollo de éstos proyectos, inicialmente con una metodología tradicional waterfalll (PMP style) y posteriormente mediante metodologías ágiles, tipo SCRUM / kanban. Posteriormente, dejé de estar en el desarrollo de los proyectos para formar parte del departamento de arquitectura técnica de uno de los principales bancos de nuestro país, donde aprendí a pensar de forma más genérica y abstracta de forma que las soluciones que proponía fuesen cross-project.

A día de hoy, soy el CTO y el responsable de desarrollo de producto de Aiwin, una empresa dedicada a la gamificación que combina arte, juego y tecnología para proporcionar soluciones de alto impacto emocional a sus clientes.

Como CTO me encargo de seleccionar la tecnología para nuestros productos, así como los perfiles técnicos necesarios para el desarrollo de los productos. Además soy el responsable de impulsar la estrategia a nivel tecnológica de la empresa, tanto en el desarrollo del producto como en otras áreas de la empresa como operaciones o comercial.

Como responsable de producto, me encargo de trazar el roadmap de cada uno de nuestros productos, definiendo las funcionalidades y prioridades de cada uno de ellos, y recogiendo feedback de nuestros usuarios para implementar un circuito de mejora continua de nuestros productos.

¿Cómo fue tu primera toma de contacto con un producto digital?

Mi primera experiencia en la construcción de un producto digital fue el desarrollo de una plataforma de gamificación para el sector bancario cuyo objetivo principal era incentivar el uso de los canales digitales para realizar la operativa diaria y fomentar la contratación de productos en el cliente retail desde la web del banco.

Anteriormente, había participado en otros proyectos de creación de productos digitales pero una vez que el producto veía la luz el proyecto terminaba y ya no participaba más en el ciclo de vida del mismo.

Pero en este caso fue la primera vez en la que participé en todas las fases del ciclo de vida de un producto: la construcción y su posterior introducción en el mercado, el crecimiento (llegó a tener más de 250K usuarios activos), la madurez (pivotando para sacar el máximo rendimiento a los patrocinios del banco) y el declive (afortunadamente, de esta última etapa solo viví el principio).

¿Qué es para ti un producto digital?

Buscando en la hemeroteca nos podemos encontrar muchas definiciones de producto: algo que ha sido fabricado o producido, el resultado de un trabajo u operación, todo aquello que puede ser utilizado con un fin específico, … Pero a mí personalmente, la versión que más me gusta es la que se establece desde el punto de vista de marketing: elementos fabricados para satisfacer/crear una necesidad en el cliente o atender un deseo a través de su uso o consumo. Y es que creo que aquí es donde radica el éxito de un producto: en la capacidad del mismo de cubrir las demandas de los clientes.

Además el componente digital indica que el producto sólo puede utilizarse o consumirse a través de medios digitales, como por ejemplo, internet, plataformas de televisión digital, etc.

¿Cuál es el principal error que cometen las empresas a la hora de diseñar un producto digital?

Creo que el principal error es no tener en cuenta el cliente al que va destinado durante la creación, invertir mucho tiempo en la creación del producto sin saber si nuestro cliente va a utilizarlo, y una vez se ha introducido en el mercado no saber pivotar hacia ese nuevo producto que es el que realmente quiere el cliente. En definitiva, creo que es necesario tener un enfoque más lean, lanzando MVPs con mayor frecuencia y evaluando su acogida en el cliente.

¿Que crees que se necesitaría en España para que se convirtiera en un referente internacional en creación de producto digital?

Seguro que hacen falta muchas cosas, como incentivos fiscales al emprendimiento, espacios públicos de co-creación y co-working, fomentar la creación de proyectos personales desde las propias empresas, … pero creo que muchas veces lo que nos falta es creérnoslo más.

Tenemos la tendencia a pensar que cualquier producto de fuera es mejor y no es verdad. En España hay mucho talento y gente muy preparada que en muchas ocasiones solo necesita es pequeño empujón para dar el salto a crear ese producto que tiene en mente, que lleva tiempo dándole vueltas pero por falta de confianza no se atreve a realizar.

Product Hackers Awards Candidaturas

¿En qué aspectos os fijáis a la hora de decidir un stack tecnológico sobre el que desarrollar un producto concreto?

En nuestro caso, dado que somos una empresa pequeña y no tenemos recursos ilimitados, nos decantamos por aquellas tecnologías que se ofrecen en formato SaaS que son gestionadas por terceros y que se ofrecen en una modalidad de pago por uso.

Por ejemplo, para el caso de recursos de computación utilizamos tecnologías serverless que no requieren tener una infraestructura levantada 24x7. Esto nos permite ahorrar costes tanto de computación como de mantenimiento.

En el caso de recursos de almacenamiento, mantenemos la misma filosofía: utilizamos bases de datos gestionadas en vez de bases de datos que requieran infraestructura ad-hoc. El pago de estos recursos de almacenamiento se realiza, principalmente, en función de la cantidad de información almacenada.

Además de cómo se ofrecen estas tecnologías, nos fijamos principalmente en que la tecnología sea adecuada para el caso de uso que queremos implementar.

Hoy en día, con el abanico tan grande de tecnologías sumado a la modalidad de pago por uso ya no vale eso de utilizar las mismas tecnologías para todos los componentes del producto sino que cada componente puede estar desarrollado utilizando un stack completamente diferente al de otro componente del mismo producto.

¿Cómo conseguís balancear el uso de tecnologías más modernas y que puedan atraer más talento técnico con la deuda técnica que va adquiriendo el producto?

Según lo indicado anteriormente, cada componente del producto tiene o puede tener un stack independiente y adecuado a sus necesidades de negocio.

Además dado que estos componentes no están fuertemente acoplados a los demás sino que están integrados a través del uso de una API pública entre ellos, el ciclo del desarrollo de cada uno de estos componentes del producto puede ser completamente independiente.

Esto permite que los componentes que se vayan quedando desfasados tecnológicamente se puedan ir reemplazando utilizando stacks más modernos sin afectar al resto de componentes del producto.

En vuestro caso, ¿tenéis equipos separados de desarrollo de producto y de soporte o se cubren ambos aspectos desde el mismo equipo?

Tenemos un equipo de operaciones y un equipo de producto.

El equipo de operaciones se encarga de personalizar y parametrizar los productos para cada uno de nuestros clientes, además de ofrecer soporte de primer nivel al usuario.

El equipo de producto se encarga del mantenimiento correctivo y evolutivo de los productos así como de la creación de nuevos productos que pone a disposición del equipo de operaciones y del equipo comercial.

El desarrollo del producto se realiza en base, por un lado, al feedback proporcionado por los clientes vía operaciones o comercial y, por otro lado, al roadmap definido por el responsable de producto sobre cada uno de los productos de la compañía.

¿Cuáles son los principales stoppers que os encontráis en el día a día en cuanto al desarrollo de producto y cómo los solucionáis?

El principal impedimento es que las prioridades marcadas por las necesidades de los proyectos siempre suelen superar a las prioridades marcadas por el roadmap del producto. Esto hace que siempre quede en un segundo plano el desarrollo del producto y se dedique tiempo principalmente a requerimientos concretos de clientes.

Para solucionar esto tomamos la decisión de separar los equipos en operaciones y producto (anteriormente era un solo equipo que hacía las dos cosas) pero aún así hemos observado que es difícil mantener un ritmo de evolución constante en los productos debido a que hay que atender las incidencias que surgen en la ejecución de los proyectos de personalización de nuestros productos.

Para minimizar en la medida de lo posible el impacto que esto supone estamos implantando un sistema priorización de tareas que permita priorizarlas en base a un criterio objetivo y conocido por todos en la compañía (vamos a utilizar la métrica WSJF) y que la prioridad no dependa exclusivamente de la presión que puedan ejercer los clientes sobre el equipo comercial y/o operaciones.

Para los que estén leyendo esta entrevista, ¿por qué crees que deberían participar en los Product Hackers Awards si tienen algún producto digital?

Hay motivos muy obvios por los que participar en estos premios, como por ejemplo, ver tu producto compitiendo con otros grandes productos y/o empresas o el premio económico en caso de resultar vencedor.

Pero creo que el principal motivo por el que animo a participar es porque el hecho de participar en un concurso de este tipo, o mejor, el hecho de enseñar tu producto a terceros ya sea en un concurso, en una ronda de financiación, etc. hace que tengas en cuenta ciertos detalles o que inviertas tiempo en solucionar ciertas carencias que de no ser, en este caso, por la participación en el concurso nunca se habrían tenido en cuenta.

Por ejemplo, la típica tarea repetitiva que debes hacer siempre y que no aporta ningún valor, pero como en su momento era más importante invertir el tiempo en otras cosas se ha quedado así de por vida.

Product Hackers Awards Candidaturas