Las Jugadas Más Engañosas en Producto, Reveladas

Hannah Clark: Las cosas no siempre son lo que parecen. Desde precios de suscripción engañosos hasta personas que juran que el maíz dulce realmente sabe bien, nunca faltan razones para ser escépticos de todo—especialmente ahora en producto. El ritmo del cambio en esta industria avanza tan rápidamente que las tendencias pueden empezar a parecer buenas prácticas y las verdaderas buenas prácticas pueden parecer desactualizadas. Pero cuando el objetivo es construir un producto que pueda escalar con el tiempo, depende de nosotros verificarnos para no dejarnos arrastrar por la hipnosis del tren de la moda.

Mi invitado de hoy es Matt Graney, director de producto (CPO) en Celigo. Matt ha pasado más de 20 años en producto B2B y casi nueve de ellos escalando el equipo de producto de Celigo de cuatro a más de 45 personas. Y aunque la IA ha demostrado ser una oportunidad extraordinaria para la compañía, ha notado una brecha entre las expectativas y la realidad cuando se trata de algunas de las relucientes nuevas tácticas que inundan nuestro feed de LinkedIn. Desde prototipos disfrazados de código listo para producción hasta herramientas demasiado buenas para ser verdad, escucharás su perspectiva sobre dónde pisar con cautela, y la sabiduría probada que le permite sobrevivir a esta transformación de la IA. Vamos allá.

Por cierto, tenemos conversaciones como esta cada semana. Así que si esto te parece interesante, ¿por qué no te suscribes? Ahora sí, entremos en materia.

Bienvenidos de nuevo al pódcast El Product Manager. Hoy estoy aquí con Matt Graney, CPO en Celigo.

Matt, muchísimas gracias por hacer tiempo en tu agenda para hablar con nosotros.

Matt Graney: Gracias, Hannah. Un placer hablar contigo hoy.

Hannah Clark: ¿Puedes contarnos un poco sobre tu trayectoria y cómo llegaste a ser CPO en Celigo?

Matt Graney: Sí, llevo mucho tiempo en producto B2B, unos 20 años. Celigo es una plataforma de integración, llevo ocho años y medio allí, entrando justo después de la ronda de financiación serie A.

Y otros cinco años y medio antes de eso también en el ámbito de la integración. No fue realmente planeado, simplemente las cosas se dieron así. Antes de eso, participé en productos relacionados con el ciclo de vida del desarrollo de software, incluyendo herramientas de modelado UML. Para quienes recuerdan lo que eran, originalmente fui ingeniero de software en Australia trabajando en telecomunicaciones y defensa.

Vine a EE.UU. para trabajar como ingeniero de preventa, en realidad para un producto en el que me convertí en usuario avanzado mientras estaba en Motorola. Así que he tenido un recorrido variado. Más tarde, pasé por marketing de producto y finalmente llegué a producto.

Hannah Clark: ¿Un recorrido? Nunca lo había escuchado así descrito.

Es gracioso. Hoy nos vamos a divertir con un episodio medio temático de Halloween, enfocándonos en jugadas malas disfrazadas en producto. Vamos a comenzar hablando de Vibe Coding. Hay muchas opiniones sobre Vibe Coding en la comunidad de producto.

Y debo admitir, las plataformas no-code son herramientas increíbles, yo las uso todo el tiempo, pero también pueden darnos momentos muy al estilo Scooby-Doo, cuando nos quitamos la máscara y vemos que no es lo que parece. ¿Cuál ha sido tu experiencia, Matt, con Vibe Coding dentro de equipos de producto?

Cuéntame lo bueno, lo malo y lo feo.

Matt Graney: Sí. Y lo habríamos logrado si no fuera por esos niños entrometidos, ¿verdad? Creo que es una democratización, lo cual es increíble. Pero hay que pensar en la ilusión: que algo se vea bien no significa que esté bien construido.

Y creo que hay mucho trabajo bajo la superficie. No debemos confundir prototipos rápidos con código listo para producción. Así que, bien por los creadores ciudadanos, pero también hacen falta arquitectos ciudadanos. Y en el contexto del negocio en que estamos, por ejemplo, B2B, hablamos de software de infraestructura donde tratamos con miles de millones de transacciones al mes.

