Cómo Tener Éxito en una Fábrica de Funcionalidades como Product Manager (con Aakash Gupta, El Experto en Crecimiento de Producto)

Lee la Transcripción:

Estamos probando la transcripción de nuestros pódcast usando un programa de software. Por favor, disculpa cualquier error tipográfico ya que el bot no es correcto el 100% del tiempo.

Hannah Clark: Fábrica de funcionalidades: sustantivo. Definición: una empresa de software enfocada en construir y lanzar constantemente nuevas funcionalidades en vez de crear un producto que los usuarios realmente desean. Usado en una oración: "Pensé que me contrataron para guiar al equipo de producto en una nueva y audaz dirección, pero en cambio solo estoy avanzando poco a poco en una fábrica de funcionalidades".

Dime, ¿saldría tu foto junto a esa entrada de diccionario? Tú y miles de PMs más, mi amig@. Así que si así es la situación, ¿qué puedes hacer al respecto?

Mi invitado de hoy es Aakash Gupta, quien escribe el icónico boletín Product Growth. Antes de dedicarse al boletín a tiempo completo, Aakash pasó los últimos 12 años en roles de producto en niveles senior y ejecutivos en compañías como Epic Games, Affirm y Apollo, lo que significa que ha experimentado casi todos los niveles de influencia que puede tener un product manager.

Y como puedes imaginar, Aakash conoce demasiado bien las circunstancias que generan fábricas de funcionalidades, y su guía para gestionar como PM en estas organizaciones es tanto ultra práctica como refrescantemente realista. Este es un episodio al que querrás poner especial atención hasta el final, así que empecemos.

Bienvenid@s de nuevo a The CPO Club Podcast.

Aakash, muchas gracias por dedicar tu tiempo para hablar con nosotros hoy.

Aakash Gupta: Por supuesto. Encantado de estar aquí. Gracias por invitarme.

Hannah Clark: Sí, un placer. ¿Puedes contarnos un poco sobre tu trayectoria profesional y cómo llegaste a donde estás ahora?

Aakash Gupta: Claro, cuando empecé en gestión de producto allá por 2008, siento que la disciplina no estaba tan desarrollada. Creo que INSPIRED se publicó más o menos por esa época. Creo que eso realmente ayudó mucho a varias cosas. Antes de eso, tal vez estaba el texto de Ben Horowitz, como buen product manager, mal product manager. Pero fuera de eso, el campo no se había profesionalizado realmente. De hecho, principalmente existía en empresas y startups de Silicon Valley.

Me introduje en esto porque los fundadores de la startup en la que trabajaba seguían religiosamente todo lo relacionado con Y Combinator. Y muchas empresas de Y Combinator en esa época tenían product managers. Así que, aunque trabajaba en una startup de solo seis personas cuando ingresé, entré como product manager. Afortunadamente, tenía formación en ingeniería, así que había programado muchas apps y había probado utilizar Photoshop.

Así que hacía de todo al principio. Diseñé todo nuestro sitio web, rediseñé grandes partes de nuestra app aunque mis habilidades de diseño son bastante limitadas. Y para nuestro sitio, gestioné nuestro CMS y toda la tecnología detrás. Así, fui responsable de todo como product manager en esa etapa inicial, mientras encajaba en la gestión de producto y aprendía de qué se trataba, pero era un estilo muy startup.

Luego trabajé en mi propia startup llamada Rap to Beats. Eso era básicamente lo mismo pero con más programación. Estaba creando muchas más versiones de la app. Así que tengo este bagaje de creador dentro de la gestión de producto. A partir de ahí pasé a la gestión de producto pura en una empresa llamada thredUP, que ahora es pública.

Me incorporé cuando era serie C y me fui en serie E. Juntos desarrollamos muchos de los primeros equipos de crecimiento allá. Así que, en 2014, si recuerdas, el programa de referidos de Uber era la gran novedad. Recuerdo que cuando lanzamos nuestro propio programa de referidos, fue un gran impulsor de crecimiento. Bastaba con hacer cosas sencillas como esa.

Ni siquiera lo optimizábamos. Así que empecé a lanzar productos. Me di cuenta de que podíamos cambiar fundamentalmente la trayectoria de crecimiento de empresas como product manager. Así que ahí me comprometí en serio con el oficio de gestión de producto. Desde entonces he sido product manager en empresas como Google, Affirm, Epic Games y, más recientemente, Apollo.io, donde fui VP de Producto. Y ahora dedico tiempo completo al boletín.

