ver todos los episodios

59

no escuches a tus usuarios (todo el tiempo)

Elenas - Andrés Palacio

Andrés Palacio Elenas No escuches a tus usuarios (todo el tiempo)

Producto

En este capítulo platicamos con Andrés Palacio, VP de Producto en Elenas, la startup latinoamericana de comercio social. Charlamos sobre cultura, nuevas contrataciones, cuando priorizar funcionalidades grandes sobre pequeños detalles y cuando sí y cuando no escuchar a tus usuarios.

Comparte

Transcript

Artemio: ¿Qué tal? Bienvenidos a todos a una edición más de Cuando El Río Suena, el podcast en el que invitamos a expertos y profesionales del mundo de la tecnología y la innovación para que compartan con nosotros sus mejores insights y consejos para construir negocios saludables de internet. Es un placer saludar a todas las personas que están escuchando, el día de hoy me acompaña mi socio Rodrigo Salmerón, ¿cómo estás, Ro?

Rodrigo: ¿Qué tal? Muy bien.

Artemio: Como ya es costumbre. Y nuestro invitado de esta ocasión, Andrés Palacio, que viene de Elenas. ¿Cómo estás, Andrés?

Andrés: Hola, Rodrigo, Artemio, muy bien, muchas gracias.

Artemio: ¿Desde dónde te estás contactando?

Andrés: Me conecto desde Cali, Colombia, yo soy de aquí pero no vivo aquí. Estoy en estos días en Cali, yo vivo en Medellín.

Artemio: Visitando casa, fantástico. Nada como la calidez de casa.

¿Cuál es el pitch de elevador de Elenas?

Artemio: Les cuento un poquito de Andrés, él es VP de Producto en Elenas, que es una empresa súper emocionante. Ahorita vamos a sumergirnos un poquito más en qué es lo que hacen pero, precisamente para poner a todos en la misma página, Andrés, ¿podrías contarnos cuál es el pitch de elevador de Elenas?

Andrés: Claro que sí. Elenas es una plataforma de social commerce y venta directa que le da a las mujeres de Colombia y México la oportunidad de generar ingresos vendiendo productos sin invertir su dinero; no tienen que preocuparse por procesos de despacho, envío o recaudo de dinero. Básicamente, nosotros nos encargamos de todo el proceso y ellas lo que hacen es ofrecer los productos, cerrar las ventas, y se ganan una comisión en ese proceso sin tener que poner inversión de su parte.

Artemio: Es la evolución natural de la venta por catálogo llevado en línea, así es como yo veo el servicio de Elenas.

Andrés: Completamente. Yo siempre digo que es un problema muy latinoamericano. Yo personalmente lo he experimentado, en mi familia, mi mamá hizo venta por catálogo cuando yo era niño, entonces es un tema que siento muy directamente. Y creo que sí, es una renovación en muchos niveles, en términos de la tecnología que se puede aplicar, pero también en términos del modelo mismo y cómo realmente una mujer, independientemente de sus conocimientos o de sus recursos, puede emprender y empezar a generar ingresos sin necesidad de entrar en mayores procesos.

Rodrigo: Está fantástica la iniciativa.

¿Qué hace todos los días Andrés Palacios, VP de Producto en Elenas?

Rodrigo: Andrés, tú particularmente como VP de Producto, ¿de qué se trata tu labor? ¿Cómo se ve un día normal?

Andrés: Yo creo que mi labor viene a ser algo así como ecualizar. Yo tengo varios equipos directos, son squads de producto, tecnología y data, realmente considero que son squads interdisciplinarios porque incluyen también participación de todas las áreas del negocio, y mi trabajo un poco es ecualizar las ideas, las iniciativas. En el día a día pasan muchas cosas, surgen muchas ideas, surgen muchos problemas, muchas hipótesis, y tiene que haber este espacio para que realmente reflexionemos acerca de qué de todo ese conjunto de ideas e iniciativas es lo que tenemos que apostar en este momento según nuestros objetivos, según nuestra visión, y eso es un poco mi día a día, es estar hablando constantemente con estos equipos y tratando de darle orden a lo que está pasando en el día a día para que nos mantengamos súper priorizados.

Artemio: Gracias por ese vistazo a tu día a día. Realmente creo que es muy similar al día a día que tienen todos estos líderes de producto donde realmente la tarea de priorizar tanto feedback como ideas y nuevas oportunidades, se vuelve un tema porque empiezan a ser tantas que hay que administrar y, como tú dices, ecualizar por dónde sí y por dónde no, cuál es el siguiente paso que nos va a permitir acercarnos más hacia el norte que vamos.

¿Con qué recurrencia habla Elenas con sus usuarios para recabar feedback?

Artemio: Andrés, queríamos preguntarles, ¿ustedes con qué recurrencia hablan con sus usuarios para recabar feedback? Sabemos que esto es muy importante y también sabemos que hay dos cosas de las que nunca se cansan las startups: de construir código y de hablar con sus usuarios.

Andrés: Yo creo que no hay nada mejor en este mundo de las startups que esa empatía. Yo creo que es súper común ver hoy en día que los grandes líderes en startups hablan de eso todo el tiempo y tiene todo el sentido porque creo que es uno de los aprendizajes más grandes que se ha tenido recientemente con respecto a la forma como de pronto las empresas más tradicionales manejaban las cosas. Definitivamente Elenas no se casa de eso, nuestro founder es Zach Oschin.

Artemio: Paréntesis, ¿qué edad tiene su CEO?

Andrés: Tiene 24 años.

Artemio: Teníamos que sacar este dato aquí. Vimos en The Generalist un artículo completo de Elenas y te das cuenta que el CEO es un niño prodigio entonces había que ponerlo sobre la mesa.

Andrés: Completamente. Créeme que, constantemente, se lo digo a Zach y hablamos de este tema de su experiencia. Es increíble porque es una persona de la que aprendo mucho, es mi manager directamente y todos los días estoy aprendiendo de él y bueno, entre otras cosas, hablando del contexto de las startups, eso también pasa hoy en día, en las empresas tradicionales, muy culturalmente, casi por rangos de la compañía tú podías predecir la edad de una persona, y yo creo que en las startups eso pasó a un segundo plano, es completamente irrelevante la edad de una persona e inclusive la experiencia misma de una persona es irrelevante. Realmente hay temas de cultura y de ganas que pasan por encima de todo esto.

