La figura del Product Manager en startups: Diego Mariño e Ignacio Larrú hablan sobre cómo saber que lo necesitas, a quién contratar, cómo encajarlo en la organización, cómo medir su trabajo… y demás aprendizajes

Jaime Novoa
K Fund
Published in
13 min readFeb 21, 2019

Llevamos ya 52 podKasts, lo que supone que tenemos mucho contenido interesante acumulado. Escuchar esos contenidos puede ser la forma más natural de consumirlos, pero creemos que en algunos casos, leer esos contenidos es una alternativa muy válida e incluso más útil.

El artículo que viene a continuación es una transcripción abreviada y editada de la conversación que Ignacio Larrú y Diego Mariño mantuvieron en el podKast número 6, hace ya casi 2 años.

Diego por entonces trabajaba como Principal Product Manager de New Relic (compañía que compró Ducksboard), de ahí que cuando leas a Diego hablar sobre su rol “actual”, entiendas que se refiere a New Relic y su posición como PM allí.

Si quieres volver a escuchar el podKast, aquí está:

Os dejamos con la conversación de Diego e Ignacio sobre el rol del Product Manager y cómo encajarlo dentro de las empresas tecnológicas.

¿Cómo sé que necesito un Product Manager?

Ignacio: Vamos a hablar de la función de producto en las compañías, que además puede variar de compañía a compañía.

Al principio, las compañías suelen estar formadas por una persona que programa, habitualmente el CTO, uno que vende, el CEO, y luego hay uno uno o varios que suele tener un background confuso, y que a veces acaban encargándose de la parte de producto. Antiguamente rara vez decías “me voy a ocupar de producto”, sino que tú decías “pues yo me ocupo del diseño” y poco a poco ibas asumiendo también funciones de desarrollo de producto

Diego: Sí, y además en los últimos años ha cogido más visibilidad este perfil. Yo creo que antes la parte de producto era siempre una mezcla entre diseño y desarrollo.

No sé por qué últimamente parece que hay más demanda de este tipo de perfiles. A mí me viene bien que la haya y creo que en el fondo es una labor importante. Yo creo que siempre alguien ha de ser el final decision maker de las decisiones de producto, porque si no acabas haciendo un Frankenstein para satisfacer a media empresa. Ha de haber alguien ahí.

Ignacio: Al principio muchas decisiones las toma el CEO y los fundadores pero, ¿en qué punto o qué pistas me dicen a mí que mi compañía necesita una persona de producto?

Diego: En Abiquo contratamos a un responsable de producto y era sobre todo porque necesitábamos a alguien con mucho domain knowledge. Nosotros empezamos como un equipo de investigación en la universidad y podíamos ser buenos programadores, pero nuestra experiencia en empresa corporate para vender este tipo de soluciones era limitada. Entonces necesitábamos a un experto que tuviese dominio del mercado al que nos íbamos a dirigir. Si cometes un error como nosotros cometimos de no tenerlo en ese momento, está claro que lo necesitas y debes darte cuenta de ello por esas señales.

En otro tipo de startups, normalmente al principio el produnt manager (PM) es el CEO, porque es una figura que se asemeja más al decision maker. Es la persona que va a tomar la última decisión. Pero cuando el CEO va desbordado y deja de entrar al Jira, cuando deja de hablar con clientes por rondas de financiación o por temas internos, por lo que sea, entonces es cuando alguien ha de seguir manteniendo esa función.

Vamos, que es un tema de que el día tiene 24 horas y que hay determinadas funciones que deben cumplirse sí o sí. Si tengo que estar con la gestión de la compañía, con rondas de financiación, y además de eso producto, probablemente el producto se va descuidando y ahí es cuando necesito esa función.

Entonces ahora ya entramos en la siguiente fase, que es cuando he decidido que necesito a alguien de producto pero, ¿qué perfil profesional se debe buscar en esos casos?

Ese es uno de los miedos que tengo cuando veo cómo la gente se aproxima a este trabajo. Parece que, como es difícil medir la función de producto, puedes contratar a personas que no sean responsables de nada en concreto.

La labor de un CEO la puedes medir por los resultados generales. La de un ingeniero por si entrega o no entrega, ¿pero qué es entregar en producto? Si algo no va bien, de quién es la culpa, es decir, ¿a quien señalamos con el dedo?