Solo ciertas partes de la aplicación, quizás en el front-end, pueden ser abordadas con Vibe Coding. Así que debe ser la herramienta adecuada para el trabajo adecuado, como siempre ha sido. Mientras fomentamos una cultura de experimentación, animando al equipo a tomar riesgos, probar nuevas herramientas y mantenerse al día en esta época revolucionaria para la industria.

Hannah Clark: Profundizando un poco más en eso, cuando pensamos en los distintos niveles de entendimiento tecnológico en toda la organización, puede ser tentador para quien tiene menos experiencia, o fundadores nuevos, ver algo que parece código funcional e ir directo al grano. Eso genera presión para que los equipos de ingeniería igualen esa velocidad y parezcan estar al mismo nivel, tan brillante y nuevo.

Entonces, ¿cómo ayudamos a los stakeholders a entender las verdaderas limitaciones y consideraciones entre un prototipo hecho con herramientas de Vibe Coding y software realmente listo para producción?

Matt Graney: Excelente punto, porque la velocidad para la demo no es lo mismo que la velocidad para producción y, especialmente, con 5,000 clientes en cargas empresariales B2B hablamos de infraestructura. A veces lo llamamos la plomería.

La IA puede pintar la casa, pero no necesariamente la va a instalar la plomería, ¿cierto? Hay que tenerlo claro. Hay desafíos ya sea por presión en ingeniería o incluso desde el equipo ejecutivo. Últimamente, he visto miembros bastante altos del personal no técnico haciendo Vibe Coding de pruebas de concepto para mostrar nuevas capacidades muy necesarias para los clientes.

Eso dispara la imaginación, pero también crea una presión no dicha de que esto puede ser para todos y se puede llevar rápido a producción. Si seguimos la analogía de la casa, estos no son muros estructurales, son solo la fachada, puede lucir bien. Pero igual, hay un lugar para esto porque la rapidez del POC es increíble. Debemos aprovechar esa velocidad para ayudar a los PMs a explicar requisitos, a los diseñadores a mostrar flujos alternativos.

Antes diseñaban pantallas en su herramienta de diseño favorita, ahora pueden usar código funcional, y eso tiene mucho poder. Pero no es lo mismo que código listo para producción.

Hannah Clark: Y algo que pienso a menudo es que estas herramientas inevitablemente se harán más sofisticadas, y nosotros como usuarios también lo seremos. Eso significa que el costo de construir se acerca a cero.

Como líder de producto, ¿qué te preocupa de esa tendencia y qué has hecho para mitigar esos riesgos en Celigo?

Matt Graney: Hannah, creo que ese es un buen modelo mental, preguntarse: ¿Qué pasa si el costo de construcción tiende a cero?

Quizá estamos cerca de eso, conforme avancen las generaciones de estas herramientas y los usuarios sean más hábiles, como pasa con experiencias tipo ChatGPT. Así que el costo de construir baja dramáticamente. Pero, curiosamente, eso pone aún más presión en los PMs para asegurarnos de construir lo correcto. Por eso no nos exime de las responsabilidades: analizar analíticas, hacer investigación de usuario cuantitativa y cualitativa, entrevistas, consejos de clientes, todo.

Pruebas de concepto, A/B testing, trabajar en triada con PMs, diseñadores e ingeniería. Nada de eso desaparece. Hay que defender esas disciplinas porque con tantos proyectos sencillos de hacer, podríamos acabar con zombies—proyectos fáciles de construir, pero que no llegan a nada.

Por eso las disciplinas tradicionales de gestión de producto cobran importancia: la capacidad de decidir y lograr los resultados correctos debe mantenerse.

Hannah Clark: Coincido. Sobre ideas poco meditadas, he visto una explosión de herramientas en el mercado que prometen grandes beneficios ocultando (o ni siquiera ocultando) riesgos enormes.

He visto conceptos que claramente podrían ser manipulados por actores malintencionados, no es lo que queremos. ¿Qué cosas en este espacio te generan más cautela, y qué rol sigue teniendo el juicio de producto que no se puede automatizar?