Volviendo al tema, hablando de Zach, él ha sido completamente un advocate de este sentido. Nosotros tenemos procesos de contratación en los que incluimos procesos de hablar con usuarios en frío. Es “toma estos usuarios de esta base y llámalos, preséntate como Elenas y escúchalos”, y es algo muy bonito. Yo lo hice cuando presenté mi proceso hace un año y te enseña mucho. Lo mantenemos independientemente de nuestra escala, te puedo decir con toda seguridad que todos los días nos llega feedback cualitativo de un usuario como mínimo. Y no estoy hablando de herramientas, estoy hablando de feedback porque alguien nos escribió a WhatsApp, o porque alguien de mi equipo está haciendo un proceso de research y está llamando a embajadoras y preguntándoles. Y lo hacemos constantemente. Estamos en este momento en un proceso de research, todo el tiempo estamos en un proceso de research con respecto a algo, entonces todos los días estamos hablando con usuarios. Algo que hemos tenido que balancear muchísimo es con qué usuarios hablamos porque es muy común en este tipo de cosas el survival bias. Cuando tú estás haciendo product-market fit, tú arrancas hablando con un grupo de usuarios y esos usuarios se vuelven tan poderosos en tu feedback loop que, de pronto, terminas hablando siempre con las mismas personas y algo que hemos tenido que balancear muchísimo es que entendemos que eso es importantísimo cuando estás comenzando pero, cuando ya tienes una base de decenas de miles de personas interactuando con tu producto, tienes que tratar de mitigar ese survival bias, tienes que hablar con las personas que no van a querer hablar necesariamente, tienes que ir a buscar a las personas con las que nunca has hablado para realmente tener todos los puntos de vista.

Rodrigo: Claro porque es verdad que durante el primer proceso de validación no puedes estar cambiando de sujetos todo el tiempo porque, si no, nunca llegas a ningún lado, no terminas de concretar ninguna idea, pero esto tiene que cambiar en el momento en el que escala a mucha más gente usando tu producto.

Artemio: Además tratándose de un tema que puede ser tan masivo en Latinoamérica, como esta evolución natural de la venta por catálogo, el background de la persona o usuaria en cuestión es súper diverso. Puede cambiar todo el contexto hasta sólo por la colonia.

Andrés: Completamente. De hecho, México es un gran ejemplo de eso. Cuando lanzamos México el año pasado, fue un proceso cualitativo como si estuviéramos arrancando de cero. Y, en ese proceso, se buscaron personas que estuvieran interesadas pero también que tuvieran esa diversidad, no sólo en Ciudad de México sino que realmente fuimos por la mayor cantidad de diversidad posible para entender qué es lo que está pasando en este país que estamos tratando de abrir y fue un completo éxito nuestro proceso de lanzamiento en México. Esa cercanía con los usuarios y no simplemente asumir que todo iba a funcionar tal cual.

¿Qué elementos de la cultura de Elenas pueden aprender otras startups?

Rodrigo: También te queríamos preguntar, ahorita ya nos diste un vistazo sobre cultura en esta dinámica de onboarding de hablar con los usuarios, nos parece que está fantástico, pero ¿qué más de la cultura de Elenas podrían aprender otras startups de allá afuera?

Andrés: Yo creo que, culturalmente, y tal vez vaya a uno de los temas que ya tocamos pero es importantísimo, es que nosotros balanceamos mucho los números con esta parte cualitativa, estamos constantemente en ese loop. Un proceso puede iniciar cualitativamente porque nosotros escuchamos algo de un grupo de usuarios o de un usuario en específico pero, naturalmente, el siguiente paso tiene que ser ponerle data a eso, tratar de cuantificar lo que sea que escuchamos. Lo mismo pasa al revés, cuando un insight surge de un análisis cuantitativo que surge en algún equipo, nosotros los primero que hacemos es ir a hablar con personas acerca de eso. Entonces estamos todo el tiempo balanceando porque es natural que muchas personas en el proceso de escalamiento la data se convierta en su mejor amigo, y para nosotros también lo es, la data es lo más importante que tenemos y estamos todo el tiempo midiendo. Pero la data te puede cegar porque la data te muestra una foto de outcome y, por más que tú trates de encontrar unas métricas como leading y no lagging, siempre las métricas de cierta manera van a ser lagging porque son el resultado de un proceso, mientras que este análisis cualitativo te da mucho detalle sobre qué está pasando detrás de ese número que estás viendo. Entonces, detrás de un número de retención que puede moverse un punto o dos entre un mes y otro, pueden estar pasando muchas cosas cualitativamente hablando.

Yo creo que eso es parte de nuestra cultura innata. Cuando tú ves que alguien presenta algo cualitativo y no tiene data, lo primero que vamos a hacer es preguntar dónde está la data. También cuando alguien presenta data y lo analiza, preguntamos qué vamos a hacer, cómo vamos a explorar esa oportunidad. Es algo que es firme en nuestra cultura.

Artemio: Que, muchas veces, cuando se trata de data, se trata de hacerte las preguntas correctas respecto a la data que tienes frente a ti. Antes de la entrevista que estamos teniendo contigo platicamos con Christian Peña, de Lemus, es un geek de Big Data, es una empresa que trabaja con Big Data, ellos están escaneando con satélites todo el tiempo el estado del mundo, procesando todos estos datos y haciendo un Atlas del mundo, esta es la visión que ellos tienen pero en línea, y al momento de pedirle sus mejores recomendaciones para gente que está trabajando en el área de Big Data o los errores más comunes, nos dijo precisamente eso, no hacerte la pregunta indicada o hacerte una pregunta que tiene un sesgo y ya esperando cierto outcome, y eso completamente ciega la información y muchas veces la hace no inservible pero sí sesgada y tú ya estás esperando un outcome en particular.

