¿Todos los caminos llevan a la fábrica de funcionalidades?

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 100% preciso.

Hannah Clark: Fábrica de funcionalidades—sustantivo; una empresa que lanza de manera constante productos, características y mejoras, pero que se centra principalmente en la cantidad y no en la calidad. Origen, John Cutler. Usado en una frase: "Hemos lanzado tres funciones nuevas este trimestre y no sé para quién son. Esto empieza a parecerse a una fábrica de funcionalidades". Si esa definición te resulta demasiado familiar, sigue escuchando.

En nuestro reciente evento de panel, "¿Todos los caminos llevan a la fábrica de funcionalidades?", reunimos a tres líderes de producto que han observado este fenómeno desde diferentes perspectivas. Aakash Gupta—quien fue VP de Producto en un unicornio y actualmente es autor del boletín 'The Product Growth Newsletter', Andrea Saez—líder de marketing de producto y autora de 'The Product Momentum Gap', y Paweł Huryn—autor de 'The Product Compass Newsletter'.

Ellos comparten la incómoda verdad sobre reconocer el pensamiento centrado en producción en lugar de resultados, marcos prácticos para mantener el enfoque estratégico ante las presiones del mercado medio, y marcos accionables para transformar tu equipo de constructores de funcionalidades a generadores de resultados.

Ya sea que intentes escalar más allá de los cien millones de ARR o simplemente recuperar el espíritu innovador de tu equipo, considera esta conversación como tu pase de salida de la mentalidad de fábrica de funcionalidades. Vamos a ello.

Por cierto, organizamos conversaciones como esta cada semana, así que si esto te interesa, ¿por qué no te suscribes? Bien, entremos en materia.

Vamos a comenzar con nuestra discusión, observando algunos números preliminares de la encuesta. Parece que tenemos una división bastante pareja entre personas que consideran que sus organizaciones son fábricas de funcionalidades y otros que realmente no lo tienen claro. Así que hablaremos de esto definiendo el término.

Creo que ayudará a todos estar en la misma página respecto a qué queremos decir cuando hablamos de fábrica de funcionalidades. La definición que usamos, creo que se toma de John Cutler, quien acuñó el término originalmente. Así que, una fábrica de funcionalidades es una empresa que lanza productos, funciones, mejoras, etc., de forma constante, centrándose principalmente en la cantidad y no en la calidad.

Se enfocan en la producción más que en los resultados. Lo que insinuamos aquí es que estamos en una situación donde lanzamos muchas funciones, pero no siempre está claro si estas características tienen realmente un valor empresarial sólido o si realmente resuenan con nuestros usuarios.

Obviamente, esto puede estar ligado a algunos problemas. Cubriremos esto en tres secciones. La sección uno será por qué una fábrica de funcionalidades es tan prevalente. Luego pasaremos a la sección dos, que son los caminos para salir de la fábrica de funcionalidades. Y la sección tres, que es: estamos en modo fábrica, ¿y ahora qué?

Empezaremos con la sección uno. La primera pregunta la pasará primero a Andrea. ¿Cómo las organizaciones bien intencionadas se convierten en fábricas de funcionalidades? ¿Cómo se desarrolla esto?

Andrea Saez: Para ser honesta, no hay un solo camino. Mucha gente me pregunta: ¿cómo lo evito? ¿Cómo lo evito? Hay varios caminos que te pueden llevar hacia allí.