Hannah Clark: Genial. Y sé que a much@s les gusta mucho.

Hoy nos vamos a enfocar en las fábricas de funcionalidades y específicamente en cómo los PMs pueden sobrevivir en ese tipo de organizaciones. Es casi una mala palabra en la industria ahora.

Así que empecemos por el principio. ¿Cómo evolucionan las organizaciones hasta convertirse en fábricas de funcionalidades y por qué este resultado es tan común?

Aakash Gupta: De hecho creo que todos los caminos llevan a la fábrica de funcionalidades. Digamos que estás en un entorno empoderado, como los clásicos empoderados. Lo que ha pasado en los últimos cuatro o cinco años es una de dos cosas.

O, como en el caso de Airbnb, el fundador retomó el control y dijo: "Ok, estas son algunas de las cosas que quiero que se construyan". O bien, líderes de producto tomaron el control con muchas rondas de despidos y reorganizaciones. Y lo que suelen hacer es usar reorganizaciones constantes como manera de cambiar gente de posición y asegurarse de que los productos y funcionalidades que quieren se desarrollen.

Al final, lo que ocurre es que ya sea el CEO o los líderes de producto, por las presiones actuales, han dicho: "No podemos simplemente empoderar a todos. No podemos entregar el control porque a veces los product managers tienen 26 años y cuatro años de experiencia".

No podemos entregar las decisiones de un negocio de mil millones a ell@s. Así que incluso en empresas clásicamente empoderadas, hasta Google o Netflix, he hablado con gente allí. No es que los product managers decidan el 100% del roadmap de repente.

Muchas veces hay un proceso ascendente y otro descendente corriendo en paralelo e invisible. Así que el proceso ascendente es el PM proponiendo ideas, presentándolas en la planificación, pero cuando ves el resultado final, mucho de eso es lo que los ejecutivos aprobaron o idearon ellos mismos.

Así que creo que mucha gente decora el entorno empoderado con OKRs y planificaciones trimestrales, pero al final termina siendo una fábrica de funcionalidades. Y eso, para empezar, es solo una cuarta parte de las empresas realmente empoderadas que caen en la fábrica de funcionalidades.

Para el 75% restante, diría que cerca del 30% están en fase de transformación. Estas empresas entienden que deben cambiar a ágil, que deben empoderar a los PMs. Pero lo que pasa nuevamente es que los PMs trabajan con otras funciones, como diseño, ingeniería, negocios y ventas, y en industrias como banca o salud, donde ocurre mucha transformación digital, esas personas aún están acostumbradas a trabajar al estilo fábrica de funcionalidades, estilo cascada.

Así que incluso si el área de producto quiere esos cambios, toma años implementarlos. Hablaba con Marty Cagan y me dijo que toma tres años. Y creo que tiene razón. Son unos tres años. Así que hay empresas en ese proceso. Y lo que pasa es que se les exige a los PMs cumplir ciertas métricas, pero al mismo tiempo se les dice qué funcionalidades construir.

Es una zona gris caótica. Y finalmente, en entornos de cascada pura o fábrica de funcionalidades, muchas empresas lo aceptan sin problema. Si hablas con un PM promedio en Apple, los ejecutivos deciden muchas de las funcionalidades, Jony Ive y Steve Jobs cuando estaba allí tomaban muchas decisiones clave.

Así que ese modelo puede seguir teniendo éxito y muchos piensan que no lo tiene, pero yo he observado que todos los caminos llevan a la fábrica de funcionalidades.

Hannah Clark: Puedo ver que si sigues esa lógica, todo tiene sentido.

Hablemos de algunos de los pasos que describes en el blog que escribiste sobre este tema. Si no lo han leído, es realmente interesante la manera en que lo desglosas y tomas una posición un poco controversial sobre cómo reaccionar siendo PM en una fábrica de funcionalidades. Antes de entrar en los pasos, ¿puedes hablar un poco sobre tu postura y tu alineación, especialmente con Melissa Perry?

Aakash Gupta: Sí, creo que están los idealistas y los realistas. Por el lado idealista están Marty Cagan, Teresa Torres, John Cutler, a quienes admiro y leo todo lo que publican. Pero creo que ell@s creen que, como PM, deberías intentar transformar tu organización si estás en una fábrica de funcionalidades.