Andrés: Completamente. Uno muchas veces se encuentra lo que iba buscando y por eso es súper importante que, cuando se plantean esas preguntas, se planteen sobre las bases correctas. En mi equipo somos muy dados a darnos feedback con respecto a lo que escribimos. Utilizamos mucho la escritura como una forma de trabajar dentro del equipo de Producto y yo con el equipo hablo mucho acerca de cómo escribimos las cosas de tal manera que se entienda cuál es el nivel de madurez de eso, si es sólo una hipótesis, si es sólo una idea, si es una hipótesis validada. Es súper importante que quede muy claro cuando tú estás escribiendo algo que cuando tú digas “el resultado de lo que hicimos fue X”, darle contexto a X, “¿qué es X? X es que hiciste un experimento con un porcentaje de personas en este contexto y que, como resultado, viste esto y eso es una correlación más no una causa”, te puedes demorar un poquito diciéndolo pero es importante porque, si no, una persona que no tenga el contexto puede simplemente asumir que tú ya hiciste un movimiento de métrica según lo que dijiste y, al momento de ir al dato, realmente no está.

Entonces yo creo que es súper importante con nuestros Data Scientists, nosotros tenemos estas sesiones en las que tratamos de alinearnos muy bien en eso. Hay diferentes fases, yo creo que a veces hay proyectos que avanzan en fases muy explorativas y realmente todos hacemos el ejercicio, por ejemplo, “hagamos una matriz de correlación entre diferentes eventos. No sabemos cómo se relacionan esos eventos. Hagamos una matriz y vemos en un mapa cómo se relaciona el costo de envío con la frecuencia de órdenes a la semana”, y, si encontramos unos coeficientes de correlación interesantes, ahí ya sabemos qué pregunta hacer. Si vemos un coeficiente de correlación superior al 0.5 entre esas dos señales, tú dices “listo, me voy a hacer una validación de una hipótesis que es que cuando tenemos costos de envío más bajos aumenta la cantidad de órdenes que se montan a la semana”, eso es una pregunta súper específica que te puede ayudar a validar el data science, pero es un trabajo muy colaborativo realmente.

Artemio: Qué buen ejemplo.

¿Cuáles son las responsabilidades más importantes de un Product Manager?

Rodrigo: En otra dirección, parte de lo que hacemos en este podcast es contextualizar, orientar a muchas personas que están involucradas en el mundo de las startups en Latinoamérica. ¿Cuál es tu visión en las responsabilidades más importantes de un Product Manager? Puede ser desde un Product Manager de puesto más bajo, que tiene a pocas personas en su equipo hasta los puestos más altos. ¿Cuáles dirías tú que son las responsabilidades más importantes que tiene alguien así?

Andrés: Siempre que haya un Product Manager en una sala de reuniones, virtual o presencial, su labor debe ser devolver todo al problema. Si nos sentamos en una sala y estamos discutiendo una idea y no hemos discutido el problema, la responsabilidad del Product Manager es que se discuta el problema, es devolver todo al estado en el que entendemos el por qué. Si un Product Manager arranca a dar valor desde el qué estamos haciendo o el cómo lo estamos haciendo, de entrada estás fallando en su responsabilidad principal, que es el por qué lo estamos haciendo. Y es muy común que, en ocasiones, ya sea por tu humor o por falta de contexto, haya situaciones en las que se esté hablando de un tema específico y ya se esté hablando acerca de cómo se va a solucionar algo en una interfaz gráfica y, si tú sigues esa conversación sin nunca haber entendido por qué razón lo estás haciendo, te va a costar muchísimo tomar decisiones y sentir que eres accountable por los resultados. ¿Cómo tú presentas resultados de una iniciativa si nunca entendiste por qué lo estábamos haciendo? Es completamente imposible. Y, para mí, esta pregunta siempre un Product Manager la debe responder y es su responsabilidad principal, desde luego no es la única, hay responsabilidades que tienen que ver con la mediación entre diseño y tech, entre tech y los stakeholders, la mediación entre data y diseño; hay muchas actitudes alrededor de cómo negocias y cómo priorizas. Todo eso es lo que está escrito en todos lados sobre cómo funciona el rol del Product Manager, pero para mí, la principal, y la que hace que este resto de cosas funcionen o no es que un Product Manager sepa responder por qué se está haciendo algo. Si no lo sabe hacer, está fallando en su responsabilidad principal.

Artemio: Está fantástico ser el guardián del por qué cada decisión se toma respecto al producto, interfaz o experiencia que están teniendo los usuarios, y creo que tienes razón en esta parte en la que luego es muy fácil por un dato o por una idea que viene del estómago dar un paso pero sin detenerse a responder el por qué. Y el tener este respaldo en alguien que es como el guardián, pero no guardián en sentido de “aléjense, esto se hace así”, sino desde un estado más de consciencia respecto a los pasos que estás dando lógicamente.

¿Qué hace especial a la experiencia de usuario de Elenas?

Artemio: Andrés, otra pregunta que tengo muchas ganas de hacer es ¿qué hace especial la experiencia de usuario de Elenas?

Andrés: Yo creo que, naturalmente, debido a ese contacto que tienen los usuarios, la experiencia es bastante empática y esto es una respuesta muy out of the box frente al diseño de experiencia, pero es así. Yo creo que es una experiencia empática, es una experiencia que todo el tiempo nos estamos cuestionando si es lo correcto para estas personas, si es lo correcto para este momento de la experiencia, y tenemos unos principios que el equipo de Product Design sigue y nos alineamos mucho en eso, pero yo creo que hay un aspecto de nuestra experiencia que es realmente único si lo vemos en el contexto contra otras aplicaciones o competidores indirectos grandes de ecommerce, y es que nosotros estamos en un momento donde podemos darnos el lujo de iterar un poco más grande. Nosotros no somos, como equipo de producto, fans de optimizar sobre detalles pequeños y yo se lo digo muchas veces al equipo de Product Design, yo sé que hay muchas cosas que mejorar en la experiencia de usuario, en la interfaz, y está bien, encontraremos el momento para hacerlo, pero yo no quiero gastarme un año iterando sobre cómo abre un cajón o cómo se despliega un elemento. Yo creo que encontramos los momentos para hacerlo, pero realmente cuando tú ves las iteraciones de producto que nosotros hacemos en cada ciclo son iteraciones grandes.

