En la columna pasada, Daniel Bilbao, cofundador de Truora, explicó cómo se compara trabajar para una consultora, empresa tradicional y startup(link). Recibió muchos comentarios y preguntas, el interés y nivel de respuesta nos sorprendió un poco. Un área de interés frecuente de los lectores fue las transiciones entre una carrera y otra. En particular, sobre el cambio entre consultoría y startup.

Para profundizar en este tema, yo, Maite Muñoz, me encuentro en la posición perfecta, ya que antes de fundar Truora junto a David Cuadrado, Cesar Pino y Daniel, trabajé como consultora en McKinsey en la oficina de México.

A continuación,  les comparto un poco sobre mi experiencia al pasar de Consultoría a ser Product Manager en una startup de tecnología, y de tecnología pura.

Hace un poco más de un año, decidí dejar mi trabajo como Business Analyst en Mckinsey.  Mi motivación principal era el aprendizaje. Quería trabajar en la industria de tecnología porque ya tenía claro que con software se puede tener un impacto gigante con un equipo pequeño. Me conecté con Daniel y después de varias conversaciones a lo largo de un mes me uní a una startup en etapa temprana como Product Manager (PM). Etapa temprana no alcanza a describir a lo que me estaba metiendo. Cuando me uní a Truora, era la única persona con background de negocios y la única persona que no escribía código en toda la empresa. 

La mayoría de las preocupaciones o miedos que tenía durante la transición son similares a los que muchas personas cambiando de carrera tienen. Preguntas que me siguen haciendo hoy en día: 

“¿Cómo puedo trabajar en producto si no sé nada de tecnología?”, 

“Nunca he liderado un equipo, ¿cómo voy a poder liderar a un equipo de puros ingenieros?”, 

“¿No es producto un trabajo monótono?”, 

Pero ahora, un poco más de un año después, me doy cuenta que es posible trabajar en ‘tech’ sin ser desarrolladora, las habilidades de resolución de problemas son claves, y mi trabajo es dinámico e interesante. 

Irónicamente, las diferencias más cruciales fueron las cosas que nunca me cuestioné. Con eso en mente, pensé en compartir mi experiencia para desmentir algunos de los mitos que rodean el trabajo en producto.

La clave es convertirte en generalista de producto - no experta en una sola cosa

Naturalmente, estaba acostumbrada a aprender rápidamente sobre nuevas industrias, por lo tanto el desafío no era aterrador. Pero lo que sin duda no consideré era cuánto mejoraría en mi trabajo si aprendía más profundamente de tecnología. Sin embargo, resultó que no sólo sería tecnología el reto. Como PM (Product Manager), necesitas saber de experiencia de usuario (UX), tendencias de la industria, wireframing (bosquejos), aprender a interpretar las preocupaciones del cliente, identificar soluciones similares, etc. Por lo tanto, para ser un PM tienes que cambiar tu mentalidad. Es imposible volverte experto en todos los campos, en un tiempo corto. La clave es aceptar que no serás el experto en todo el “viaje del producto”, más bien tendrás que tener suficiente conocimiento de tecnología, UX y necesidades de clientes, logrando unir todas exitosamente. El objetivo es ser una generalista de producto. Afortunadamente tuve, y tengo, un equipo maravilloso que contó con una inmensa paciencia para responder mis preguntas diarias cómo: ¿Qué es un API? ¿Ingeniero full-stack? ¿Jira? ¿Funciones del front-end? ¿Wireframes? ¿User journey?

La planeación es lo fácil - me viene natural

Mi trabajo estaba menos enfocado en PowerPoints, investigación de industria o ingeniarse planes de ejecución para solucionar un problema. Ahora el objetivo tenía dos grandes partes:  entender el problema y proponer una solución, y ejecutarlo. Para la planeación, es aquí donde las habilidades de resolución de problemas, pensamiento analítico, ‘conectar los puntos’, y estar cómoda tomando decisiones fueron muy valiosos. La consultoría me había entrenado para estar “orientada a problemas” y para pensar constantemente en soluciones y recomendaciones. 

El reto estaba en que planear no era suficiente, las soluciones hay que construirlas, lanzarlas y mejorarlas, y rápido! Esto es más difícil. 

Aprender a diseñar un MVP (producto mínimo básico por sus siglas en inglés) toma algo de tiempo. Luego, asegurarse que sería ejecutado correctamente en coordinación constante con ingeniería y diseño, es un problema de comunicación. Para esto consultoría te prepara bien.

Finalmente, priorizar entre los múltiples problemas y soluciones que estaba explorando, y asegurarse de enfocar a todo el equipo en las cosas que de verdad le importan a la startup es lo más difícil; porque nunca hay recursos suficientes para todo lo que se quiere lograr. En mi trabajo vivo o muero dependiendo de como priorice. 

El ajuste más significativo, que al mismo tiempo me encanta y me da más miedo, es la responsabilidad. Mi trabajo era presentar la estrategia correcta y cruzar los dedos a que el cliente lo implementara bien. Ahora, yo soy la responsable de implementarla. Encima de todo, tener las métricas y responsabilidad de que resultará ser una buena solución. En el caso de Truora, hacemos estudios de antecedentes de seguridad: nos aseguramos que el conductor de Didi, o el repartidor de Rappi sea confiable, y hay que hacerlo bien con más de 100 mil personas al mes. No me puedo equivocar. 

Iteración constante en vez de trabajo perfecto

Otra cosa que fue bastante impresionante y pocas veces pensamos en ella, era la metodología de trabajo. Vengo de un mundo que requería un entregable “perfecto” antes de entregar a clientes. Y de repente, estaba en un escenario donde los entregables rápidos eran la norma. Mi lado perfeccionista se resistía (y, francamente, a veces aún lo hace) cuando desarrollamos un MVP, que es la versión más simple que se puede tener de la solución. La mentalidad de construir algo simple y desordenado para probar tu hipótesis era completamente nueva para mi. De repente, me encontré construyendo algo que tendría fallas por diseño y cuyo éxito no recaía en entregarlo perfecto, más bien era sacar ese MVP desastroso y enfocarse intensivamente en todo el feedback que pudiera conseguir. El feedback del MVP era el objetivo.

Aprendizajes y nuevos retos

Habiendo dicho esto, tanto producto como consultoría son trabajos increíblemente exigentes, interesantes, emocionantes y dinámicos. Ambos me han puesto frente a escenarios desafiantes, problemas difíciles y soluciones creativas a lo que a veces parecen situaciones imposibles. Pero lo que ha sido el factor más motivante a lo largo del camino, es que en ambos trabajos me he expuesto a personas, colegas y mentores increíblemente inteligentes que están todos dispuestos a ayudarte y a motivarte a ser mejor.

Un startup como el nuestro, que está creciendo constantemente, te enfrenta a nuevos retos rápidamente. Y naturalmente, los retos como PM para mí continúan. Ahora, me enfrento a ser manager de otros product managers, estando en geografías diferentes y con perfiles distintos. Y, lo más difícil para alguien poco extrovertida como yo, reclutar para poder crecer mi equipo en 4 personas más en el próximo mes. Porque como dicen mis co-founders en su acento caleño “O contratás, o te va a tocar hacer el trabajo de 4 personas, y pues… así complicado” Please help!


Linkedin: Maite Muniz Telleria
Twitter: @mai_mutel