Eso es lo que predican, muchas de las herramientas que comparten, los insights tan generosamente gratuitos. Así que los respeto mucho, pero eso es lo que creen. Melissa Perry, yo mismo y otras personas como Clair Vaux, Powell Hearn, somos más realistas. Es decir, a menos que tengas ocho o diez años de experiencia y ya seas gerente de grupo o algo así, no tienes la experiencia ni el peso necesario para transformar tu organización.

Así que en vez de buscar eso, quizá deberías pensar en otra estrategia. ¿Por qué digo esto? Porque he visto muchísima gente intentar ese estilo de vida idealista. Una anécdota que quizá ya han escuchado, porque suelo repetirla, pero me encanta ordenar el subreddit de product management por los posts con más votos de la historia.

Creo que hoy todavía ocho de cada diez posts son de PMs diciendo que odian su trabajo, que es miserable. Y si lees los detalles, son PMs en fábricas de funcionalidades. Algunos dicen: "Entré en gestión de producto tras leer INSPIRED y pensé que podría definir el roadmap, pero solo sigo órdenes del CEO".

Es un caso común: gente en ese 75% de empresas que son fábricas de funcionalidades y están frustrados con su trabajo. Así que, para ahorrarnos el misterio, ya que tengo tantos lectores PM en el boletín, mi consejo realista es: acéptalo. Ríndete ante la fábrica. Te beneficia saber que estás en una fábrica. Ahora puedes decir "si soy un obrero de la fábrica, ¿qué tengo que hacer para adaptarme y avanzar?"

Hannah Clark: Sí, creo que la mentalidad influye mucho en qué tan bien afrontamos cualquier situación difícil. Pero no tiene por qué serlo.

Hablemos un poco de los pasos que diste en el blog, comenzando por rendirse a la fábrica, tema que ya mencionaste. ¿Para ti, cuándo entendiste que era un paso necesario en el proceso?

Aakash Gupta: Creo que fue tras intentos de transformación fallidos. Por ejemplo, he estado en varios tipos de entornos. Muchos PMs nunca han estado en videojuegos, por ejemplo. Yo trabajé en Epic Games con Fortnite. Mucha gente piensa en la fábrica de funcionalidades con el CEO o jefe de producto o diseño decidiendo todo. Pero en empresas de videojuegos, normalmente los diseñadores y creativos son quienes idean lo más cool para la siguiente temporada.

Para mí, como product manager, era obvio que había oportunidades fáciles en rendimiento, onboarding, actualizaciones. Si alguien ha intentado actualizar Fortnite, todavía es un lío, aunque hayamos mejorado. Justo probé actualizarlo y era un archivo de 42 GB. Mi Mac tardó dos horas y luego casi una hora en instalarla. Es fricción extrema y la compañía lanza estos updates dos veces por semana. Así que hablamos de horas de fricción cada semana.

En la tienda de monetización, había oportunidades sencillas para crear más variantes para quienes gastan 2,000–4,000 al año. Pero para convencer a quienes se enfocan en lo cool, una opción que creí inteligente fue decirles: "Enfoquémonos en resultados, no solo en features cool". Pero nadie me escuchó. Probé eso. Después fui a Affirm, con planificación hipercentralizada.

Pensé que en mi roadmap como GPM iba a proponer problemas difusos. Eso no funcionó nada bien: los ejecutivos revisando nuestro roadmap preguntaron si habíamos hecho algún trabajo, pues los de otros equipos tenían detalles, wireframes y hasta cifras calculadas al décimo decimal para impacto de ingresos y profit.

Así que aprendí cometiendo esos errores. Además, ahora que coachéo muchos PMs, llegan a mí porque tienen pequeñas dificultades. A veces, tras hacer una revisión 360, resulta que sus pares de diseño o ingeniería dicen que sus PRDs no eran suficientemente detallados. Estos PMs creen que trabajan en un entorno empoderado, pero en realidad están en una fábrica de funcionalidades donde se espera un PRD increíblemente detallado.

Se saltan esos aspectos fundamentales y por eso rinden peor. La motivación de todo esto es mejorar tu rendimiento. En mi experiencia real, no he visto que se pueda cambiar el sistema de inmediato. Solo lo logré al llegar a director o VP.