Cuando nosotros anunciamos a las embajadoras que lanzamos una nueva funcionalidad, es una gran funcionalidad, y es algo que, de una vez, o soluciona un problema a raíz o falla. Y, si falla, nosotros tenemos la responsabilidad de decir “falló, iteremos sobre eso”, pero yo creo que nuestras usuarias sienten que nosotros estamos trabajando independientemente de que muchas veces pueda gustarles o no una funcionalidad a unas usuarias específicas, ellas saben que nosotros estamos trabajando en nuestra aplicación y procuramos que así sea. O vamos a solucionar problemas que importan o no estamos haciendo nada, realmente no estamos en una fase en la que debamos estar iterando sobre complacer a los usuarios externos e internos en detalles pequeños, sino que tenemos que probar hipótesis grandes porque ahora es que tenemos el lujo de hacerlo y, después, tal vez no vamos a tener ese lujo.

Artemio: Fantástico. Esto que cuentas me hace imaginarme un poco la experiencia que tienen los usuarios de Elenas, es algo que yo siento mucho con las actualizaciones que manda Notion cada que hacen una actualización de producto, tanto Notion como Figma, creo que son dos empresas que, casi siempre, lo pienso y, a los meses o al medio año, aparece una funcionalidad que ataca eso en particular de lo que un par de gente nos estamos quejando en un foro. Estas dos empresas, ya en una etapa mucho más consolidada, podría decirse, ya empiezan a concentrarse en pequeños detallitos, pero Notion es un software que siempre arroja features y son features que emocionan muchísimo a la comunidad que hay alrededor de ese software porque, genuinamente, sí sientes que están escuchándote y analizando todo el comportamiento de la gente que estamos usando ese software.

Andrés: Completamente. Yo creo que moción es la palabra. De hecho, ahora que lo mencionas, yo recuerdo cuando recibí el último newsletter de product updates de Notion y supe que era algo grande. Nosotros utilizamos una herramienta que se llama ClickUp y es igual, ClickUp cuando itera, itera grande, o te solucionó el problema o falló y te dio más problemas pero no está trabajando en un cambio de interfaz o rediseño, como cuando Facebook cambia un botón y todo el mundo lo comparte, no, ClickUp hace una optimización realmente y es lo que te encuentras en productos que ya están con demasiado momentum, te toca ser más cuidadoso en cuáles son las cosas que iteras.

¿Cuáles son tres formas en las que una startup puede fallar en su producto?

Rodrigo: Andrés, ya nos mencionaste cosas que la gente puede hacer bien con sus productos, hablar con sus usuarios, fijarse en qué funcionalidades son las que se iteran y se prueban y saber por qué, esta priorización, pero ahora ¿nos puedes compartir tres formas en las que una startup puede fallar en su producto?

Andrés: He mencionado algunas cosas que se alinean con eso. Para mí, una sería hacer lo que el usuario quiere. Y esto también es medio cliché en el medio ya para la altura en la que estamos, pero es real. Es que si tú te enfocas en hacer lo que el usuario quiere, primero tienes que estarte preguntando quién es el usuario que estás escuchando y ahí es donde entra lo que hablábamos de survival bias. Tal vez estás escuchando al usuario equivocado y al final haces lo que ese usuario quería pero no lo que otros 99 querían, entonces siempre es muy delicado hacer lo que el usuario quiere y, nuevamente, aquí es donde Producto juega un papel muy importante porque debes devolverte a por qué lo quiere, por qué eso que el usuario quiere es un problema y por qué debes resolverlo. Creo que esa es una forma en la que una startup puede fallar y es hacer las cosas porque hay una comunidad que está pidiéndote y haces lo que la comunidad está pidiendo, pero a la larga descubres que esa comunidad no era el product-market fit que tú creías y terminas fallando.

Otra sería diseñar para la competencia. Este es un tema que yo hablaba con mi equipo también hace no mucho y es que hay muchas empresas que diseñan producto para la competencia, se enfocan en qué es lo que mi competidor no tiene, no hace, cómo ser mejor que mi competidor y terminan diseñando un producto tan en esa línea que los usuarios quedan atrás y los problemas de los usuarios quedan atrás. Yo creo que esa es otra forma en la que se puede fallar.

Por último, que también lo mencioné ya, es utilizar exclusivamente data cuantitativa. Yo creo que, si hay un híper enfoque en la data cuantitativa y no lo equilibras, especialmente si todavía no has encontrado el product-market fit o si estás reciente en ese product-market fit o abriendo un nuevo mercado, puedes fallar seriamente si no le das un vistazo a la parte cualitativa.

Artemio: Ahí lo tienen, un gran top tres de cómo puedes fallar en producto en tu startup.

Rodrigo: Y esta de hacerle caso al usuario es muy interesante porque escuchas todo el tiempo que hay que hacerle caso al usuario, que el usuario siempre tiene que estar al centro. Pero este enfoque de tener cuidado con a quién le estás preguntando yo creo que es especial.

Artemio: Claro, y está esta frase bien famosa de Ford que dice “si yo le hubiera preguntando a la gente qué querían, me hubieran dicho que caballos más rápidos”, igual mucho se puede sacar de ahí.

¿En qué se fija Andrés para asegurarse de que una nueva contratación va a encajar con la cultura de su equipo?

Rodrigo: Andrés, queríamos preguntarte, en un tema de contrataciones, más allá del perfil técnico que, si no se cumple, la gente no puede trabajar porque no tiene las habilidades requeridas, ¿cómo te aseguras de que una nueva contratación va a entrar en tu cultura? ¿En qué te fijas cuando estás armando tus equipos?