Matt Graney: Siempre hemos buscado la bola mágica de la gestión de producto, ya sea con metodologías de valoración como RICE.

Las he visto ser abusadas porque dejan margen para que los PMs manipulen puntuaciones, y pronto se aprende cómo inclinar la balanza. Aquí veremos los mismos riesgos.

Algunas herramientas prometen recolectar la inteligencia—telemetría, conversaciones—pero sabemos que muchas cosas ocurren fuera de lo registrado, en observaciones que un LLM no entendería.

Por eso no hay sustituto para el buen juicio de producto. Aunque tengamos más datos que nunca, siguen siendo incompletos. Aún necesitamos visión, estrategia y seguir apostando, midiendo resultados si hacemos bien nuestro trabajo.

Pero el proceso sigue siendo iterativo y no hay una respuesta mágica que la IA nos dé para armar una hoja de ruta infalible.

Hannah Clark: Coincido. Hablaba con un invitado (aún no ha venido a este programa) sobre la IA como tecnología “irregular”: algunas cosas las hace muy bien y otras parece que las hace bien, pero no es así.

Así que, además del sentido de producto, hay que conocer la tecnología lo suficiente para saber hasta dónde confiar o no en que el LLM lo haga por ti.

Matt Graney: Incluso con las interfaces de chat básicas hemos visto IA muy lisonjeras, ¿no? Y si no te das cuenta, puedes llegar a creer que siempre tienes grandes ideas.

A mí me gusta mezclar y pedirle opiniones muy críticas a la IA sobre mis ideas. Si no, siempre suena como si yo fuera un genio para la IA.

Hannah Clark: Sí, ¡nos adoran! Pasando página, quiero hablar de otros atajos atractivos pero insostenibles que los equipos de producto están tomando ahora.

¿Cuáles te parecen los peores?

Matt Graney: Uno de mis favoritos son los OKR. Tenemos una relación problemática con ellos: a nivel empresa no van tan mal, pero en producto pueden ser un desafío al importar algo de un gran nombre (tipo FANG) sin importar la cultura que lo sostiene. Es como hablar de los monstruos de Frankenstein: si no tienes la cultura adecuada, nunca se va a unir todo bien.

Eso es una cosa. Luego está el “teatro de métricas”, métricas de vanidad que no nos cuentan nada ni ayudan a decidir mejor. Eso es una trampa antigua. Hablamos de fábricas de características, y ahora podemos producir por hectárea gracias a la escala, pero, ¿cómo aseguramos producir lo correcto? Todos esos atajos buscan soluciones mágicas porque “alguien lo leyó en X o LinkedIn” y, sin rigor, sólo erosionan la confianza.

Hannah Clark: Coincido sobre la erosión de la confianza, especialmente en la comunidad de UX research. Tradicionalmente han sido poco reconocidos y ahora los LLM confunden aún más cómo hacer las cosas bien y el papel de la IA en ese proceso.

Me gustaría gritar que no se puede sustituir la investigación de usuarios por LLM.

Matt Graney: El jefe de research me dice lo mismo: las transcripciones de IA están bien, pero las interpretaciones fallan en captar sutilezas, al menos por ahora, y quizá eso cambie.

A medida que la tecnología avanza, podemos ser optimistas, pero por ahora hay que conocer sus límites y reforzar la investigación tradicional.

Hannah Clark: Cambiando un poco de tema, hablemos de escalar equipos. Has escalado el equipo en Celigo de dos PMs a diez veces más. Seguro hubo errores.

¿Cuáles son tus aprendizajes fundamentales sobre escalar equipos, desde organizaciones pequeñas hasta maduras? ¿Qué sigue siendo cierto incluso hoy con la IA?

Matt Graney: Como dices, ha sido un viaje, Hannah.

Empecé con dos PMs y dos redactores técnicos, equipo de cuatro. Ahora casi llegamos a 50: PMs, diseñadores, researchers, documentalistas y operaciones de producto. He aprendido sobre el orden en que hacer las cosas.