En thredUP y Affirm, de hecho, tu trabajo es mejorar las prácticas de tu organización, ir corrigiendo consciente y poco a poco lo que es una anti-práctica como la fábrica de funcionalidades. Pero como consejo de carrera, si no estás a ese nivel, no intentes corregir esa anti-práctica.

Hannah Clark: Lo que nos lleva al siguiente paso, que es adaptarse al entorno. Lo que escribiste trata sobre identificar cuál es tu verdadero trabajo y enfocarte en cumplirlo. ¿Puedes profundizar sobre este paso y sus subpasos?

Aakash Gupta: Sí. Me parece increíble ver los tipos de entregables que creé en cada trabajo de PM y los que mejor recibieron. Eran completamente distintos. En Epic Games, básicamente eran propuestas de funcionalidades cool.

A veces me quedaba hasta las 2am creando, con diseñadores, un demo jugable de la funcionalidad, aunque gráficamente fuera borroso. Eso era lo que funcionaba allí. En Affirm, como conté antes, lo que funcionaba era llegar con un roadmap y un modelo de impacto muy detallado, con hojas de cálculo y todo tipo de modelos de proyección. Totalmente opuestos, ¿verdad?

Así que necesitas investigar cómo se mide el éxito en gestión de producto en tu entorno. Recomiendo entrevistar a quienes han estado más tiempo como PMs en tu empresa. Es una gran fuente. También quienes han sido promovidos recientemente. Dos buenos focos.

No te quedes en lo superficial. Recomiendo invitarles a comer, a conversar cara a cara sin pedirles nada inmediato; quizá primero ofrece algo de valor. Una vez que haya confianza, ya puedes preguntar cosas como: ¿Redactas un PRD para cada funcionalidad? ¿Me puedes compartir tu mejor PRD? ¿Tu paquete de promoción? ¿Las notas de tus últimas reuniones uno a uno con tu manager? Preguntas muy tácticas, pero que no puedes hacer si no tienes una relación de amistad.

Hazte su amig@ primero. Quizá un mentor también, pero sin pedir explícitamente que lo sean. Muchos líderes quieren ver que los PMs tienen autonomía. Lo verán como que eres investigador y quieres triunfar.

Y luego, igual que con tu producto, cuando entras a un nuevo trabajo, entrevistas clientes, no clientes, rivales y colegas. Te recomiendo tener una charla uno a uno con tu tech lead, engineering manager, diseñador, investigador de usuarios, analista y tu jefe y jefe de jefe, para aclarar responsabilidades.

Sé muy explícit@. Pregunta al diseñador qué piensa de que un PM haga maquetas. La mayoría dice que no quiere que sea en Figma, pero igual aceptan bocetos. Hay que conocer esas sutilezas. Entiende a tus stakeholders particulares.

Un error es asumir el trabajo de PM de otro equipo será igual al tuyo. Pero diseñador, ingeniero y analista de tu equipo tendrán expectativas diferentes. Mucha gente quiere subir la montaña del liderazgo de producto para llegar a vicepresidente.

Pero concéntrate solo en el escalón siguiente y en el círculo cercano, creando una especie de contrato. Cuando tengas ese entendimiento, puedes probar qué funciona bien y qué no. A veces, el engineering manager no sabe que su equipo disfruta ir a llamadas con clientes. Lo descifras en la práctica. Así que mantente atent@ a tu pequeño grupo. Es consejo básico de carrera, pero aquí aplica porque se trata de entender el rol de PM. Ningún trabajo de PM es exactamente igual.

Hannah Clark: Parecería que en cualquier entorno laboral, con quienes más trabajas creas una microcultura. Es importante entender las sutilezas de esa cultura, qué lenguaje se maneja, que las expectativas estén alineadas, y lo agradezco mucho.

Eso está conectado a tu recomendación de tener citas uno a uno con quienes han tenido éxito en el puesto durante tiempo.

El siguiente paso en tu trayectoria es crear una ruta de promoción. Y esas personas son claves en ese paso. ¿Puedes contarnos de esa estrategia para trazar ese roadmap de carrera?