Andrés: Yo diría que para nosotros es muy importante la cultura alrededor de la empatía. Hablábamos acerca de este proceso en el que nosotros le pedíamos a las personas que hablaran con usuarios porque queremos saber cuál es esa empatía con usuarios, queremos entender cómo piensan acerca de abordar a los usuarios y es súper importante, pero también, internamente, está este proceso que nosotros hacemos que incluye conversaciones con diferentes miembros del equipo, tanto de la misma disciplina como de otras disciplinas y otras personas del área y, de hecho, tiene una parte que es bastante inmersiva porque es trabajar con otras personas como si fuera tu primer día de trabajo en Elena. Es “cómo haces tú para resolver este problema, aquí tienes a esta persona que es Product Manager, tienes al Product Designer, tienes a la persona de logística, resuélvelo” Entonces tú ya sientes cómo es trabajar con esas personas, sientes cómo la persona escucha o no escucha durante las reuniones, si es colaborativa, si impone demasiado su opinión, y yo creo que esos aspectos, para nosotros, son claves en la cultura, los apreciamos muchísimo y nuestro proceso busca validar esos puntos.

Artemio: Fantástico. Me encanta esta cultura alrededor de la empatía.

Rodrigo: Uno de sus tests para entrar es hacer estos equipos de trabajo y resolver un problema con el resto del equipo, ¿cuánto tiempo se toman en una de estas pruebas? Me dio mucha curiosidad porque seguro que es algo que les consume recursos, en un proceso de contratación se ven varios candidatos.

Andrés: Es un tema que para mí también cuando ingresé fue bien interesante porque yo decía “¿cuántas personas aceptan realmente llevar ese proceso?”, pero hay algo bien importante y es que una vez tú le explicas a un candidato por qué lo hacemos, el candidato termina entendiendo y apoyando la idea. Yo, que fui candidato, cuando me lo explicaron me hizo mucho sentido, ¿cómo más van a decidir si yo soy un fit cultural o no si no es trabajando conmigo? Entonces creo que es importante que las personas encuentren el por qué para tener la disposición de hacerlo.

Toma un tiempo y toma recursos, sí, pero vale totalmente la pena. El equipo que tenemos hoy en día de Producto es un equipo que hemos venido armando desde hace un año y todos pasamos por ese proceso. Hoy puedo decir que nos sentimos muy sólidos gracias a ese proceso y también lo aplicamos en otras áreas, no aplica sólo para producto.

Y, desde luego, toca negociarlo, toca hablarlo, pero todo el mundo entiende el valor que tiene y, si la persona no lo entiende y no está dispuesta, entonces tal vez no es la oportunidad y tal vez no es el fit cultural o tal vez estamos en diferentes páginas. Nosotros casi sentimos que tenemos una responsabilidad social sobre la empatía, tanto con nuestros usuarios como con la compañía, y, si no podemos validar ese nivel de empatía, si no podemos asegurar que esa persona va a ser responsable en el manejo de relaciones con los demás, entonces no es para Elenas. Somos una empresa que se toma muy en serio ese tema cultural.

Artemio: Muchas veces creo que la empatía es un tema que hace falta mucho tocar en muchas compañías que vienen de la generación anterior a esta. Empatía hacia tus empleados, hacia tus usuarios, empatía en general, con la gente con la que negocias, con tus socios. Creo que es un valor que últimamente ha cobrado mucha relevancia pero, al mismo tiempo, también creo que es muy natural por el tipo de empresas que está arrojando el contexto que estamos viviendo.

¿Cuál ha sido el reto favorito al que se ha enfrentado Andrés con su equipo de producto?

Artemio: Andrés, también queríamos preguntarte, de los retos que han resuelto con su equipo de producto, ¿cuál ha sido tu experiencia favorita? Ahorita mencionabas que fue todo un tema entrar a México, puedes irte por ahí, pero es una pregunta completamente abierta.

Andrés: Definitivamente es lo que está en mi cabeza en este momento porque fue una experiencia que significó muchas cosas. Nosotros, en el momento que abrimos México, no teníamos equipo en México. Teníamos unas personas de Colombia dando lo mejor cada uno para tratar de entender cómo lo podíamos hacer. Tuvimos aliados importantes en México que nos ayudaron a entender cómo funcionaba el país, pero era mucha incertidumbre. Sin el manejo de la incertidumbre del día a día, de que tienes el peso estratégico de no saber qué hipótesis aplican en México y cuáles no, tienes al mismo tiempo la incertidumbre de que no sabes qué cosas de tu producto necesitas internacionalizar y qué cosas necesitas localizar; es una cantidad de cosas que requería demasiada iteración, demasiado trabajo en equipo. Además, el equipo de Producto era más pequeño de lo que es hoy en día, al igual que el equipo de Tecnología. Fue un reto.

México lo hicimos en tres meses. Fueron tres meses desde que dijimos “vamos a lanzar en México” hasta que lo lanzamos en México. En ese proceso, adaptar producto, hacer estudio de mercado, encontrar personas que nos quisieran dar a entender cómo trabajaban esos temas de dropshipping y de venta directa. Adicional al proceso de cuando nosotros lanzamos, yo me acuerdo muchísimo de la semana en la que lanzamos, empezamos a recibir los primeros datos y es verdaderamente emocionante sobre todo porque fue nuestra primera expansión y yo creo que eso va a quedar en la memoria de todos los que formamos parte de ese proyecto porque fue un proceso bastante bonito, bastante retador, y te sientes vulnerable, sientes que, por más que ya tengas un market fit en un país y que tengas un tamaño y una cantidad de usuarios, es como volver a empezar y un error cuesta muchísimo. Si las cosas hubieran salido realmente mal, se hubiera podido comprometer también nuestra operación en Colombia. Fue un reto muy interesante.

Artemio: Es bien curioso cuando te enfrentas a este tipo de retos o cosas que representan un hito para la empresa en la que trabajas porque se vuelve, desde un lado, un reto intelectual, al final del día es un acertijo donde tienes que tomar un chorro de decisiones y al final escoger una e ir con la apuesta que tú hayas elegido pero, por otro lado, también se vuelve una batalla muy personal porque el intelecto detrás de quien resuelve el acertijo es tuyo enteramente o de tu equipo. Entonces, siento yo, que cuando un equipo logra este tipo de hitos, se afianza mucho la relación que hay entre ellos, la relación que tienen con la empresa, y queda extra decir que terminan de dominar lo que sea de lo que se trate el producto en cuestión. Creo que es mediante que se desbloquean estos retos que un equipo termina por sentirse un equipo.

