Crear o replantear una función para que aporte más al negocio

Al asumir la dirección del portfolio no solo tenía que decidir dónde invertir o qué productos priorizar. También tenía que definir qué esperaba de la función de Product Management para que esos productos crecieran.

El trabajo en Performance me había enseñado que para cambiar la trayectoria de un producto no bastaba con mejorar el software. Había tenido que entender en profundidad a los clientes, redefinir el problema que resolvíamos, trabajar la propuesta de valor y el precio, preparar a los equipos comerciales y participar en cómo llevábamos el producto al mercado (el go-to-market o GTM).

Quería extender esa forma de trabajar al resto del portfolio, pero no podía limitarme a añadir nuevas responsabilidades a las que ya tenían los product managers. Tenía que decidir qué trabajo dejaban de hacer, qué podía eliminarse o agilizarse y qué responsabilidades debían asumir otras funciones para que el cambio fuera realmente viable.

Una de las decisiones fue trasladar al Engineering Manager buena parte de la gestión diaria de las iniciativas en desarrollo. Eso exigía acordar con Ingeniería una nueva distribución de responsabilidades y conseguir que el equipo asumiera mayor autonomía sobre la ejecución. Producto seguía tomando las decisiones sobre prioridades, alcance y valor, pero dejaba de actuar como gestor permanente del proyecto.

El tiempo liberado debía dedicarse a trabajo que podía cambiar mucho más el resultado del producto: hablar con clientes y con los equipos que estaban cerca de ellos, investigar el mercado, entender por qué alguien compraría cada solución, trabajar su propuesta de valor, explicarla dentro de la empresa y participar en cómo se llevaba al mercado.

Además, el cambio coincidió con la aparición de la IA generativa. Empezamos a trabajar con estas herramientas cuando todavía eran muy nuevas (por entonces, con modelos como GPT-3 y GPT-3.5) y también las incorporé al propio trabajo de Product Management para reducir tareas que consumían tiempo sin requerir necesariamente el criterio del PM.

El objetivo ya no era únicamente entregar mejores productos, sino rediseñar el rol para concentrarlo donde podía tener más impacto y aumentar nuestra capacidad para convertir los productos en negocio.

Ese cambio de foco empezaba por reforzar el discovery. No quería que el Product Manager se limitara a analizar datos, recoger peticiones o validar una solución antes de construirla. Los PM tenían que estar suficientemente cerca del mercado como para empatizar con los clientes y entender cómo trabajaban realmente, qué problemas consideraban importantes, qué alternativas utilizaban, qué hacía que decidieran comprar y qué podía impedir que lo hicieran.

Para conseguirlo, la relación con clientes debía ser mucho más directa y complementarse con el conocimiento de ventas y customer experience. Los datos ayudaban a detectar dónde mirar; las conversaciones permitían entender qué estaba ocurriendo detrás y convertirlo en decisiones.

Performance fue un buen ejemplo. Investigar durante semanas cómo gestionaban las empresas sus evaluaciones nos permitió descubrir que el problema era mucho más amplio que recoger respuestas: había que coordinar participantes, gestionar excepciones y convertir mucha información en decisiones útiles. Ese conocimiento cambió qué construimos, pero también qué valor podíamos prometer y cómo debíamos explicarlo.

En Trainings ocurrió algo distinto. Al estudiar el producto y hablar con los equipos que lo vendían y utilizaban con clientes, detectamos que era relativamente fácil de vender cuando aparecía en una conversación. Investigar por qué nos llevó a una necesidad mucho más concreta que la visión amplia de construir una plataforma de aprendizaje: las empresas necesitaban gestionar formaciones obligatorias, certificaciones y requisitos administrativos. Esa señal pasó a orientar tanto la inversión de producto como su posicionamiento.

Por eso también incorporé mucho más product marketing al trabajo de las PM. Quería que pudieran traducir lo aprendido en una propuesta de valor clara: para quién tenía especialmente sentido el producto, qué problema resolvía, qué lo diferenciaba y por qué alguien estaría dispuesto a pagar por él.