Al principio, todo era sencillo: junto al CTO, tres priorizábamos el backlog entero. Pero eso no escala. Con equipos y PMs offshore se complica.

Añadimos procesos poco a poco. Al principio, el diseño era lo que podíamos, casi armando capturas de pantalla como una nota de rescate, algo casi vergonzoso. Cuando contratamos diseñadores profesionales, no lo hicimos bien: los tratamos como una agencia para “hacer bonito”, no en serio sobre user experience.

La documentación técnica nos ha salido bien y sigue evolucionando. Así que ajustamos los procesos según necesitamos. No lo hacemos perfecto, pero nos ha funcionado y ha permitido a todos crecer. Nunca gestioné un equipo tan grande; tengo cicatrices y canas que lo prueban.

Hannah Clark: ¿De veras? ¿Dónde?

Matt Graney: Oh sí. Le echo la culpa a mis hijos, quizá. Bueno.

Hannah Clark: Todo se le puede echar a los hijos. Yo lo hago siempre. Para cerrar y ligando con lo de antes, ¿qué prácticas de gestión de producto te parecen hoy más importantes que nunca, aunque parezcan viejas?

¿Hay conceptos o marcos que sigas usando con tus equipos en la era de la IA?

Matt Graney: Como dije, a medida que el coste de construir baja, hay que priorizar más. Así que pienso en herramientas de priorización.

Eso exige alineamiento con una visión y estrategia, para que todos puedan tomar decisiones localizadas. Nada reemplaza el contacto de primera mano con usuarios y clientes. Aprendí mucho negociando con clientes insatisfechos al principio de mi carrera.

No hay reemplazo para eso: te da una visión completa del producto y ayuda a priorizar. Priorizar sin piedad es esencial: siempre falta capacidad, incluso en empresas grandes. Así que las herramientas de siempre siguen valiendo.

Donde la IA puede ayudar es en digerir información de investigación y, como hablamos, para prototipos rápidos. Pero los prototipos, por concepto, están hechos para ser descartados, no para servir de base a producción.

Si haces eso bien, las herramientas sí aceleran el trabajo y ayudan a priorizar.

Hannah Clark: Muy bien dicho. Para cerrar con optimismo: ¿Dónde están las mejores oportunidades del valor real de IA para mejorar el trabajo de los PMs? ¿Qué consejo das a quienes quieren abrazar la IA sin caer en estos atajos o trampas que hoy tocamos?

Matt Graney: Una de las grandes es la investigación competitiva. Hoy es una herramienta que me habría gustado tener. Sí, ahora los proveedores publican mucho más y necesitas investigar.

Eso es enorme. También crear documentación rápidamente: preparar un press release o FAQs antes. Puede que antes diera pereza, pero hoy es una gran manera de empezar. Servirse de estas herramientas para expandir la imaginación.

¿Qué me estoy perdiendo? Cuando la IA se le pregunta bien, sirve para descubrir puntos ciegos. A veces alucina, pero incluso de ahí salen ideas o visiones laterales que no habrías considerado. Pero la IA puede ser un espejo de feria: si tu disciplina falla, solo lo empeora. Pero bien usada, da el foco que el PM necesita.

Hannah Clark: Estoy de acuerdo. Matt, ha sido genial. Gracias por compartir tus conocimientos y ayudarte a matizar estas cuestiones que tanto se ven en el sector.

Lo aprecio mucho. ¿Dónde pueden seguir tu trabajo online?

Matt Graney: Mejor en LinkedIn. Es donde más estoy, así que feliz de conectar allí con quien quiera.

Hannah Clark: Perfecto, muchas gracias.

En el próximo episodio de El Product Manager Podcast. Si creías que este episodio ponía expectativas frente a realidad, vamos a sumergirnos en profundidad sobre la tecnología LLM en un episodio que desafiará todo lo que crees saber sobre IA.

Mientras que el potencial de esta tecnología es ilimitado, sus limitaciones actuales son mucho más complejas de lo que creemos, al igual que su impacto en nosotros como creadores y usuarios de productos de IA. Este episodio va a ser intenso, así que suscríbete y acompáñanos la próxima vez.