Qué chida experiencia, qué rápido lo hicieron, fueron muy ágiles.

¿Cómo es diferente trabajar en productos que están probando su product-market fit vs productos que buscan escala?

Rodrigo: Andrés, tú tienes experiencia en agencias, ¿no? Algo que nos llamaba mucho la atención, del punto de vista que nos podrías dar tú habiendo tenido esta experiencia, ¿cómo es diferente trabajar en productos nuevos que están apenas probando un product-market fit, que apenas van a salir y están en las primeras etapas contra productos que ya buscan escala, que todavía pueden probar funcionalidades nuevas, sin embargo, ya no es un producto que apenas están armando y que apenas van a lanzar?

Andrés: Yo, de cierta manera, he reflejado que nuestra cultura se trata mucho de seguirnos sintiendo en fase de product-market fit y constantemente nos evaluamos así. Cada proceso de research que hacemos tratamos de validar eso, de validar los puntos de market fit y cómo estamos con respecto a cómo nos sentíamos hace unos meses. Y yo creo que es una cultura que tiene mucho que ver con lo que mencioné antes, es ese balance en cualitativo, en escuchar, hasta que tú no escuchas una historia completa, hasta que no te sientas con una embajadora y te muestra cómo utiliza el producto en su celular y tú ya ves que le instaló un skin a su celular Android que no la deja ver cierta información como nosotros la diseñamos en el Figma, pierdes muchas cosas, pierdes cosas que pueden comprometer tu market fit.

Yo creo que se trata mucho, en esta etapa, de eso. Junto con la data, una forma de medir de forma rápida, es muy popular que uno, en esas primeras instancias, cuando hace análisis por cohort y los cohort son de tiempos un poco más cortos de lo que estaría midiendo una startup que está en un stage de serie B o serie C, la velocidad, definitivamente, como yo mencionaba antes, te puedes dar el lujo de hacer cosas más rápido, de fallar en grande si quieres porque el fallo en grande, a la larga, te puedes recuperar rápidamente, versus una empresa en otra escala en la que fallar en grande puede significar una pérdida en su economía bastante alta durante un periodo de tiempo y no se puede dar ese lujo. Yo creo que esa mezcla de lo cualitativo, velocidad, perderle el miedo e iterar en grande es algo importante en market fit. Y, en escala, es bonito, yo he vivido ese proceso de tomar empresas súper grandes que tienen todas las ganas de meterle velocidad, imprimirle agilidad a su cultura, pero tiene ese balance en el que tienes que usar mucho más la data porque, cualitativamente, es imposible cubrir un scope en el que tú te sientas validando hipótesis, te toca acudir a la data muchísimo más, debes tener mucha más atención al detalle, un funnel en el que, por la mala ubicación de un botón, se te están yendo dos o tres puntos porcentuales; cuando estás en una etapa de product-market fit, lo arreglas y puedes experimental con él. Pero si estamos hablando de una gran banco, del pago y de la recuperación de cartera, esos dos o tres puntos te pueden golpear bastante, entonces hay que tener atención al detalle.

Y el change management. A medida que creces, debes tener más en cuenta a los usuarios que ya tienes y cómo hacen las cosas hoy, cosa que en un stage temprano, tú te puedes dar el lujo de cambiar la experiencia, cambiar el paradigma, y los usuarios que estaban se van a adaptar y los nuevos que lleguen ya van a llegar con ese nuevo paradigma. Cuando tienes una base de usuarios muy grande tienes que hacer un proceso de change management, pensar en las comunicaciones, cómo hago este cambio más progresivo, cómo lo mido poco a poco para ver cómo se están comportando los nuevos usuarios versus los usuarios anteriores, entonces son retos en ese aspectos pero los dos lados tienen un nivel de complejidad bastante alto y son divertidos.

Artemio: Acá en el estudio nosotros hacemos muchísimos design sprints, nos gusta decir que en nuestro equipo somos ninjas del design sprint y, algo que a mí me da pavor el día que son las pruebas de usuario, es no encontrar patrones. Por fortuna, nunca hemos tenido ese problema, siempre hemos estado más del lado de “encontremos product-market fit, hablemos con este nicho muy en particular" y, a partir de la tercera entrevista, ya empiezas a identificar de manera muy visible cuáles son los patrones que hay que cambiar, qué no está bien, qué les gustaría, pero siempre, ese día en la mañana yo tengo ese miedo de que nos vayan a decir cada uno una cosa distinta. Y me imagino que eso sucede ya que escalas, ya que tus usuarios pueden ser muchísimos tipos de business personas, mencionaste ahorita un banco.

Hablamos hace un rato con Mafer Herrera, que fue la Directora de Producto de la RappiCard o la Directora de Diseño, fue de nuestras primeras entrevistas. Ella nos contó que a ellos no les funcionó muy bien el mecanismo de tener cinco o seis business personas porque las personas que pueden acceder a un servicio bancario tienen muchísimos trasfondos, tantos que ya no hace sentido tener una lógica de estas. Me imagino que eso sucede una vez que escalas.

¿Cuál ha sido el error más importante de Andrés en su carrera?

Artemio: Andrés, tienes muchos años de experiencia construyendo productos, ¿cuál ha sido el error más importante de tu carrera hasta ahora? O tal vez uno que, en ese momento, pareció catastrófico pero que hoy volteas a ver y sabes que aprendiste muchísimo de eso.