Y esa responsabilidad no terminaba al definir el posicionamiento. Producto tenía que participar activamente en el go-to-market: trabajar con marketing, ventas y customer experience en demos, argumentos comerciales, materiales y formación; aportar criterio sobre precio, packaging o distribución cuando afectaban al crecimiento; y observar qué ocurría cuando la propuesta llegaba de verdad al mercado para seguir aprendiendo. No tenía que sustituir a esas funciones. Marketing conocía mejor los canales, ventas las conversaciones de compra y customer experience la realidad de las cuentas. Producto aportaba una perspectiva diferente: la conexión entre lo que habíamos aprendido del mercado, las decisiones que habíamos tomado sobre la solución y la promesa que la empresa podía hacer al cliente.

Así, discovery y go-to-market dejaban de ser extremos separados del proceso. Lo que aprendíamos del mercado servía para decidir qué construir, pero también cómo posicionarlo, cómo venderlo y qué necesitábamos aprender después.

Participar en el go-to-market implicaba trabajar sobre muchas decisiones que Producto no controlaba directamente. Una PM podía detectar una oportunidad, pero necesitaba a Marketing para darle distribución, a Ventas para llevarla a las conversaciones comerciales o a Customer Experience para desarrollarla dentro de la base de clientes. Por eso reforcé también una capacidad menos visible del rol: influir sin autoridad formal y construir relaciones con otros equipos alrededor de intereses compartidos.

No se trataba de llegar con una petición para que otra función dedicara recursos a nuestro producto. Había que entender también sus objetivos y demostrar qué podía aportar Producto a cambio. Una oportunidad era mucho más fácil de movilizar cuando mejoraba el resultado de las dos partes.

Con Customer Experience, por ejemplo, construimos una relación especialmente estrecha. Su conocimiento de las cuentas nos daba acceso a problemas, objeciones y oportunidades que difícilmente habríamos encontrado mirando únicamente los datos. Producto podía devolver ese valor con mejores soluciones, argumentos y oportunidades para desarrollar comercialmente esas mismas cuentas. La colaboración funcionaba porque ambos equipos ganaban.

En Trainings ocurría algo parecido con marketing y ventas. Detectar que el producto era relativamente fácil de vender no bastaba para conseguir más distribución. Había que explicar por qué dedicarle atención tenía sentido también para ellos. El foco en una necesidad administrativa clara simplificaba la conversación comercial, y agrupar Trainings con otros productos que resolvían obligaciones relacionadas hacía más fácil presentar una propuesta conjunta al cliente.

Parte de replantear Product Management fue, por tanto, enseñar a los PM a mirar más allá de los límites de su equipo. El crecimiento de un producto dependía muchas veces de recursos y decisiones que no controlaban. Su trabajo era construir suficiente evidencia, confianza y alineamiento para conseguir que otros equipos también quisieran hacerlo crecer.

La nueva forma de trabajar no llevaba a aplicar la misma receta a todos los productos. Precisamente lo contrario: permitía entender mejor qué necesitaba cada uno para crecer y movilizar a la organización alrededor de oportunidades diferentes.

En menos de un año, el portfolio más que duplicó su contribución al negocio y pasó de siete a ocho cifras de ARR.

Ese crecimiento fue el resultado del trabajo de muchas personas y de decisiones diferentes en cada producto. Mi contribución como directora fue cambiar las condiciones en las que Product Management trabajaba: quitar peso a tareas que absorbían capacidad sin aprovechar especialmente su criterio, acercar la función al mercado y al go-to-market, y reforzar su capacidad para influir y colaborar con el resto de la organización.

Con el cambio, Product Management no hacía "más cosas", sino dedicaban una parte mucho mayor de su trabajo a entender dónde podía crecer cada producto y a conseguir que ese conocimiento se convirtiera en decisiones, colaboración y negocio.

Handinger podía aplicar sus agentes de IA a muchas tareas diferentes. Esa amplitud era una fortaleza tecnológica, pero también hacía más difícil responder preguntas básicas de negocio: quién debía utilizar el producto, para hacer qué y por qué esa persona elegiría Handinger frente a otras alternativas o seguir trabajando como hasta entonces.

La comunicación partía de lo que la tecnología era capaz de hacer: investigar información, razonar sobre ella, ejecutar acciones o encadenar tareas. Pero una capacidad tecnológica no es todavía una razón de compra. Quien descubría Handinger tenía que hacer por su cuenta el esfuerzo de relacionar esas capacidades con un problema concreto de su trabajo y entender si resolverlo tenía suficiente valor.