Todo, desde simplemente intentar cerrar ventas, tal vez no tienes un buen líder de producto, o jefe de producto, o VP de producto, lo que sea. Puede ser un tema de “hiPPO” (highest paid person's opinion), puede ser el síndrome del objeto brillante. Hay muchas formas diferentes de llegar allí, pero creo que el problema subyacente, digamos fundamental, sería la falta de influencia de un líder de producto para poder establecer realmente una estrategia y decir: esto es lo que estamos haciendo, por esto lo hacemos.

Y también poder negociar cuándo tienes que lanzar una función por ciertas razones, pero luego ser capaz de reconducir al equipo hacia la estrategia. La realidad es que, aunque me encantaría decir que nunca vamos a hacer eso, puedo, absolutamente, evitar una fábrica de funcionalidades.

Hay momentos en la carrera de todos, en el camino de toda empresa donde hay que hacer concesiones y decir: está bien, tendremos que construir esa función porque tenemos que conseguir esos ingresos, necesitamos el dinero. Así que no es una situación simplemente blanca o negra.

Hay negociaciones y concesiones que deben hacerse, pero lo importante es tener a un líder de producto que pueda decir: ok, ya hicimos eso. Ahora volvamos a nuestra estrategia, a lo que realmente intentamos hacer y resolver.

Hannah Clark: Aakash, ¿quieres agregar algo? Sé que compartiste una perspectiva antes que inspiró esta conversación, aquello de que parece que todos los caminos llevan a la fábrica de funcionalidades. ¿Cuál ha sido tu experiencia en el campo?

Aakash Gupta: Sí, creo que solemos decir: ok, existen estas empresas geniales allá afuera. Están en Silicon Valley, Google, Netflix, Meta, y simplemente hacen bien los productos. Y si tú simplemente haces producto como ellos, todos tus problemas se resolverán. Alcanzarás tus métricas, tu negocio tendrá éxito y crecerás en tu carrera. Y luego la gente sigue ese consejo y rápidamente se da cuenta de que.

Parecen haber algunos vacíos aquí. Y el vacío número uno que he visto es que cuando voy y hablo con PMs que trabajan en esas empresas y les pregunto, “¿cuál fue la mayor función que lanzaste el último trimestre?” Ellos me dicen: “Ah, sí, fue X y Y”. Y yo digo: “¿Cuál fue la etimología de esa función?”

¿Cómo se decidió desarrollar esa función? ¿Quién la ideó? Invariablemente, en esas grandes tecnológicas, todas las funciones relevantes fueron decididas por el equipo ejecutivo. Fueron debatidas durante seis meses antes. No hubo el clásico descubrimiento del PM donde el PM hablaba con usuarios en una continua investigación cada dos semanas, y surgía con esta solución brillante que ningún ejecutivo en Google o Meta había imaginado, cambiando el rumbo de la empresa.

Eso no pasa nunca y, por tanto, creo que hay una sobre-glamorización de lo que realmente ocurre en esas empresas y en ciertos lugares, específicamente lo llamaría como Apple, o incluso Snapchat. El CEO de Snapchat, Evan Spiegel, estuvo en un montón de pódcast recientemente. Hay un par de diseñadores y el CEO que dictan todo.

Es como una pura fábrica de funcionalidades. Y creo que probablemente se sobrevalora esto y, en realidad, muchos caminos sí llevan a un entorno tipo fábrica de funcionalidades. Si no es todo el tiempo, como Andrea enfatizaba, al menos parte del tiempo puede haber demanda por ventas, una exigencia del éxito del cliente, algo.

Así que todos tenemos que aprender cómo manejarnos cuando estamos en esa situación de fábrica de funcionalidades.

Andrea Saez: ¿Puedo ser algo polémica, ya que me pidieron ser polémica antes de la llamada? Estoy 100% de acuerdo con todo lo que dijo Aakash, pero una cosa que creo que es muy importante entender es que esas empresas que él mencionó, muy acertadamente, tienen el presupuesto para hacer esas cosas.

Pueden lanzar para aprender o lanzar, simplemente para ver qué pasa porque pueden reabsorber ese riesgo. La mayoría de las empresas no tienen ese presupuesto. Así que cuando intentan operar como Google o Apple o quien sea y dicen: “Vamos, lánzalo”, ¿recuerdan aquel lema de Facebook “Muévete rápido y rompe cosas”?

Lo peor que puedes hacer porque no eres Facebook. Seamos realistas con eso. La mayoría no trabaja en un FAANG y, si sí, están en la situación que Aakash describe, pero pueden darse ese lujo. Yo no, así que tengo que jugar un poco más inteligentemente.

Hannah Clark: Ok. Creo que ya tenemos una visión de cómo se desarrollan estos escenarios, quién puede permitírselo y quién no.

Si lo vemos en un espectro de bueno a malo, ¿es ser una fábrica de funcionalidades intrínsecamente malo, o a veces puede funcionar dependiendo del modelo de negocio? ¿Dirían que hay una alternativa realista y viable?

Paweł Huryn: Sí, no estoy totalmente de acuerdo con la idea de que siempre hay que hacer concesiones al hablar con los interesados sobre características, implementarlas o revisar sus solicitudes, porque hay problemas que no requieren mucha discusión. Si recibimos una solicitud de los interesados de, por ejemplo, integrar Stripe.

Entonces necesitamos la integración. Por supuesto, podemos tratar de traducirlo y replantearlo como un problema financiero, pero en algunos casos, descubrir el área problemática no es tan necesario. En otros casos, los interesados como ejecutivos o ventas o éxito del cliente pueden tener información que el product manager hablando con usuarios puede perderse.

Así que tampoco me gusta descartar completamente esas ideas. He visto a muchos PMs que llegan nuevos a una organización y empiezan a entrevistar a usuarios, sin saber que muchos interesados llevan cientos de horas hablando con clientes cada mes. Así que ignorar lo que saben me parece un desperdicio.

Y además, al final del día, los negocios tienen que ganar dinero. Así que, para algunas empresas, si trabajan en un modelo cliente-proveedor, satisfacer lo que pide el cliente, incluso si al equipo de producto no le entusiasma, es una forma viable de ganar dinero. Así que en ese caso, puedes elegir dejar la empresa en vez de tratar de cambiarla, porque ese es su modelo de negocio.

Hannah Clark: Sí, es un punto válido. Ese es el otro lado: si mantiene vivo el negocio, a veces así es como toca.

Volvemos con Andrea. Vamos a la sección dos, que son los caminos para salir de la fábrica de funcionalidades. Así que dejamos la pregunta moral y vamos a evaluar si una organización sobre-invierte en el corto plazo y desatiende el valor a largo plazo. ¿Dónde está ese equilibrio?

Andrea Saez: Creo que lo primero que lo revela es si recibes mucho feedback negativo: alta tasa de cancelación, ciclos de ventas más largos. Son indicadores de que probablemente estás perdiendo el ajuste producto-mercado. Esa suele ser la señal cuando empiezan esas decisiones de “solo lanzamos esto para salvar una cuenta” o cerrar un trato, y ahí es cuando todo se descontrola. Y empiezas a ver, no voy a nombrar ciertas herramientas, Jira. Sí, conoces eso, tienes todas esas funciones, pero ¿están conectadas?

¿Tiene sentido para tu público? ¿La UX tiene lógica? Por el amor de Dios, Jira, ¿qué estamos haciendo? ¿La gente puede navegar fácilmente por la UI, etc.? Pero, en general, es cuando ves que el ajuste producto-mercado empieza a diluirse y ya no es tan sólido como antes.

Hannah Clark: Hablemos sobre intervención temprana. Si empezamos a desviarnos, ¿qué controles y equilibrios podemos implementar? Sabiendo que hay niveles limitados de influencia en ciertos puestos de gestión de producto—depende de la madurez de la empresa, hay muchos factores—, pero supongamos que tienes influencia significativa, ¿qué intervenciones tempranas o controles puedes implementar para centrar la entrega de valor y que la visión de la empresa se mantenga clara?

Paweł, ¿quieres empezar?

Paweł Huryn: Comenzaría alineando la estrategia en toda la organización. Si los equipos no concuerdan en cómo creamos valor, qué clientes necesitamos atender, qué problemas queremos abordar, qué nos diferencia, entonces puede ser complicado entregar valor consistentemente.

Así que primero es el alineamiento estratégico y las decisiones que tomamos para que todos sean conscientes del contexto. Esto es lo que, en “No Rules”, Netflix llama “contexto, no control”. El siguiente paso es alinear equipos alrededor de los objetivos, para que todos entiendan qué es lo más importante para la organización ese trimestre o ese año, y que se alineen objetivos del equipo o departamento con las principales prioridades. Luego existe el empoderamiento, que puede requerir entrenamiento, porque no todo equipo de producto sabe cómo hacer un descubrimiento continuo.

En líneas generales, salvo excepciones, queremos empoderar a los equipos con problemas significativos que resolver, con resultados claros, de modo que puedan descubrir cómo resolver esos problemas, crear valor para los clientes y, en definitiva, para el negocio.

Eso sería. Comenzando desde la estrategia y terminando empoderando equipos para que inicien ese proceso de descubrimiento.

Hannah Clark: Algo relevante para sumar: recientemente conversé con Cem Kansu, CPO de Duolingo, sobre cómo piensan en visión y valores. En su empresa hay “vacas sagradas” que han acordado no tocar o modificar, porque son la esencia de quienes son; eso sirve de brújula para sus decisiones y para lo que deciden descartar.

Me pareció un enfoque interesante.

Paweł Huryn: Sí, esos temas son esenciales. No sólo en lo que queremos enfocarnos, sino también en lo que no vamos a hacer, los clientes que no vamos a atender, las estrategias que no implementaremos, para que todos lo tengan claro y las eviten.

Hannah Clark: Antes de avanzar a la sección tres, ¿los panelistas desean sumar controles o intervenciones tempranas para evitar el modo fábrica de funcionalidades?

Aakash Gupta: Fábrica de funcionalidades es un término peyorativo, nadie quiere estar ahí, pero si revisamos los elementos más destructivos, el problema número uno en un negocio es no enfocarse en lo que realmente importa. Conseguir que el equipo directivo se concentre en las métricas y problemas de usuario clave tiene el mayor impacto.

Se trata de aportar ideas que refuercen tu credibilidad. Pienso en dos tipos de insights que debes traer a la mesa con los ejecutivos: insights de usuario—idealmente grabaciones de sesiones, análisis de usuarios, conversaciones grabadas—y datos duros: por ejemplo, saber que el 16% de tus clientes no hace X y si logras que el 50% lo haga podrías generar millones en ingresos. Si llegas con esos datos, podrás orientar el enfoque sobre las métricas y problemas correctos.

Eso es lo primero, lo estratégico. Después, debes permitir que los equipos—los diseñadores, PMs, etc.,—puedan iterar y cambiar el rumbo de lo que los ejecutivos tienen en mente, mientras prototipan y muestran maquetas a usuarios reales. Para eso sirve implementar reuniones de revisión de producto; que los directivos se sientan partícipes. No quieres que te den un diseño y que, tres meses después, les devuelvas un reporte de fracaso y te echen la culpa de no implementar “su” diseño. Invítalos al proceso: “tu diseño lo testeamos, lo mejoramos por X y Y y lanzamos eso”. Esos son mis dos puntos de palanca: táctica sobre la estrategia que mencionó Paweł.

Hannah Clark: Muy valioso. ¿Alguien desea comentar?

Andrea Saez: No creo que pueda sumar nada más. Estoy completamente de acuerdo, no seré controversial aquí. Sólo diría que, mientras alineas, te asegures de que haya alineación real. Veo muchos equipos fallar porque dicen sí, y una semana después cada quien hace lo suyo. Necesitas alineamiento ejecutivo, debe comenzar arriba. Todos deben saber qué, cómo, por qué y para quién están construyendo. El “para quién” suele ser origen de desalineación: si todos quieren vender a públicos distintos, acabas con funciones que no encajan.

Hannah Clark: Sobre el desarrollo cortoplacista de funciones: ¿es cierto que a veces las empresas lanzan funciones desconectadas de la visión con la intención de volver y perfeccionarlas, pero al entrar en el espiral de fábrica ya nunca lo logran, acumulando “deuda de funcionalidades”? ¿Alguien quiere responder?

Paweł Huryn: Supongo que la pregunta es sobre lanzar funciones que no son ideales. En mi experiencia, eso es exactamente lo que deberíamos hacer.

Lanzar funciones sin todos los detalles, sino que resuelvan el problema para el 70% u 80% de los usuarios y recoger feedback. Por supuesto, a veces no se puede, pero en la mayoría de empresas donde trabajé hicimos así. Incluso si había una idea sobre qué lograr en cinco meses, rápidamente escuchábamos al usuario y mejorábamos los supuestos iniciales, porque lo que ocurre en producción puede variar mucho de los tests de usabilidad o las entrevistas previas. Así que 100% a favor de lanzar sin perfección.

Hannah Clark: Andrea, ¿cómo encaja eso con la estrategia? Mencionaste que en tu organización necesitas ser más estratégica. ¿Tienes un enfoque distinto?

Andrea Saez: No, coincido con Paweł. Hay que lanzar con intención. No todo necesita ser perfecto. No quiero asumir, pero Todd dijo “a medio cocinar”, y lo he visto: lanzamos algo y decimos luego lo mejoramos, pero el equipo sólo pasa a lo siguiente. Eso es la trampa de la fábrica; lanzamos lo nuevo y nunca volvemos para mejorar lo básico, asumiendo que el usuario lo entenderá.

Aakash Gupta: Sí, todos los comentaristas tienen razón. Brent y Todd apuntan a esto: por eso es tan mala la fábrica de funcionalidades, caemos en el síndrome del objeto brillante y dejamos funciones a medias, nunca las optimizamos aunque sepamos qué falla porque estamos ocupados con lo nuevo. Para salir de esto, hay que llevar esos insights (“miramos 100 grabaciones, solo 3 personas usaron esto; la retención es 7%”) a los ejecutivos de la fábrica, hablarles en su idioma. Con datos así, te permitirán iterar; si la adopción es 7%, hay que lograr que el usuario vea la función y arreglar problemas de retención. La otra opción, que a menudo se necesita de verdad, es eliminar funciones: hay demasiadas que obstaculizan la tarea central del usuario. Esto se da mucho en B2B, queriendo ser “plataforma” apenas llegamos a X millones de ARR. Enfocarse en lo esencial suele ser más impactante.

Andrea Saez: Creo que fue Pendo quien estudió que el 80% de las funciones no se usan. Es una barbaridad.

Hannah Clark: Es increíble.

Creo que eso nos lleva a la última sección: estamos en modo fábrica, ¿y ahora qué? Muchos se unen hoy porque ya trabajan en lo que consideran una fábrica o temen estar acercándose a ello.

Supongamos que cambiar el modelo ahora mismo es imposible o muy difícil debido a la infraestructura y cultura actual. ¿Qué pasos podemos tomar desde el liderazgo para regresar a una mentalidad enfocada en valor?

Aakash Gupta: Si eres líder, recae sobre ti. Si eres el VP de producto, el chief product officer, el que sea, tu trabajo es señalar todas las deficiencias de tu organización, los problemas a solucionar. No es presumir: “¡qué bien lo hacemos!” No, es resolver los problemas. Así que deberías identificar los grandes problemas y la fábrica de funcionalidades es uno que suele resonar. ¿Qué hacer? Preguntar: “¿Cuál fue tu estrategia el año pasado? ¿Qué funciones prometimos construir y cómo resultaron? ¿Cuántas tuvieron éxito?” Si 75% fracasaron, ¿queremos repetir eso este año?

Y entonces, ¿cómo cambiarlo? ¿Cómo desmenuzar el problema? Así hablas en el lenguaje de los interesados, no solo diciendo que Marty Kagan dice que tienes que empoderar a tus PMs. Sí, Marty tiene razón, pero tú debes aplicar ese aprendizaje a tu contexto, traduciendo eso para el stakeholder. Ese es el trabajo de un buen VP. Y como Andrea dijo al principio, muchas veces lo que llevó a la fábrica fue la ausencia de un buen VP o CPO.

También diría que a veces los fundadores—especialmente—o algunos CEOs, son difíciles y, aunque haya un gran VP, al final el CEO impone sus cosas. En ese caso debes pensar estratégicamente en tu carrera y tal vez buscar otro lugar donde sí puedas hacer impacto.

Andrea Saez: Iba a decir exactamente eso. Puedes ser el mejor CPO o VP, intentar hacer todo correcto, pero si no tienes el apoyo del CEO y el resto del nivel C, no llegarás lejos. Debe haber alineación arriba: si la hay, todo es mucho más fácil.

He trabajado con CPOs sin influencia, donde ventas dirigía el producto, no el CPO. Lo otro que sumo es alinear y entender los comportamientos de usuario medibles—y esto es en parte de mi libro—muchas funciones que se construyen no se centran en hábitos repetibles y escalables. Muchos lanzan solo por lanzar, pero ¿realmente aportan valor al cliente?, ¿les ayudan?, ¿o dificultan la vida? Quizá haya que hablar también de ética: cómo impacta en la vida y flujos del usuario.

Paweł Huryn: Estoy de acuerdo con todo lo dicho.

Desde la perspectiva de un manager o equipo de producto sin gran influencia, también es posible mover cosas en la dirección correcta. Obvio, no cambiarás toda la organización, pero yo, por ejemplo, trabajé en BC, un centro de recursos para más de 30 bancos daneses. Mi iniciativa fue la única que escapó a SAFe (“Scaled Agile Framework”), que para mí es como waterfall con planificación a largo plazo. ¿Cómo? Analizamos iniciativas previas, señalamos los problemas y medimos los resultados actuales. Así, como CPO pero desde mi nivel. Sugerimos un experimento: que nuestro equipo central y cuatro más colaboraran de manera ágil, sin el marco pesado. Y funcionó. No cambiamos toda la empresa, pero sí para mi iniciativa.

Hannah Clark: Aprecio esa perspectiva de quienes tienen menos influencia: muchos estarán en ese punto y buscan lograr impacto.

Paweł Huryn: También se pueden cambiar muchas cosas dentro del equipo, sin pedir permiso: colabora con diseñadores, invita a ingenieros a idear soluciones, no prepares todo solo ni entrevistes clientes en solitario.

Andrea Saez: Quiero añadir algo sobre lo duro que es. Me sorprendió lo que Paweł contó, porque requiere mucho trabajo y normalmente en mi carrera hago como Aakash y decido que mejor busco otro empleo. Pero sí, es difícil hacer esa transformación.

Así que poder para quien lo logre o siga en ese camino, porque es agotador para el bienestar personal y mental. Pero, si lo logras o sales de ello, aprendes mucho.

Hannah Clark: Sí, sin duda te aporta experiencia para tu siguiente etapa, sigas o no en la empresa.

Si quieres seguir a nuestros ponentes, cada uno es un referente. Andrea tiene su libro “The Product Momentum Gap” en Amazon. El boletín de Aakash, “The Product Growth Newsletter”, suscríbete porque es un recurso fantástico.

Y el boletín de Paweł se llama Product Compass. Aakash y Paweł han colaborado en algunos pódcast, pero Aakash es muy activo con el suyo. Por favor, sigue a nuestros panelistas, que siempre comparten contenido de valor.

Creo que podemos pasar al Q&A. Tenemos grandes preguntas de la audiencia. La primera, de Aqueda, espero pronunciarlo bien.

¿Cómo pasamos de fábrica de funcionalidades a creación continua de valor para usuarios y clientes generando impacto positivo en el negocio? Hemos tocado el tema, pero quizá hay algo más que aportar.

Señala que el valor al cliente parece haber sido ofuscado por la búsqueda de resultados rápidos. Andrea, si puedes resumir lo que cubres en el libro, sería útil.

Andrea Saez: Es literalmente eso. Se trata de unir la estrategia de producto y el valor para el cliente. Hablamos mucho sobre el valor al cliente, cómo identificarlo, seguirlo, enfocarse y unir al equipo en torno a él, y eso es fundamental.

Tenemos una plantilla llamada “product VCP” o plan de creación de valor. Lo importante, como dijo Paweł, es que no se decide en aislamiento; hay que escuchar ventas, éxito del cliente, soporte y reunir a todos los interesados en un taller colaborativo para entender qué es valor y cómo entregarlo.

Hannah Clark: Por si quieres una muestra, discutimos justo eso en el pódcast hace un año: “How product leaders are unintentionally hindering business growth”.

Bien, siguiente pregunta de Parker: ¿Qué herramientas/métodos usas para fomentar discusiones estratégicas y alineamiento en torno a un objetivo común de producto? ¿Qué te ha sido más eficaz? Es algo más táctico. ¿Alguien quiere empezar?

Aakash Gupta: Si intentamos crear alineamiento sobre un objetivo, lo primero es no imponer la respuesta correcta, sino plantear el contexto y preguntar: “¿Podemos identificar juntos el objetivo correcto?” Invita a personas clave y, si puedes, colabora con alguien bien respetado por ambas partes—un analista o un externo—para presentar un informe o investigación. Así todos aprenden y pueden cuestionar, visualizan métricas y opciones, y, como PM, recopilas los pros y contras. Luego, vuelves al “tercero imparcial” (el data science team) para más insights. Finalmente, sin tener la respuesta fijada, decides juntos. Es un proceso lento, pero ayuda al compromiso.

Hannah Clark: Siempre das procesos claros y útiles. Gracias por eso.

Pasamos a Mikayla: el negocio y el equipo UX piden una renovación de producto; quieren entender bien los puntos de dolor y los journeys, pero hasta ahora ha sido una fábrica y está desconectado porque usamos muchos sistemas para coser la UI y el PM sólo quiere velocidad porque según él “ya sabemos”, pero no hay dirección clara. ¿Cómo salir de ahí?

Situación concreta: hay insights fragmentados, la construcción no está alineada con ellos y el PM no hace conexión.

Paweł Huryn: En este caso es el PM quien presiona para lanzar sin validación. Puede ser difícil, pero trataría de indagar sobre el problema real que busca resolver esa función y validar tanto el problema como las posibles soluciones. También verificaría si ese problema se alinea con los objetivos organizacionales y la visión de la empresa. Quizás alguien del equipo, aunque no sea el PM, pueda indagar o encontrar inconsistencias entre análisis de datos y las funciones que se están construyendo. Todo parte de ciertas suposiciones; intentaría validarlas.

Andrea Saez: Coincido. Hay dos preguntas mágicas: ¿qué problema estamos resolviendo y por qué? Y, además, ¿para quién? En una situación así, el equipo sólo quería lanzar convencido de que “ya sabían”, y yo, como marketer, pregunté: “No quiero molestar, solo entender el problema y la lógica detrás de la decisión, porque yo tengo que vender esto y necesito saber el valor”. Así logré que pasaran por el proceso lógico. Puedes usar un esquema de problema/producto y preguntar: ¿qué problema? ¿por qué? ¿para quién? ¿impacto en el negocio? ¿valor para el cliente? Eso puede orientar el barco y hacer que el equipo piense el porqué.

Hannah Clark: Buena sugerencia. Seguimos con las preguntas. Brent pregunta: ¿En un mundo ideal, una empresa debería ser menos fábrica de funcionalidades al madurar? ¿Puede esa tendencia ser señal de una mala organización de los equipos de producto?

Andrea Saez: ¿Opiniones? Hannah, quiero tu perspectiva.

Hannah Clark: Soy “outsider” aquí, pero creo que una empresa debería ser menos fábrica al principio, con un objetivo claro para un problema definido. Me parece que la fábrica surge conforme la empresa escala y se hacen concesiones para sobrevivir. Así que creo que es algo con lo que se topará cualquier organización que escale. Pero debo decir que nunca he vivido eso en primera persona, así que fact-check, por favor.

Aakash Gupta: Creo que hay una proporción similar en todas las etapas. A veces, en etapas iniciales, la gente piensa que solo hay que copiar otro producto: “solo construye esto, todo está claro”. Eso es fábrica. Así que puede ocurrir en cualquiera. Lo importante es preguntarse qué partes de la fábrica te afectan hoy. ¿Estás generando el ROI mínimo para justificar tu sueldo? Si no, la fábrica es un problema y hay que ir atacando área por área. Sociológicamente, creo que ocurre en todos los tamaños, incluso en grandes empresas como Meta, o empresas de Series A y C, o incluso OpenAI; a todos los niveles encuentras ese fenómeno, probablemente en más del 50% de los casos.

Hannah Clark: Pasamos a Sahi. ¿Qué aporta un PM de background híbrido negocio-técnico versus uno puramente técnico en cuanto a funciones y diseño?

Andrea Saez: Creo que hay relación: en mi experiencia, PMs puramente técnicos suelen carecer de enfoque de negocio. Al final, todos construimos para vender. No digo que debamos ser solo ROI, pero tener presente la necesidad de vender lo que se construye y cómo impacta las decisiones es esencial. Los PMs con background de negocio lo tienen claro y toman decisiones basadas en eso, mientras que los más técnicos se enfocan en la parte técnica y a veces olvidan la rentabilidad. He estado en proyectos donde presento la pregunta “¿cómo vamos a vender esto?”, y nadie lo había pensado. Es clave saber a quién vendes y cómo el desarrollo está preparado para el journey del cliente, porque un cliente enterprise no tiene el mismo problema que una startup. Y si no tienes ese bagaje de negocio, tal vez no haces esas preguntas. Puede que me equivoque, así que corríjanme si es necesario.

Hannah Clark: ¿Alguien desea agregar?

Aakash Gupta: Creo que solo está preguntando—seguramente tiene ambos perfiles—qué valor añade frente al técnico. Hoy hablamos mucho de impacto. Si tienes bagaje de negocio, usa esas fortalezas: modela el crecimiento de tu equipo, mide el impacto, escribe reportes detallados de resultados. Aprovecha tus puntos fuertes y no te preocupes tanto por lo que otros saben o no. Los PMs técnicos pueden aprender habilidades de negocio, no es difícil. Haz más de lo que sabes hacer bien. El puesto de PM es flexible y puedes personalizarlo.

Andrea Saez: 100% de acuerdo.

Hannah Clark: Todd dice: Paweł, mencionaste que te gusta mantener todos los insights. ¿Cuándo los conviertes en items reales del backlog? Nuestro backlog parece el piso de la fábrica. Recomendamos archivar items de más de 12 meses. ¿Qué opinas?

Paweł Huryn: Primero, no estoy seguro de si dije “guardar todos los insights”, pero sí de aprovechar información de varias fuentes: entrevistas, stakeholders, investigaciones, data, encuestas.

Para organizar insights y backlog, siempre trato de no poner historias de usuario ni funciones en el backlog de desarrollo antes de tiempo. Primero hago el discovery, comparto los diseños, testeo hipótesis clave, comparto hallazgos y sólo cuando hay confianza los divido en historias y tareas. Es como tener dos backlogs (no tiene que ser en la misma herramienta; puede estar en Miro o en lo visual). Cuando llega el momento de archivar, suelo eliminar o archivar todos los items antiguos porque si el backlog pasa de 80 o 100 elementos, es inmanejable. Si son importantes, volverán a surgir.

Hannah Clark: Gracias a todos por participar. Un enorme agradecimiento a los panelistas por su tiempo: Aakash, Andrea y Paweł. Fue muy divertido e informativo. Muchas gracias por participar y ser una audiencia tan comprometida. Esperamos verlos la próxima vez.

Gracias por escuchar. Para más recursos, guías y análisis de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más conversaciones como esta suscribiéndote a Product Manager donde sea que escuches tus pódcast.