Andrés: Hay uno que puede que no sea tan catastrófico. Yo creo que, a nivel impacto, contra otros productos donde pude haber cometido errores que generaron más problemas, yo recuerdo uno mucho porque me hizo sentir mal desde una perspectiva más ética, no porque haya hecho algo que conscientemente hice mal, sino porque fui ingenuo y fue de mis primeras experiencias como Product Manager con una startup estadounidense. Caímos en la trampa del Scrum. Del proceso puedo hablar horas, pero caímos en una trampa en la que tú tienes que estimar unos tickets y, con esos tickets, haces un planning donde dices qué vas a hacer en este ciclo, que usualmente es de dos semanas, teníamos estos ciclos de sprints de dos semanas. Y caímos en una trampa que es que hay un punto en el que se te olvida que la base del Scrum es entregar valor, pero el valor tiene que ser realmente una entrega de valor completa al final del sprint y muy pocos equipos hacen eso, muy pocos equipos realmente piensan, al final de un ciclo de trabajo, en que están entregando algo completo. Realmente, los equipos se confían porque creen que siempre va a haber un sprint más, que después de este sprint voy a tener otro. Entonces decimos “hagamos el backend de esta funcionalidad y luego hacemos el frontend”. Hicimos el planning, dijimos “hagamos esto, hagamos el frontend y el backend lo hacemos después”, no hubo después. Cuando se acabó el sprint, cuando hicimos el product demo, nos dijeron “no vamos a seguir trabajando, el equipo lo va a tomar” y, para colmo, tuve que ver cómo ese producto que nosotros entregamos lo pusieron en producción y cómo la funcionalidad de la que nosotros entregamos sólo el frontend no funcionaba porque no tenía backend. Y yo siempre, a partir de ahí, utilizo un ejemplo con mis equipos y siempre les digo “piensen que el ciclo en el que están es el último ciclo que entregan. Siempre piensen de esa manera para que se reten a entregar algo que verdaderamente funcione”. Es preferible que recorten una funcionalidad completa y que construyan otra completamente a que entreguen dos funcionalidades que funcionan a medias. Y eso es algo que aprendí y que realmente me puso a pensar muchísimo en esa época y lo sigo cargando como un ejemplo de malas decisiones que he tomado en el pasado, yo creo que es una de las que más resalta.

Artemio: Esta es una gran experiencia también para toda la gente que nos está escuchando, muchas gracias por compartirnos eso. Hasta a nosotros nos pone a pensar. Me surgió una duda fuera de guion. ¿Tú tienes un perfil técnico? ¿Tú sabes programar, Andrés?

Andrés: Yo no soy ingeniero y nunca me he llamado a mí mismo un desarrollador, pero digamos que cuando me vuelvo a 2008 o 2009, en esa época los diseñadores, yo soy diseñador, hacíamos primero el código de maquinación, hacíamos HTML, CCS, pero, en ese momento, yo trabajaba sobre la plataforma de Sharepoint de Microsoft y otras plataformas que también funcionaban en .net, y me tocó aprender del tema. Cuando era diseñador hice páginas, intranets, y realmente sí tuve que aprender algo de código para poder llevar a cabo esos proyectos. Luego tuve unas épocas de entusiasta en JavaScript del lado del servidor y temas de ese estilo, pero nunca me he considerado un desarrollador propiamente, sin embargo es un tema que me ha dado curiosidad y me ha gustado en algunos momentos profundizar.

Artemio: ¿Cómo lidias con medir la carga de trabajo de los programadores en un sprint? Entiendo que tienes estos conocimientos básicos, pero también, por lo que dices, no inferiría que sabes de todo a todo cómo funciona el backend de una aplicación, pero de igual forma llevas la administración del producto y de qué features se van implementando. Entonces, ¿cómo lidias con esta medición de la liga para que el equipo sí llegue en dos semanas?

Andrés: Este es uno de los puntos claves en un cambio metodológico que hicimos a final de año y es que no estamos haciendo ciclos de dos semanas. Nosotros empezamos a adoptar un poco una metodología híbrida, pero algo que hice fue que le compartí a todo mi equipo un libro que se llama Shape Up, para los que no los conocen, es un libro escrito por los fundadores de Basecamp en el que ellos describen cuál es el proceso que utilizan en el interior de Basecamp para diseñar features. Yo cuando hago este tipo de cosas, desde luego lo leo yo primero, pero cuando lo comparto con el equipo les doy los puntos clave, cuáles son las cosas a tomar en cuenta, y creo que Basecamp es uno de esos casos en los que yo le dije a mi equipo que lo tomaran con la responsabilidad de saber que estos libros cuentan las cosas positivas de lo que se está escribiendo ahí, pero que tienes que ponerlo en práctica y saber cuáles son los downsets.

Entonces nosotros lo que hacemos es que trabajamos en ciclos más largos. Basecamp propone trabajar en ciclos de desarrollo de seis semanas. Posterior a esas seis semanas, trabajas en dos semanas que se llama cool down que es cuando estabilizas la entrega que se hizo. Nosotros lo recortamos un poco, estamos trabajando con cuatro semanas de desarrollo y dos de cool down. La regla fundamental uno es involucrar a tu Tech Lead y a tu equipo de Tech desde el shape, desde el momento en el que se está definiendo qué se va a hacer, y ahí te quitas el problema de la asignación porque, si tú sabes que tienes un ciclo de cuatro semanas de desarrollo y tú te sientas con el Tech Lead, con el Product Designer y con el Data Analyst y entre los cuatro dicen “este es el problema que tenemos y estas son las hipótesis de cómo solucionarlo”, cuando terminen, van a tener algo que se van a demorar cuatro semanas haciendo o van a tener algo que es más largo y ahí la responsabilidad del Product Manager es ver, de eso, qué cosas vamos a cortar hasta que logremos llegar a las cuatro semanas, pero es una comunicación constante con el Tech Lead.

A mí nunca me ha parecido que optimizar sobre que el Product Manager prediga cuánto se va a demorar algo sea sano y poner tampoco a un equipo de Tech a decirle “mira este diseño, estima cuánto te vas a demorar”, es algo que no es tan sano. Y Shape Up describe muy bien cómo manejar eso durante el proceso, inclusive te dicen que, cuando estés en el proceso de construcción, tú tienes unos niveles de incertidumbre. Dependiendo del nivel de incertidumbre en el que estés en el desarrollo, toma la decisión de cortar donde tengas que cortar, decir “no salgamos con eso, quítalo por completo”, hasta que el equipo se sienta cómodo con lo que va a tener que entregar al final de ese ciclo. Debo decir que funciona en Elenas y podría funcionar en otras empresas de producto pero, teniendo este contexto de agencias y pensando en otras modalidades, probablemente no van a pasar otras maneras de hacer seguimiento ahí y, en ese caso, utilicen cosas muy clásicas.