Aakash Gupta: Si piensas en la fábrica de funcionalidades, suele haber un conjunto de criterios bastante consistentes que debes cumplir. Estos criterios a menudo no se dicen ni escriben y tu propio jefe puede interpretarlos mal. Mucha gente confía solo en su jefe y, a veces, son insistentes con la promoción. Pero no entienden, y debo explicárselo, que yo no soy el único que decide su promoción.

Por ejemplo, en Affirm, yo redacto un paquete y lo entrego a un comité de promoción. Ese comité incluye a toda la dirección de producto en mi nivel y superiores. Y todos suelen opinar algo. Así que tienes que, además de convencerme, convencer a todos los líderes de producto de Affirm en mi nivel o superior para que digan algo positivo de ti.

Hay que relacionarse con ellos y eso es lo que realmente funciona en Affirm. Se trata de entender lo no dicho. Trabajé con PMs en Affirm que tenían problemas para ser promovidos. Una estuvo tres años como senior PM haciendo buen trabajo. Así que empecé a tener reuniones uno a uno con ella aunque no estaba en mi equipo y la promovieron al ciclo siguiente.

Le di este consejo: estuve en tu último comité de promoción y solo tu manager habló por ti. Tu manager no te dio ese dato.

Así que no puedes confiar solo en tu jefe. Hay que formar relaciones con otros managers que estén logrando promociones para su gente. Encuentra esas personas, acércate, sé amig@ primero, trabaja con ell@s en algo colaborativo para que vean tu valor.

Luego pregúntales sobre sus experiencias en comités de promoción. Para mí, los mejores consejos los recibí en persona, tomando una cerveza después del trabajo. Ahí es donde de verdad aprendes lo que ocurre. Much@s ciñen su jornada al horario de oficina y digo que está bien, pero quizá debas cambiar viernes de 4 a 5 pm por jueves o viernes de 8 a 9 pm para esas conversaciones; será más efectivo para investigar cómo logran que promuevan a su gente. Mucha gente me pregunta cómo llegué a VP tan rápido.

La respuesta básica es que supe cómo funcionaban las rutas de promoción en diferentes empresas. En casi todas las que entré, al año o dos me promovían, sumaba gente a mi equipo, tenía más alcance, porque estaba enfocado en ese camino. Y cuando pregunto a colegas si hablaron con alguien sobre esto, a veces ni sabían que existía un comité de promoción.

Ahí hay un vacío de conocimiento. Así que, primero, cubre esas lagunas. Segundo, analiza tus puntos fuertes.

Como PM, todos fallarán en algo: tal vez tu feedback de diseño sea 8 de 10, o tu capacidad para tratar con stakeholders difíciles sea 7 de 10. Así que apóyate en tus fortalezas. Tal vez sea la redacción. Ese era el mío.

Apóyate mucho en ello. Pregúntate cómo crear un informe semanal, o socializar una estrategia de producto con más equipos de los habituales. Usa tus fortalezas contra esos criterios. Yo solía compartir mis textos y estrategias con equipos que podían verse afectados antes de finalizar el roadmap, y eso les llamaba la atención para ver el documento completo, diciendo "hey, este tipo hace buen trabajo de producto". Se trata de aprovechar lo que sabes en base a esos criterios.

Hannah Clark: Es muy inteligente y tan táctico. Aprecio mucho tu método.

El siguiente paso es mejorar prácticas aisladas. Cuando hablas de prácticas aisladas en este contexto, ¿a qué te refieres y cuáles son algunos ejemplos concretos de cómo perfeccionarlas?

Aakash Gupta: Sí, mencioné que, sobre todo en el nivel GPM o superior, esto debe hacerse a nivel organizacional.

Básicamente deberías probar con algunos equipos lo que voy a explicar y demostrar que funciona. Si estás por debajo del nivel GPM, debes pilotar esto en tu equipo propio. Después de probar, en tus uno a uno, que puedes triunfar bajo el contrato de trabajo acordado con tus compañeros de ingeniería, diseño y analítica, llega el momento de decir: "Oye, vamos a ir un paso más allá".

Debes también pedir su feedback y ajustar cosas según lo que digan. Y este es el orden en que recomiendo aplicar ciertas técnicas. He jugado mucho con el orden desde que coachéo y esto es lo que mejor funciona.