Yo creo que el rol de PM las empresas lo entienden de dos formas muy diferentes:

  1. Uno, que es el que a mí me gusta, es el de final decision maker, que vendría a ser como en una película el productor. Es decir, alguien que más o menos tiene una visión de cómo va a ser todo y se encarga de seleccionar y gestionar partes y procesos.
  2. Y hay otro tipo de rol, que es el que se hace más en la empresa grande, que es el product manager como coordinador entre diferentes departamentos. Una figura que gracias a ventas recibe inputs de lo que se puede vender, entonces eso lo transforma en algo que ingeniería pueda resolver, con un trade-off razonable entre tiempo y features a entregar.

Al fin y al cabo, una de las cosas que hace un product manager, y que poca gente dice, es que básicamente me paso el día repitiendo el mismo mensaje en diferentes reuniones. Que yo esté cansado de repetir el mismo mensaje es una señal de que estoy haciendo algo bien.

¿Qué perfil busco a la hora de contratar un Product Manager?

¿Y cómo se identifica un perfil que pueda cumplir estas características en una entrevista de trabajo? ¿Qué buscarías para diferenciar entre el product manager broker y el product manager “obra de autor”?

En mi caso, siempre uso alguna pregunta de estrategia. La típica es preguntar qué crees que va a pasar en la pelea entre Amazon Web Services, Google Cloud y Microsoft Azure. Si tienes un cierto conocimiento tecnológico o tienes un cierto conocimiento de negocio, tendrás un conocimiento de mercado general y sabrás responder a la pregunta y defender tu opinión.

Cuando alguien te dice que tiene experiencia de product manager, una pregunta útil es pedir que te expliquen cómo es un día típico en su actual trabajo: cómo repartes las horas, sobre todo para ver realmente qué hace esa persona, y eso unirlo a cómo realmente cree que ha de invertir su tiempo.

Con esas dos preguntas te puedes hacer una idea que te ayude a filtrar.

Después hay otras características que te pueden ayudar dependiendo de la empresa para la que estés contratando. Si en tu empresa necesitas PMs con un background técnico, pues es un área a explorar, igual que la capacidad de gestión. En algunos casos nos inventamos una feature y pedimos al candidato que explique cómo plantearía todo el proceso de desarrolo, de principio a fin.

Pero en muchas ocasiones, un responsable producto es alguien muy generalista. Ha de saber sobre el proceso de ventas porque va a pasar mucho tiempo con el equipo de ventas, e incluso debe saber vender o saber sacar información a los clientes para que eso ayude a priorizar decisiones. Normalmente los clientes te dan la solución que quieren pero no el problema que tienen, así que si empiezas trabajando en ellos en la solución y no en el problema, probablemente acabarás un poco desviado.

Saber de marketing también es importante, saber cómo nos posicionamos en el mercado y esto cómo afecta a qué mensaje hemos de dar y cuál es la mejor forma de llegar a la persona objetivo para la cual es la feature.

Debe saber de desarrollo, no porque tengas que escribir todas las especificaciones, sino para sentarse a negociar con los programadores. Como empresa, podemos saber que aspiramos a la calidad total de aquí a cinco años, ¿pero cómo priorizamos o cómo vamos a afrontar lo que tenemos que hacer en los próximos tres meses?

El PM debe también hablar mucho con soporte, hablar con la gente de documentación.

En una empresa como en la que estoy ahora, el rol de PM es más como una especie de broker entre diferentes departamentos, para que todos tengamos claro que estamos dando la solución ideal y que el flujo de información es continuo. Yo hasta que no trabajé en una empresa tan grande no me imaginaba lo importante que es que todo el mundo tenga información continuamente.

¿Dónde debo encajar al Product Manager dentro de mi startup?

Esto nos lleva a otro a otra pregunta que yo quería hacerte, que es sobre todas estas funciones longitudinales o más horizontales que trabajan con muchos departamentos. Uno de los problemas que siempre tienes a la hora de diseñar la organización es dónde pongo a producto. ¿De qué depende producto?

Volvemos a la parte de antes de decidir el rol que va a tener en la empresa. Si el responsable de producto es el final decision maker, ingeniería debería depender de él.

Yo creo que en estos temas de diseño organizativo, lo principal es que la estructura que elijas esté en corcondancia con lo que exijas. Es decir, si yo quiero que mi PM sea el dueño total y exigirle como tal, tengo que ponerlo como dueño total. No tiene sentido que quiera que tenga ese rol y que entonces lo ponga por debajo de ingeniería.

Normalmente las organizaciones crecen con un CTO y sin responsable de producto, con lo cual el CTO es desde el primer día dueño del equipo más grande en una empresa tecnológica, que junto con el de ventas debería ser el de ingeniería.