Lo mismo ocurría al entrar en el producto. Una herramienta generalista deja muchas decisiones abiertas: el usuario tiene que imaginar qué construir, cómo adaptarlo a su proceso y qué resultado podría obtener. Cuanto mayor era esa flexibilidad, más conocimiento y esfuerzo exigíamos antes de que pudiera experimentar el valor del producto.

Por eso, el problema no se resolvía únicamente mejorando el mensaje. Había que elegir oportunidades de producto concretas y hacer que producto, posicionamiento y adquisición construyeran alrededor de la misma necesidad.

El primer paso fue dejar de tratar todas las aplicaciones posibles de la tecnología como oportunidades equivalentes.

Investigué distintos problemas que Handinger podía resolver y trabajé con el fundador para compararlos según la relevancia de la necesidad, quién podía comprar la solución, qué alternativas utilizaba, qué hacía falta que hiciera el producto para resolverla bien y qué posibilidades teníamos de llegar hasta ese mercado.

No bastaba con que la tecnología pudiera "hacer algo". Tenía que existir un problema suficientemente valioso, un perfil concreto que lo reconociera y una forma razonable de construir y llevar hasta él una solución mejor que sus alternativas. Así decidimos priorizar varias oportunidades alrededor de equipos comerciales, como investigar cuentas, cualificar potenciales clientes o preparar reuniones.

A partir de ahí desarrollaba cada oportunidad hasta convertirla en una propuesta concreta: definía qué intentaba conseguir ese perfil, qué parte del proceso debía resolver Handinger, qué experiencia tenía que ofrecer el producto, qué valor aportaba y cómo explicarlo. De ese trabajo salían la propuesta de valor, la narrativa y el argumentario de cada caso de uso.

Por ejemplo, para preparar una reunión comercial no bastaba con decir que un agente podía investigar información. Había que decidir qué necesitaba saber el profesional, qué trabajo debía asumir Handinger, cómo debía entregarle el resultado y qué beneficio justificaba utilizarlo frente a otras opciones.

El punto de partida dejaba así de ser "qué pueden hacer nuestros agentes" y pasaba a ser qué problema queremos resolver, para quién y qué tiene que ofrecer Handinger para convertirse en una opción valiosa.

Con los casos de uso ya definidos, la adquisición dejaba de partir de canales o temas y podía partir de a quién queríamos llegar y con qué problema concreto. El fundador empezó a utilizar esas propuestas como base para el outbound, con mensajes construidos alrededor de situaciones reconocibles para cada perfil. Y el contenido podía seguir la misma lógica: carruseles o vídeos mostrando un caso de uso concreto, demostraciones del producto y artículos orientados a búsquedas relacionadas con esas necesidades.

Para facilitar esa parte, diseñé también un sistema que traducía cada oportunidad en temas, intenciones de búsqueda y piezas de contenido conectadas con la propuesta de valor, y produje las primeras con ese enfoque.

Así, la adquisición dejaba de desarrollarse de forma independiente al producto: las decisiones sobre qué mercado perseguir determinaban también qué contar, a quién y a través de qué propuesta de valor generar demanda.

En los dos meses que duró el proyecto, la empresa pasó de tener una tecnología con muchas aplicaciones posibles a contar con un criterio compartido para decidir qué oportunidades perseguir y cómo convertirlas en propuestas reconocibles para el mercado.

Ese criterio daba dirección al resto: desarrollo podía trabajar desde casos de uso más concretos, la adquisición sabía qué perfiles y necesidades intentar captar y el fundador podía iniciar conversaciones desde problemas que el potencial cliente ya reconocía, en lugar de tener que explicar primero todo lo que permitía hacer la tecnología.

Este tipo de función es especialmente importante en productos tecnológicos muy horizontales. Cuantas más cosas puede hacer una tecnología, menos evidente resulta por sí sola la respuesta a quién vendérsela, para qué y por qué debería pagar por ella. Product Marketing ayuda a hacer esa elección: reduce posibilidades para convertir capacidad tecnológica en soluciones concretas alrededor de las que la empresa puede construir producto y generar demanda.