Primero, informes de resultados de las funcionalidades. Son poco amenazantes en una fábrica de funcionalidades. Lanzaste una funcionalidad, la pidió el CEO Brian Chesky, pero quiere saber el resultado y por qué. En las fábricas de funcionalidades, muchos líderes sí quieren saber por qué pasó algo.

Muchos PMs solo reportan: "A superó B, así que destaco A", pero eso no es tan impresionante como decir: "A superó B porque..." y ¡boom! De repente influyes en lo próximo a construir. Incluso aunque no lo adopten siempre, tu narrativa influye.

Por ejemplo, en Airbnb, si lanzaste el precio total porque Brian Chesky te lo pidió, vuelve después con resultados. Sabes que la tasa de conversión va a bajar, pero, ¿cuánto? Sabes que el NPS subirá porque la gente tendrá menos sorpresas negativas con precios.

Quizá cuando la gente agrega al carrito y paga sube la conversión. Así que esperamos que la conversión inicial baje pero la final suba. Pero aún no sabemos el impacto en la conversión global. Brian querrá saber esto. Datos en mano: la conversión bajó solo 2% en el mapa, pero en la página de pago subió 6%. Así que el total mejoró 4%. Parece que su idea fue brillante.

¿Por qué sucedió? Profundiza: entrevista a más usuarios, habla con tu investigador. Quizá antes la gente no creía en el precio mostrado. Había un problema de confianza, y ahora se resolvió. Vuelve con ese insight a Brian: lo importante fue resolver el problema de confianza. Así puede preguntarse dónde más la gente no confía en Airbnb y establecer la próxima hoja de ruta. Esta explicación larga busca dejar claro que los informes de resultados de funcionalidades son poco amenazantes y abren camino.

El segundo paso interesante es dimensionar el impacto (impact sizing). Muchos PMs son responsables de resultados pero solo reciben órdenes de qué construir. Así que, cuando te dicen que hagas una funcionalidad, crea el mejor caso posible, usando todos los datos disponibles, de cómo esperas que impacte. Por ejemplo, en thredUP el CEO pensaba que cambiar el programa de referidos iba a aumentar ingresos 5% el mes siguiente. Yo hice los cálculos más optimistas posibles y aun así apenas llegaba a 0,1%. Así se hace evidente si una idea funcionará. Armando un modelo financiero de dimensionamiento de impacto.

Tercero: descubrimiento (discovery). La gente suele ponerlo al principio, pero yo digo que va después de los dos pasos anteriores. Cuando te piden un output, di: "Gracias por el wireframe, VP o CEO. Vamos a hacer un proceso de discovery y te voy a compartir los vídeos de usuarios". Así haces descubrimiento de soluciones, o incluso de problemas. Así pasas de explorer de soluciones a descubrir problemas (3A, 3B).

Cuarto: OKRs. Aquí ya entramos en terreno de GPM. Como principal product manager, no recomiendo implementar OKRs si el resto de la empresa no lo hace. Pero como GPM sí tienen sentido si tus equipos ya hacen discovery.

Mucha gente pone OKRs en segundo lugar, pero no han desarrollado la habilidad de informes de resultados ni dimensionamiento. En esas empresas, los OKRs suelen ser falsos y se incumplen. Creo que le pasa al 90% de las empresas.

Por eso doy este orden tan intencional. Luego, conecta los OKRs con árboles de problemas y soluciones (OKPS tree). Finalmente, estrategias de producto. Todo el mundo asocia gestión de producto a estrategia, pero hasta que no tienes control total sobre el árbol de OKPS, no puedes escribir una estrategia real. Hasta entonces, la estrategia la escribe el CEO. Hasta que estés plenamente empoderado, ahí puedes añadir estrategia de producto.

Hannah Clark: El siguiente paso, por supuesto, es construir tu coalición. Ya hablamos un poco del tema de formar relaciones sólidas con tus recursos de diseño e ingeniería. ¿Tienes algún caso real de cómo esto ha funcionado para ti?

Aakash Gupta: Sí, volvamos a Epic Games. Las relaciones eran clave para cualquier éxito de influencia que lograra. Quería trabajar en el rendimiento de Fortnite.

Piensa que Fortnite es un juego de alta competitividad. Hay quien juega 2,000 horas al año, casi un trabajo de tiempo completo. Cuanto más inviertes, más aprendes. Hay competencia de altísimo nivel.