Entonces claro, producto siempre es un equipo pequeño. 10, 15, 20 personas frente a cientos de personas.

A veces se habla de la figura del PM como el de la persona de diseño, como si la creatividad fuese un aspecto fundamental. En mi caso, la creatividad del PM es solo un 5 por ciento de mi tiempo siendo generoso. Realmente es un tema de proceso, coordinación e investigación.

Es decir, todo lo que recibimos de los clientes tenemos que decidir si lo podemos vender, si piden algo que nosotros también consideramos, si es algo que tiene sentido con la visión de la empresa y que encaja con el posicionamiento que tenemos en el mercado. Hay toda esa parte de investigación, de consolidar requerimientos de clientes, que es muy importante.

Luego hay una parte de digerir esto dentro de la empresa y moverlo, y finalmente de encagarte de que la producción y de que la venta sea la apropiada. No necesitas a nadie muy creativo para eso.

La creatividad la puedes necesitar en casos más concretos y puntuales.

Quizás el de PM sea un rol que se asemeja más al de VP de ingeniería que al de CTO. Como cuando existe esa evolución dentro del departamento técnico por el cual el CTO se queda con una labor más de creatividad y de evangelización, y el VP de ingeniería es el que se encarga de que aquello no se suma en un caos absoluto.

Sí, yo por ejemplo si algo toco en mi día a día es sobre todo el correo, Excel y PowerPoint. No necesito muchas más herramientas para hacer mi trabajo.

¿Cómo puedo medir el trabajo de un Product Manager?

Y hablando de herramientas, una de las cosas que a mí me encanta es que tengo el hábito de basar todo en datos. ¿Cómo puede una empresa medir al departamento de producto? ¿Qué métricas le pedimos?

No es un tema fácil porque a veces es difícil delimitar donde empieza y donde acaba la responsabilidad de producto.

Una métrica directa puede ser ventas. En teoría si las ventas suben será porque producto lo ha hecho bien, pero puede también darse una situación en la que producto lo haga bien y que ventas no lo haga tan bien, o que por culpa de ingeniería haya demasiados defectos o retrasos. Es complicado. Si encuentras una métrica fiable para medir el productos puedes dar conferencias al resto de tu vida.

Yo creo que lo bueno y lo malo es que es un cargo de confianza. La parte mala es que no hay una forma clara de medirlo. ¿Voy bien o voy mal? Pues depende de la percepción que los equipos de la empresa tengan de ti, de los objetivos que se han mercado. Y la parte buena es que, como cargo de confianza, tienes cierto poder para una serie de cosas.

Para mí una de las cosas vitales de producto es que en la línea temporal de la compañía, aparece después. El CTO está ahí desde el principio, el de ventas más le vale estar también casi desde el principio por aquello de seguir existiendo, y en un momento dado, el de producto es como el tercer hermano que aparece un poco de la nada y que puede tener ese síndrome de hermano pequeño, de falta de respeto de los otros departamentos.

Yo creo que si hay una falta de respeto hacia la posición es porque no se pueden medir. Si suben las ventas, felicidades. Si ingeniería entrega, felicidades. Pero producto es un poco más etéreo.

Es un tema al que le doy muchas vueltas y que lo hablamos mucho: cómo nos organizamos, cómo contratamos, qué objetivos ponemos, etc. Encontrar una forma de hacerlo que no sea muy estricta porque la persona acaba de llegar, pero tampoco muy laxa como para que incluso se desmotive por no tener métricas contra las que luchar. Es complicado.

Yo creo que lo mejor es tomártelo como un cargo de confianza. Si tienes una persona que se esfuerza, que intenta estar bien informado e informar a otros, que le pone cariño a los resultados, entonces que siga. Pero es complicado porque nunca sabrás si se podría hacer un 10% mejor. E igual no te interesa llegar hasta medir la productividad de esa forma.

Y para los futuros CEOs, que sean conscientes de que hay que apoyar también la figura del PM. Porque normalmente aparece un nuevo ente que además viene a suplantar algunas de las funciones que hacía el CEO.

Yo también creo que para un CEO debe ser complicado abandonar a tu hijo. La startup en una fase inicial es principalmente producto, no suele haber mucho más. Y además todo el mundo opina.

Luego, algún día, probablemente llegue no una persona que tenga la decisión final, pues siempre la tendrán los fundadores, pero una opinión muy importante. Y debe tener el apoyo y la confianza suficiente dentro de la empresa como para que sea una opinión respetada.

