Para el especialista en startups en etapa temprana el PM debe ser un articulador de stakeholders, que mejore el funcionamiento colectivo, sin la potestad de exigir de manera burocrática.
Nacido en Colombia, viviendo hace más de dos años en México, Santiago es un todoterreno de las Startups. Se desempeñó como Project Manager, analista de datos, líder de adquisición, líder de retención, líder de operaciones y Business Architect. Empezó en Rappi, la reconocida empresa de delivery colombiana; luego estuvo en Frubana, una startup enfocada en proveer alimentos, frutas y verduras a restaurantes sin intermediarios; su último paso fue por Mundi, la primera plataforma de servicios financieros para exportadores y agentes de carga. Ahora enfrenta un nuevo reto liderando tech y producto en una startup que viene a revolucionar la industria de Manufacturing & Supply Chain en Latinoamérica.
Habiendo estudiado Administración de Empresas, ¿cuál fue el punto de inflexión que vinculó tu carrera con la tecnología?
Siempre me ha gustado la tecnología. En el colegio hackeaba los iPods y las primeras ediciones de I-Phones para poder descargar todas las cosas de pago gratis. Luego aprendí algunos lenguajes de programación. Si bien en la universidad entré a estudiar business, lo que me impulsó a meterme en este mundo fue Rappi, que terminó siendo mi primer trabajo después de la universidad.
La primera versión de Rappi la lanzaron en mi universidad en el 2015. Era una aplicación en la que tu entrabas y había un espacio en blanco donde escribías que querías, a donde querías que te lo llevaran y eso se hacía realidad. La universidad era como una montaña, entonces bajar a una papelería era un trabajo duro. Para mí eso era magia, te llevaban lo que querías a la cima de la montaña. Ahorrabas tiempo y esfuerzo por menos de un dólar. Ahí empecé a entender el potencial que tiene la tecnología. Ahí fue que decidí que quería trabajar con una empresa de tanto impacto en las personas.
Me gustaría detenerme un poquito en tus últimos roles como Business Architecht & Product Manager en la Fintech Mundi. Estuviste desde Febrero de 2021 hasta el mes pasado. ¿Cuáles eran tus principales tareas en estos roles?
Cuando se acabó el proyecto de Tucán (Frubana), me fui pensando que quería hacer producto. Me gusta la tecnología, el código y trabajar con ingenieros. En esa búsqueda conocí a Mundi, que en ese momento tenía una PM y todavía no había un equipo de producto. Por eso mi primera tarea fue empezar a automatizar las operaciones core del negocio con herramientas no-code. Es un tema que me fascina y que estoy seguro es el presente y futuro para las Early-Stage Companies y que cada vez ofrece más escala. Bubble en esto por ejemplo es una locura. Con no-code empezamos a automatizar muchos procesos sin botar una sola línea de código con el objetivo de ver qué funcionaba y que no. Son herramientas sumamente flexibles que permiten modificar cosas en producción sin botar tiempo o recursos de un equipo de ingeniería. Luego, cuando sabemos que funciona, construirlo con tecnología propia, y recursos propios es mucho más efectivo. Hay que lanzar las versiones 1.0 siempre lo más rápido posible. Si no te sientes avergonzado de la versión 1.0 de tu producto, lanzaste tarde. Así fue que empecé medio haciendo producto, medio haciendo operaciones y medio haciendo análisis de datos. Era hacer producto en una menor escala, pero era lo mismo: entender quién es tu usuario interno y entender qué le va a funcionar, qué no, montar un prototipo, testearlo, ver si funciona, lanzarlo con tus usuarios e iterar. Luego Mundi fue creciendo y se estableció un equipo de producto formal.
Y te pasaste a ese equipo.
Exacto. Me gustaba lo que hacía pero sentía que no tenía tanto impacto a largo plazo porque todo lo que montaba de 0 llegaba a un punto en que ya no escalaba más y lo tomaban PMs. Yo lo llevaba de 0 a 1, y ellos de 1 a un millón, porque ya tenían recursos de ingeniería y diseño. Yo quería pasar por la experiencia de llevar un producto a un millón, ya que ya sabía cómo montar muy buenos mvps y probar primeras hipótesis, pero estos solo funcionaban hasta cierto punto y en ese punto me tocaba abandonarlos y entregarlos al equipo de producto. Quería un proyecto end-to-end donde pudiese montar con lo que yo sé hacer los primeros pinos, y después escalarlo con recursos de ingeniería. Ahí decidí moverme al equipo de producto. Entré como product manager de logística, en donde orgullosamente puedo decir que lanzamos la primera solución de cargo insurance 100% digital en Latinoamérica.
Claro. ¿Cuáles fueron los desafíos que encontraste en el nuevo rol?
Personalmente, en producto las dos complicaciones más grandes son Team Building e identificación de riesgos; es decir un buen discovery. Uno no tiene que ser la persona más técnica para ser un buen PM. Lo que sí se necesita sí o sí son buenos soft skills. Por el lado de Team Building el reto de un buen PM es tener un equipo de desarrolladores, un equipo de diseñadores, un Scrum Master, y una serie de stakeholders externos 100% alineados, motivados, que dejen todo en la cancha, sin estar haciendo micro management y principalmente sin ser el jefe de nadie. Debes ser un articulador de stakeholders que hacen que todo el mundo funcione como un reloj, sin poderte imponer ni exigirle a ninguna persona de manera burocrática.
Por el lado de identificación de riesgos, debes tener muy clara la estrategia de producto, en especial en Early-Stages. No se deben celebrar el lanzamiento de features, sino el movimiento de métricas. Y las métricas son outputs alimentados por inputs. Saber identificar los riesgos y las formas de mover esos inputs son habilidades que parecen obvias, pero que no son nada fáciles. Marty Cagan lo dice en lo que para mí es la biblia de producto (Inspired).
“Hay que saber identificar riesgos de valor, usabilidad, viabilidad y viabilidad de negocio, antes de construir cualquier cosa”.
Marty Cagan. Fundador del Silicon Valley Product Group.
¿Cuáles son por ahora los criterios más importantes al momento de priorizar el backlog y poder lidiar con las presiones de los distintos stakeholders que mencionabas?
Esto depende demasiado de cada empresa y situación. Es muy importante tener muy buena relación con stakeholders y con la gente con la que estás trabajando, pero esto no significa hacer todo lo que a uno le piden. Esto aplica para clientes externos y clientes internos. Por ejemplo, si uno es PM de un área de riesgo es importante sentarnos con ellos y hacer una herramienta que les funcione. Pero esto no significa desarrollar lo que pidan sino sentarse y ser ese guía que los ayude a identificar que es realmente lo que necesitan y luego desarrollar una respuesta. Ahora, si es un producto externo para el cliente de la empresa yo priorizó la parte cuantitativa, los números. Eso para mí es más valioso que hablar con 100 clientes. Yo creo que la gente no sabe lo que quiere sino que sus acciones demuestran lo que quieren.
“Lo que la gente quiere es lo que la gente hace y eso se ve realmente en los métricas”.
Santiago Perico
¿Hay diferencias entre B2C y B2B?
Si. En B2C es mucho más fácil ver lo que los clientes hacen y con data poder descubrir qué es lo que quieren. En B2B es mucho más cualitativo, ahí es más importante sentarse a hablar con los clientes. En mi experiencia B2C es 90% números y 10% cuali para entender mejor esos números. B2B es más bien al revés: 80% cuali, 20% data, porque no tienes muchos datos. Esto puede tener muchas variables y matices porque hay b2bs con tickets muy pequeños pero gran cantidad de operaciones (como Frubana), en donde hay muchos datos, pero diría que para simplificar me enfocaría más en la parte cuanti en B2C y en la cuali en B2B.
Y ahora empiezas un nuevo proyecto en Masu ¿Qué ves por delante?
La industria manufacturera en Latam necesita renovarse. Los modelos antiguos de compra de materias primas están desperdiciando una oportunidad de mercado importante. Se viene una época interesante para Latinoamérica teniendo en cuenta temas como el nearshoring en México y la evolución de las cadenas de suministro de los grandes jugadores. No es claro el panorama para seguir operando con un modelo 1PL.
Así mismo hay un reto importante en los manejos de inventarios para marketplaces. Si bien no vamos a trabajar con perecederos necesitamos tener un modelo de cálculo de demanda muy afinado. Poder tener el mínimo de productos en stock, una rotación sana y una logística poco costosa es parte fundamental de la operación que estamos planeando.
Por otro lado, hay un gran reto en el acceso a Supply para poder aumentar oferta y equilibrar precios. Actualmente hay muchas empresas locales que no están pudiendo acceder al producto, o si lo hacen es a precios muy elevados. Esto se debe al crecimiento de la demanda en la región pero también a la ineficiencia de las empresas que los venden. Masu viene a ser un puente entre estos jugadores y a generar externalidades positivas a las dos partes, Supply and Demand.