El problema es que si tienes mala latencia o bajo frame rate, tu techo de habilidad se limita. Y vi en los datos que quienes tenían mal rendimiento (por hardware o internet) tendían a abandonar tras 1,000 o 2,000 horas, vs quienes tenían buenas máquinas y conexión, que seguían 12 mil o 14 mil horas.

Hay gente que sigue jugando Fortnite después de muchos años. Este era mi insight, pero no podía ir directo a los líderes a decir que prioricen el rendimiento. Tenía que ser muy estratégico e influenciar a los ingenieros y diseñadores más respetados, quienes trabajaban jornadas maratonianas.

Jason, quien había creado Call of Duty y ahora estaba al frente de Fortnite, tomaba las decisiones clave y respetaba mucho a ese grupo de ingenieros y diseñadores hipertrabajadores.

Decidí que ell@s debían ser mi coalición. Como tenían tanto trabajo, nadie les daba feedback sobre el impacto de lo que lanzaban.

Ahí encontré mi oportunidad: yo hacía informes de resultados de funcionalidades. Les mostraba datos concretos de cada parche: "Patch 6.4 hizo esto, esto y esto; los francotiradores subieron 8%, las bajas bajaron 6%, los jugadores de bajo elo vencen más seguido a los de alto elo, etc.". Así les motivaba.

También agregaba datos sobre rendimiento: "Quienes tienen latencia de más de 200ms abandonan a tasas récord." Añadir elementos como rifles y coches aumentó la diferencia entre jugadores de baja y alta latencia. Eso les hizo ver la importancia del rendimiento y logramos avances. Así pienso estratégicamente en quiénes pueden estar en mi coalición e invierto en esas relaciones e influencias.

Hannah Clark: Es inteligente en muchos niveles. Construyes relaciones, generas confianza, tu influencia crece casi sin buscarlo. Brillante.

Antes de terminar, quiero repasar algunos errores comunes que ves en los PMs de fábricas de funcionalidades. Ya mencionamos el error de no darse cuenta de que inevitablemente están en ese entorno, pero ¿qué otros errores destacarías?

Aakash Gupta: Hay quizá seis que quiero mencionar. El primero es enfocarse solo en métricas de output. Reciben mi consejo de rendirse a la fábrica, así que solo optimizan por velocidad de story points, cantidad de features entregadas a tiempo, o cuántas menos veces han movido fechas.

Eso también es un error. Todavía tienes que mirar los resultados de todo lo que entregas. No quiero que rendirse a la fábrica signifique dejar de hacer buen trabajo. La fábrica puede ordenarte crear una feature inútil, pero igual necesitas criterio de producto antes de lanzarla.

Esto te ayudará a tomar mejores decisiones de asignación de recursos cuando puedas y a mantener músculo de buen trabajo de producto. Much@s, al llegar a una fábrica de funcionalidades, frenan su crecimiento profesional. "Ben trabajó cuatro años en banca en modo feature factory y ahora es peor PM que antes". Historias así ocurren de verdad. Así que es vital mantener el crecimiento profesional, siempre ligando las métricas y el impacto al usuario de todo lo que lanzas.

El segundo error es descuidar la deuda técnica. Al correr tras features, ignoras el deterioro de sistemas, la experiencia del desarrollador empeora, los tiempos de build se alargan. Y sigues corriendo por la próxima gran entrega. Esto es muy común.

La deuda técnica accidental, es la que llega vía experiencia de usuario y debemos minimizarla. La intencional, la asumida al correr por funcionalidades grandes, está bien si luego corriges algo cuando la funcionalidad madura. El tercer error es ignorar los comentarios de usuarios.

Aunque mencioné mostrar wireframes o cambios, para muchas personas es un gran avance, pero no debería serlo. Pregunto a PMs: ¿cuántos usuarios vieron tu diseño final antes de lanzar la última gran funcionalidad? Y la mitad responde que a ninguno; lanzamos deprisa porque era urgente. Es un error enorme. Aunque estés atrapado en una fábrica de funcionalidades, tu reputación y carrera dependen de lo que entregue tu equipo.

Así que asegúrate de que ese mal producto sea al menos la mejor versión posible de esa mala idea. El cuarto error es dejarse llevar por el FOMO (miedo a perder oportunidades) para definir el roadmap. Es, de hecho, la razón clásica de la feature factory.