Hemos hablado de que sé que necesito producto, a quién contratar, la transición inicial de us posición en la empresa, cómo medirle, etc. A mí también me parece muy importante saber lo que no se puede medir, porque tan malo es no medir como intentar aplicar métricas a algo que no puede ser medible.

El problema siempre es que cuando plantas una métrica la gente tiende a basarse en ella.

Uno siempre tiene lo que mide.

Por eso me gusta que sea un cargo de confianza, porque te permite interactuar de muchas maneras con muchos departamentos y tener la decisión final. No me gusta porque en el fondo no hay ninguna métrica final sobre la que decir “voy bien, voy mal, puedo llegar a ascender”, etc.

¿Cómo evoluciona el rol del Product Manager y su posición según crece la empresa?

Y luego una vez que la compañía ha seguido evolucionando, ¿cómo el equipo de producto y la función de producto evoluciona con la compañía? A lo mejor al principio está más cercana a desarrollo y luego se va acercando más a ventas a medida que la empresa crece.

Yo creo que sí. Si estás creando una empresa en fase inicial, normalmente sois cuatro alrededor de una mesa y si alguien se encarga de producto está seguro sentado con tres ingenieros.

A medida que avanza la empresa, que madura, probablemente es alguien más cercano a ventas. Al final estamos aquí para vender más, para vender mejor y para seguir creciendo. Entonces eso supone que tienes que estar formando parte de ese proceso. Saber qué piden mis clientes por un lado, y luego saber también cuál es la estrategia que llevamos como empresa.

Al menos mi visión, y me parece la correcta, es que la empresa -ya sea el Consejo de Administración o los fundadores-, fijan unos objetivos para este año. A esos objetivos vamos a llegar a partir de una serie de iniciativas, que se constituyen en base a proyectos y los proyectos en base a tareas. Esto supone que producto puede entrar o no en los objetivos, típicamente no, porque se hace a nivel más alto, pero sí que hay que ver con qué proyectos que podamos desarrollar podemos llegar a esos objetivos y qué iniciativas tangibles podemos tener dentro de esos proyectos.

Una de las preguntas que a mí, que he intentado formarme en producto, me asalta es, ¿dónde puedo formarme en producto? ¿Cómo puedo aprender sobre esta función?

Yo creo en la principal fuente es la experiencia. Yo a veces miro atrás y me avergüenzo de cómo podía ser tan lelo.

Lo cierto es que he tenido dos buenas experiencias como empresa. En Abiquo empezamos pequeños y llegamos a tener probablemente en aquel momento, en inicios de 2010, uno de los productos más potentes para gestionar infraestructuras cloud del mercado. Y Ducksboard también cogió mucha fama.

Entonces sí que hay una serie de cosas que sé que he hecho mal, pero también otras seria de decisiones tomadas que creo haber hecho muy bien. Por ejemplo, invertir en diseño en general, no sólo en interfaz de usuario. Abiquo probablemente sea una de las primeras herramientas para sysadmin llena de colores. Esa decisión tenía sentido porque la gente, muchas veces, te acaba conociendo por screenshots. Por lo que si son herramientas para sysadmins, en cuanto pones una un poco colorida, la gente se queda con ella y la recuerda. Destaca mucho.

Y con Ducksboard pasó algo parecido y volvimos a implementar esa filosofía. Funcionó funcionó muy bien.

Si tuvieras que recomendar dos libros sobre producto, ¿cuáles serían?

No lo sé la verdad. Es una pregunta que me hicieron también hace poco.

No me cambió la vida, pero amí me vino muy bien sacarme una certificación de Pragmatic Marketing Framework. Había frases en el curso que te cambian la vida, como por ejemplo, “cuando producto no hace su trabajo, el vacío lo ocupan los otros departamentos”. Pues es verdad, al final acaba ingenería opinando de lo que hemos de priorizar.

Otra frase mítica es “tu opinión aunque interesante, es realmente irrrelevante”.

Al hilo de esto, yo recuerdo el día en el que instalamos Mixpanel y empezamos a ver resultados y debatíamos sobre lo que hacía la gente en base a datos. ¿En Ducksboard por qué no se crean más widgets? ¿Es por que no saben que el botón “más” (+) puede implicar añadir un widget? ¿Es por que entran pero no ven nada y hay un error de conexión, hay un error de JavaScript? ¿Es por que no encuentran los servicios que les interesan dentro los servicios y los widgets que les gustaría ver?

Cuando empezamos a medir todo, pudimos tener respuestas a estas cosas y pasamos de debatir en base a “yo creo” a debatir en base a datos.

--

--