En su momento yo dejé de utilizar Scrum y me fui por Kanban, que me parecía un poco más fácil de controlar, pero sí creo que la mayoría de los problemas ocurren por no involucrar al equipo lo suficientemente temprano, por asumir que tú puedes sentar a un Product Manager a escribir un documento con todo lo que hay que hacer y que al final de eso va a salir algo bien hecho. Yo creo que, para que algo salga bien hecho, tienes que sentar desde el comienzo a todas las personas que son accountable, de lo contrario no te va a funcionar.

Rodrigo: Nos hemos encontrado varias veces con ese problema porque nosotros estamos del lado agencia y, teniendo este podcast, hemos escuchado un montón de metodologías, de cómo se arman los squads, de qué perfiles están juntos para no tener este tipo de problemas, y nos hemos roto la cabeza intentando implementar estrategias de este tipo y, después de un rato, hemos dicho “no, no somos una startup”, los procesos tienen que ser diferentes, no tienes a la gente haciendo lo mismo, los objetivos varían.

¿Cuáles son los retos más grandes a los que se enfrenta Andrés Palacio y Elenas en los próximos años?

Rodrigo: Nos estamos acercando al final de la entrevista, nos queda una pregunta. Ha sido una charla muy esclarecedora, pero esta última es de nuestras favoritas, la hacemos en cada episodio, nos ayuda a ver cuáles son las preocupaciones generales del ecosistema. Ante los retos que enfrenta Elenas y tú como VP de Producto en los próximos años, ¿qué te quita el sueño?

Andrés: Yo pienso muchísimo en los retos más a nivel macroeconómico, si se pueden llamar así. Yo soy una persona que está constantemente leyendo lo que pasa en la base de usuarios, viendo si sale competencia, qué está haciendo diferente la competencia, y ese tipo de cosas las considero un poco el business as usual del rol, pero lo que realmente me quita el sueño y me pone a pensar muchísimo es en cuáles son las cosas que no puedo controlar y que Elenas no puede controlar y que pueden cambiar fundamentalmente nuestro modelo de negocios.

Y yo creo que, hablando de lo que nosotros estamos haciendo en este momento, que es un modelo de venta directa que lleva muchísimos años, que se ha venido renovando, pero que es un modelo que, en sí mismo, todo el tiempo ha estado compitiendo con las plataformas de ecommerce y con los modelos de venta en línea desde el momento en el que nacieron, y hay algo de valor detrás de lo que está pasando ahí, si no hubiera valor ya estas empresas no existirían, nosotros no existiríamos, pero tú no puedes sencillamente asumir que eso va a seguir funcionando por toda la vida, tú tienes que ser un agente de cambio y mantenerte todo el tiempo pensando cómo vas a seguir dando valor sin importar lo adverso que sea el contexto.

Yo discuto muchísimo esto con el equipo de liderazgo, con nuestro CEO, miramos mucho el ecosistema asiático, para nadie es un secreto que Asia es un ecosistema muy interesante del que tenemos mucho que aprender y que ya muchas startups en Latinoamérica funcionan replicando modelos de Asia, y esto quiere decir que Asia es como una mirada adelante de lo que está pasando en Latinoamérica y en algunos aspectos es al revés, también pasa lo contrario, pero es importantísimo no sentirse cómodo con lo que está pasando, no asumir que tú vas a seguir creciendo, que tus números van a seguir yendo hacia arriba, sino entender que hay riesgos macroeconómicos, que hay riesgos a nivel geopolítico y que tú tienes que anticiparlos y saber adaptarte, y esa no es una tarea fácil porque es completamente incertidumbre. Tú no sabes dónde empieza, dónde termina, qué funciona y qué no, pero es muy bonito al mismo tiempo, es un problema de esos en los que quieres pensar, alguien lo tiene que pensar, y yo como VP siento que tengo la responsabilidad de pensarlo junto con mi equipo y los otros líderes, pero es algo que quita el sueño definitivamente.

Artemio: Andrés, muchísimas gracias por venir a este paso, genuinamente estoy muy contento con el resultado de este capítulo, creo que le va a servir muchísimo tanto a fundadores como a gente de producto y diseñadores, creo que tienes una gran filosofía, felicidades por eso.

Le recuerdo a la gente que nos está escuchando que en cuandoelriosuena.com encuentran el call to action a nuestra newsletter y, si se suscriben, nosotros prometemos enviarles un capítulo cada que tengamos una nueva publicación. De igual forma, en el correo de confirmación que les llega de la newsletter, pueden encontrar el link a nuestra comunidad de discord.latamstartup.club  en la que habemos más CEOs, CTOs, abogados del ecosistema de startups, gente de producto, gente de ventas, gente de HR, realmente este es un espacio que es abierto, es gratuito, ustedes pueden acercarse a hacer la pregunta que quieran y nosotros, si podemos, les echamos la mano.

De igual forma, si creen que este espacio pudiera servirle a alguien o es para alguien que, al momento de yo hacer este anuncio, se les viene a la cabeza alguna persona, compártanlo con ella para que pueda llegar a nosotros y tengamos un genuino win-win. Sin más que agregar, nos vemos a la próxima, muchas gracias al equipo que hace posible este podcast, Belmont, Yok, Viri, y un saludo también a Jack. ¡Nos vemos a la próxima!

Si crees que a alguien le seria útil este contenido, compártelo con esa persona.

Escucha otro episodio

los mejores recursos para negocios digitales

Nunca dejamos de aprender sobre nuestro ecosistema, cuenta con que compartiremos lo más valioso contigo.

Conoce las lecciones más valiosas después de +130 episodios publicados de nuestro podcast. Lee sobre la Minimum Viable Startup.

suscribirme
switch languageenglish

Solo usamos cookies para brindarte la mejor experiencia en nuestro sitio, pero puedes revisar nuestra política de cookies e inhibirlas si prefieres. Si sigues navegando por el sitio asumiremos que estás de acuerdo con ellas.