Si HubSpot lanza un CRM, nosotros necesitamos otro. Si Typefully permite publicar en LinkedIn, también debemos adaptarnos. Ese miedo a perder clientes. Un gran cliente se va y entonces queremos construir todo para no perder a ningún otro.

Trata de mostrar a tu dirección el alcance real de cada funcionalidad, por eso el dimensionamiento de impacto: "nuestra última funcionalidad nueva es usada solo por el 0,2% de los usuarios, ¿vale la pena crear otra?" Cada vez que veas FOMO en quien dictamina el rumbo, considéralo alerta roja. Tal vez sea momento de desviarte del modelo fábrica.

El error cinco es quemar al equipo. Incluso en entornos empoderados ocurre, pero aunque entregar rápido importa, el mejor equipo, motivado y sano, produce mejores resultados.

Puede que logres 10% de crecimiento con un equipo agotado, pero para llegar al 50% necesitas que funcionen al máximo. Así que, como PM, defiende mejores herramientas, presupuesto para formación y convivios de equipo. Personalmente, suelo pedir reuniones o celebraciones post lanzamiento. Traía brownies a los desarrolladores cuando lanzaban una feature; daba high fives a los diseñadores por buen trabajo. Estas cosas pequeñas cuentan mucho en una fábrica de funcionalidades; no solo el PM está frustrado, también diseñadores e ingenieros.

El sexto error es perder la visión del todo. Nos dan el "qué", el "qué", el "qué"; solemos olvidar el "por qué". Y no solo el "por qué" en métricas o problemas de usuario, sino también la estrategia de producto. Aunque la pongo como el paso final, debes trabajar esa habilidad de estrategia de producto.

Ahora que mencionamos la compresión del campo de PM en los últimos tres, cuatro años, hay menos trabajos que antes; el diseño y la ingeniería de producto crecen, pero a costa de gestión de producto. Si queremos que los PM sobrevivan ante esto, necesitamos que tengan impacto estratégico.

Así que, incluso dentro de la fábrica, aunque te adaptes y apliques las prácticas, siempre habrá ese 10–15% del roadmap que puedes influenciar. Ese 10–15% del sprint donde te dejan opinar. Sigues siendo parte del equipo aunque estemos entregando como una factoría. Procura que esas funcionalidades sean ultra estratégicas. Los mejores PMs que conozco en feature factories, en Epic o Affirm, cada vez que logran lanzar algo propio, cambian la trayectoria de la empresa.

Quizá no pueden hacer mucho, pero cuando lo hacen, es revolucionario. Por ejemplo, en Affirm, uno de esos PMs lanzó una funcionalidad de ML para ordenar préstamos a pagar, un backend sofisticado que mejoró la tasa de pago un 15%, dándole a Affirm una ventaja líder de mercado. Eso es lo que debe motivarte. Si estás atrapado en la fábrica de funcionalidades, después de escuchar 45 minutos sobre el tema, intenta tener esas ideas geniales de funcionalidades propias y cuélalas donde puedas.

Hannah Clark: Es el gran remate final. Aakash, muchísimas gracias por dedicarnos tu tiempo. Para las cinco personas que aún no te siguen, ¿dónde pueden encontrarte online?

Aakash Gupta: Lo ideal es el boletín. Estoy en Substack. Sé que a algúna gente no le gusta la ventanita de email.

Puedes simplemente hacer click en ignorar y seguir leyendo si lo prefieres. Hoy, en mis textos, hablo con más de 10 personas. En el último tuve colaboradora invitada. Cada un@ entrevistó 10 personas; logramos datos reales. No es contenido de producto básico como los que posteo en LinkedIn o X y piensas que tengo contenidos estándar. No, son estudios de casos con personas reales.

Para la búsqueda de trabajo de líderes de producto, hablamos con líderes que consiguieron puestos de VP o director recientemente. Hablamos con reclutadores que colocan en la industria. Intento aportar datos y visión real. Si te interesa, en eso estoy trabajando y ahí puedes encontrarme.

Hannah Clark: Estupendo. Nos vemos allí. Gracias por estar aquí.

Aakash Gupta: Gracias, lo aprecio mucho.

Hannah Clark: Gracias por escucharnos. Para más insights, guías prácticas y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes oír más conversaciones así suscribiéndote a The CPO Club dondequiera que escuches tus pódcast.