¿Está la falta de claridad matando silenciosamente tu producto?

Lee la transcripción:

Estamos probando transcribir nuestros podcasts con un programa de software. Por favor, disculpa los errores de tipeo, ya que el bot no es 100% preciso.

Hannah Clark: Es prácticamente un tópico, pero sucede todo el tiempo: dices algo a tres personas y cada una entiende algo diferente. Y eso no está tan mal si lo que dices es "Voy a por un café, ¿alguien quiere algo?" Pero cuando estás construyendo un MVP con una pista que se acorta cada vez más, o intentando lanzar algo dentro de un plazo estricto, esa falta de claridad puede ser la sentencia de muerte para una startup.

La invitada de hoy es Bijan Shahrokhi: es el fundador de Product Management Exercises y Product Monkey AI. Bijan ha dedicado la última parte de su carrera a ayudar a los PM a ser más productivos y mejores gestionando equipos. Y la capacidad de aportar claridad y alineación a un equipo de producto es fundamental para esas competencias. En unos minutos, Bijan compartirá un proceso fácil de replicar que te costará algo de tiempo al principio, pero puede salvar una startup al borde del abismo. Vamos allá.

Bienvenidos de nuevo, oyentes. Hoy me acompaña Bijan Shahrokhi. Es el fundador de ProductManagementExercises.com, y recientemente ha lanzado una herramienta de productividad destinada específicamente para product managers llamada ProductMonkey.ai.

Bijan, muchas gracias por acompañarnos hoy.

Bijan Shahrokhi: Muchas gracias por invitarme.

Hannah Clark: Genial. Siempre empezamos de la misma forma. Me encantaría si pudieras contarnos un poco sobre tu trayectoria y cómo acabaste donde estás hoy.

Bijan Shahrokhi: Claro. Soy product manager de corazón. He sido product manager durante más de 10 años, totalmente por accidente.

Ni siquiera sabía lo que era la gestión de producto hasta que tuve una startup que no iba muy bien. Le pregunté a un amigo qué creía que debía hacer a continuación y me dijo "deberías ser product manager". Y yo pensé: espera un segundo. Suena muy interesante, gestionar el producto y gestionar el producto. Eso es lo que quiero hacer.

A partir de ahí, me convertí en PM. He hecho algunas cosas distintas en los últimos 10 años. Trabajé los primeros años de mi carrera en organizaciones grandes, como en un banco como product manager y después como estratega de producto. Después formé parte de dos startups. En ambas entré justo al lanzar la empresa y una fue adquirida en un año y medio por un jugador más grande en el ecosistema.

Y la otra resultó ser un proyecto exitoso. Llegó a valer varios miles de millones de dólares en su pico. Sigue funcionando, sigue creciendo mucho. Y desde entonces me he concentrado principalmente en Product Management Exercises los últimos años de mi carrera. Recientemente lanzamos otro producto para la comunidad de gestión de producto llamado ProductMonkey.ai.

Hannah Clark: Increíble. Hoy vamos a hablar sobre la claridad en las organizaciones, que es un tema que te apasiona personalmente. Y con claridad me refiero simplemente a asegurar que todos los stakeholders estén alineados y compartan la misma versión de lo que está ocurriendo y de lo que se va a construir.

¿Cómo se ve eso para ti cuando una organización carece de un sentido de claridad?

Bijan Shahrokhi: Gran pregunta. Creo que la mayor señal que puedes ver, la señal más obvia de que una organización carece de claridad, es cuando recorres la organización y le preguntas a distintas personas cuáles creen que son los criterios de éxito para lo que hay que entregar como próximo gran hito, y empiezas a escuchar distintas historias.

Te doy un ejemplo. Por ejemplo, supón que trabajas con un producto muy técnico que va a tratar con muchas métricas de desempeño, como latencia, velocidad, número de transacciones por segundo o el volumen de tareas que se pueden completar. Si esto no está claramente definido, desde la perspectiva de una persona muy técnica dentro de la organización, quizá intenten construir algo que soporte un volumen extremadamente alto de transacciones, digamos.

Pero si le preguntas quizá a alguien más orientado al negocio y de cara al cliente, dirían que solo necesitamos lanzar algo para empezar a recibir feedback del cliente. Y notarás que hay falta de claridad una vez que empiezas a hablar con gente de toda la organización y oyes distintos números, o te dicen: "ah, nunca lo pensamos, o nunca lo discutimos". Eso suele ser una gran señal de alerta para ti como PM para darte cuenta que, un segundo, parece que aquí hay falta de claridad.

Hannah Clark: Parece que tienes algunas experiencias en primera persona con ese tipo de cosas. Sin dar nombres, ¿puedes pensar en alguna anécdota?

Bijan Shahrokhi: Claro. Sí. De hecho, el último proyecto del que te hablaba, que alcanzó una valoración de varios miles de millones de dólares, era una empresa que estaba a pocos meses de quedarse sin dinero y aún no había lanzado el proyecto.

Era como: pensaban que estaban a solo unos meses de lanzar su producto. Cuando entré, inicialmente me dijeron que estábamos a tres meses. Una vez que entré, me di cuenta de que lo que los fundadores, algunos de los fundadores, tenían en mente estaba quizá de 5 a 10 años lejos de la realidad.

Y lo que algunos ingenieros pensaban que estaban entregando también estaba a unos meses. Así que había una brecha enorme entre ambos. Por eso, llevaban desarrollando durante más de tres años, porque el equipo de ingeniería seguía presentando avances, y parte de los fundadores o del negocio los veían y decían: “Esperen un segundo, no están listos”.

Esto no cumple realmente lo que tenemos en mente. Redefinían lo que había que construir. Y la gente volvía a construir, se sentían decepcionados, sentían que no estaban siendo valiosos para la organización. Lo que hicimos en ese momento fue que pasé en realidad los primeros tres meses de mi tiempo como líder de producto reuniéndome con muchos stakeholders y entendiendo realmente cuáles son esos atributos con opiniones muy diferentes en la organización.

Por ejemplo, me di cuenta de que este atributo concreto en la empresa, o algunas personas dentro, piensan que debe ser parte del lanzamiento inicial. La otra mitad no lo piensa así. Comenzamos a tener muchas conversaciones sobre esos temas y logramos claridad sobre si se iban a construir o no. Era una decisión de sí o no. O sería una decisión de hacer una versión mínima.

Y exactamente qué iría en esa versión. Solo después de eso, nos llevó cerca de un año construir una versión ligera de lo que al principio se pensaba lanzar en tres meses. Sinceramente, nos llevó solos unos meses aclarar qué se iba a construir en un año.

Así que, espero que ese sea un ejemplo de cómo si aportas mucha claridad, puedes realmente sacar algo al mercado. Una vez lanzado, puedes usar el feedback de tus usuarios y de la comunidad para decidir cuáles de esas cosas en la lista deben priorizarse.

Hannah Clark: Sí, y cerrar una brecha así es un logro enorme, una tarea que parece imposible. Así que, es muy potente tomar ese enfoque. Si retrocedemos un poco, ¿cuáles dirías que son algunas de las implicaciones más amplias cuando una organización no incorpora procesos de claridad en su cultura en general, no solo en el equipo de producto?

Bijan Shahrokhi: El mayor impacto es que normalmente acaban no lanzando nada y eso es un gran problema. Hay muchos proyectos excelentes que nunca llegan al público porque se quedan sin dinero antes de poder inyectarle dinero a la empresa. Y, lamentablemente, esto es incluso una realidad más dura en proyectos basados en I+D. Porque los proyectos de I+D, que son muy científicos y buscan ofrecer un avance, suelen estar impulsados por fundadores con fuertes antecedentes académicos.

Y la gente con estos antecedentes, y sin ánimo de ofender (yo también tengo una fuerte formación técnica y académica y creo que es algo positivo), pero lo que pasa cuando una organización está dirigida por ellos es que buscan la perfección, y al buscar la perfección, siguen construyendo y sumando. Siempre les preocupan los escenarios extremos que, siendo sinceros, no son el fin del mundo si ocurren en la incubación o primeras fases del proyecto.

Y el resultado es que nunca lanzan y el mundo nunca llega a ver lo que tenían como visión para esa tecnología.

Hannah Clark: Sí, esa lucha de "terminado versus perfecto" está siempre ahí entre perfeccionistas y quienes solo quieren lanzar algo, ¿verdad? Así que un área que creo que todos podemos estar de acuerdo en que la claridad es vital, como dijiste, es desarrollar un MVP. Creo que es un terreno sembrado de errores y malentendidos que pueden ser desastrosos al final del día.

Entonces, ¿cuáles son algunos errores comunes que deben evitar los equipos que construyen MVPs y cómo pueden remediarlos?

Bijan Shahrokhi: Creo que el error más grande que he visto cometer a las startups con el concepto de MVP es confundirlo con entregar un producto roto e inutilizable, ¿verdad?

Y lo he visto muchísimas veces. Sin dar nombres, te doy un ejemplo. Por ejemplo, soy inversor en un producto empresarial que me apasiona mucho. Desde el primer día sabía que era algo que quería usar.

Y podía ver a mi organización en Product Management Exercises utilizándolo a diario. La mayor fricción para adoptarlo fue que tenía tantos bugs que era imposible siquiera usarlo. Así que es fundamental como líderes de producto tenerlo claro y asegurarnos de que cuando hablamos de un MVP, no nos referimos a un producto defectuoso e incapaz de mostrar el valor del producto.

Todavía hay que garantizar que la experiencia central del usuario o el valor principal que queremos entregar funcione bien, de principio a fin. Se pueden descartar muchas cosas que no son necesarias, ¿sí?, pero hay que asegurarse de poder entregar la experiencia central.

Creo que este es uno de los grandes errores: confundir MVP con lanzar algo roto.

Hannah Clark: Exacto. Está el grupo que no quiere esperar a que todo esté perfecto para lanzar, y el otro extremo... Sí, tiene sentido.

Tienes un proceso bastante intenso para buscar claridad en las organizaciones, como insinuaste antes. Si la gente quisiera copiar y pegar ese enfoque, ¿qué pasos le recomiendas para alinearse con todo el equipo?

Bijan Shahrokhi: Gracias por preguntar. Es interesante porque mucha gente en PM Exercises encuentra útil este proceso. La verdad, es bastante sencillo y se trata de hacer el trabajo difícil al principio antes de arrancar el proyecto. Es muy paso a paso y te lo explico rápidamente.

Básicamente, dedicas tiempo al principio para alinear a toda la organización a través de un proceso paso a paso. Solo cuando sientes que todos están alineados, empiezas. Es curioso porque este enfoque se ha adoptado en organizaciones grandes, por ejemplo bancos.

Pero al pasar de Waterfall a Ágil y Scrum, pensamos que no necesitábamos claridad sobre adónde íbamos, sólo plantearnos qué haríamos las próximas dos semanas. No, esa no era la intención de Agile. La intención era lanzar algo útil cada dos semanas sabiendo claramente tu meta para los próximos meses.

¿Cómo lo haces? Por ejemplo, cuando lidero un proyecto donde hay mucha falta de claridad, lo primero que hago es organizar reuniones uno a uno con los stakeholders, con mi producto. Deben ser individuales, no en grupo, porque si es un tema delicado, alguien comparte su opinión, otra persona salta, y tú como responsable de producto no puedes digerir bien todo el contexto. Así que necesitas la perspectiva individual de todos. Supón que tienes que decidir, ¿construimos X o no? Es binario, pero el modelo sirve para muchas cosas.

Los reúnes, obtienes su perspectiva sobre por qué debe hacerse o no, y preguntas qué aspectos debes considerar al tomar la decisión. Te darán varias cosas muy importantes en su mundo.

Especialmente en I+D esto es aún más importante. Cuanto más técnico es el producto o más dependencias técnicas tiene, más relevante porque hay expertos en la materia. Vas al siguiente, al siguiente, hablas uno a uno con todos.

A medida que avanzas, tu propia opinión sobre qué decisión tomar puede fortalecerse, cambiar u obtener nuevos puntos de vista. Descubres que hay cosas que parecen más fáciles o difíciles de lo que pensabas y las ajustas.

Pero lo que haces es, a medida que recoges información individual, vuelves a algunos de ellos y les dices: la primera vez que hablamos, estos eran tus tres principales problemas; por lo que he visto con otros, creo que no deberían preocuparte. Aquí el argumento, dime si me equivoco. En este ir y venir, aunque es un proceso largo, te das cuenta de que muchos retos del equipo eran por pura falta de comunicación. Nadie se dedicó a explicar todos estos trade-offs a los diferentes stakeholders, y muchas cosas se resuelven así.

A medida que avanzas, obtienes cada vez más claridad sobre los diferentes trade-offs que hay que considerar. Este enfoque también sirve para las prioridades de producto, pero podemos hablar de eso luego. En algún punto quizá haya temas sobre los que siguen existiendo opiniones divididas, como seguridad. Cuando llegas ahí, organizas una reunión grupal. Ahí explicas, este atributo es relevante, hay perspectivas diferentes, debatamos. Y así normalmente consigues una decisión.

A veces salen tareas: investigar más. Tras la reunión, muestras los resultados y se decide. Cuando tienes claros estos trade-offs, es mucho más simple decidir, ya sea sobre una dirección, estrategia, especificación o prioridades de producto. Para prioridades de producto, quizás necesites pensar antes en el objetivo.

Quizás debas comenzar diciendo: nuestro objetivo es lanzar rápido y aprender. Entonces verificas si todos están de acuerdo y, si sí, sigues adelante.

Hannah Clark: Me gustaría hablar más de prioridades de producto. Incluso cuando casi hay consenso sobre los objetivos, sigue siendo difícil priorizar entre diferentes opciones.

Existen decenas de marcos de priorización, pero ¿qué métodos has usado tú que han sido más exitosos cuando hay prioridades en competencia en estos contextos?

Bijan Shahrokhi: Una de las maneras es puntuar y mirar el tema desde distintos ángulos.

Uno es el impacto que una función o producto tendrá en mis usuarios. El segundo es la probabilidad de lograr realmente ese impacto, porque a veces ni siquiera sabes si resonará en tu público objetivo.

Si es así, la probabilidad es menor. El tercero es la facilidad de implementación. Entonces, mi fórmula mental es "impacto por probabilidad de impacto más facilidad de implementación". El impacto lo puntúo del uno al cinco, siendo cinco el más alto.

Para la facilidad de implementación, si es cinco es fácil, si es uno es mucho esfuerzo. Sumando tienes una puntuación. Esta aproximación me gusta porque es objetiva y abre un diálogo similar al proceso antes descrito.

Vuelves al equipo y presentas la tabla de los proyectos clave con tus puntuaciones de impacto y esfuerzo. Según eso, propones tus cinco grandes prioridades.

Ellos podrán debatir, sugerir proyectos que falten, dividir un proyecto grande en varios, o cuestionar tus puntuaciones. Pero empiezas a tener discusiones objetivas, centradas en puntos concretos.

Esta manera de puntuar tiene la ventaja de que, como no intentas estimar tiempos exactos, todo es relativo entre proyectos, así es mucho más sencillo alcanzar consenso sobre el valor o el esfuerzo de cada cosa. Así acabas con una lista nítida de prioridades para el próximo trimestre. Cuando surgen nuevas sugerencias, solo hay que revisar la tabla para ver si ahora se justifica un cambio.

Y a veces identificas otras cosas a considerar. Podemos hablar de esos escenarios también.

Pero, en general, este método es más objetivo y facilita priorizar.

Hannah Clark: Es genial. En Product Manager hemos hablado antes de despersonalizar el feedback y las discusiones de priorización para que nadie sienta que su proyecto o agenda fue relegado por motivos personales.

Así que es un método muy prescriptivo, lo aprecio mucho. ¿Qué era lo que querías mencionar? Dijiste que hablaríamos de ello en un segundo.

Bijan Shahrokhi: Sí, a veces la gente insiste en que algo debe ser prioritario y resulta que realmente sí debe serlo.

¿Cómo se gestiona eso? Pues no se puede agregar la nueva prioridad sin más. O eliminas algo para hacerle espacio, usando el sistema de puntuación, o asignas nuevos recursos para que no afecte la velocidad de entrega de los que ya eran prioridad. El principio es que los elementos ya priorizados no pierdan velocidad sólo porque un nuevo ítem entra en la lista. Ese es el trabajo del product manager, y en algunas organizaciones no es así y luego ocurren retrasos.

Creo que un buen PM presta mucha atención a esto: si sale una nueva prioridad por información relevante, se pregunta cómo afrontarla, si eliminar algo de la lista o conseguir más recursos sin ralentizar lo demás.

Hannah Clark: Fascinante. Cambiando un poco de tema, ya que se nos acaba el tiempo, quería hablar sobre productividad, otro asunto que te apasiona y que probablemente es una razón importante para haber fundado productmonkey.ai.

¿Tienes algún consejo general sobre productividad para nuestra audiencia y alguna información sobre Product Monkey AI que pueda interesarles? Es una herramienta muy interesante.

Bijan Shahrokhi: Claro. Con Product Monkey AI estoy automatizando una tarea fundamental para los PM pero que no me gusta: dedicar mucho tiempo a redactar requisitos detallados y criterios de aceptación, por las razones que mencionaba. Así que lo que hacemos con Product Monkey AI es obtener toda la información posible del proyecto, de tu organización y del flujo de usuario.

Y con orientación adecuada, usamos IA para generarte requisitos de producto detallados, criterios de aceptación, escenarios de prueba y hasta eventos y métricas que debes monitorear cuando lanzas el producto. Así puedes usarlo y tener un borrador rápido, que cubre el 80% del trabajo para las tareas de ingeniería y los PRDs antes de pulirlos.

Así dedicas lo que falta a terminarlo. Así, los PM podemos aportar claridad y Product Monkey AI reduce el tiempo necesario para lograrlo.

Hannah Clark: Es fantástico. Seguro que mucha gente que escucha encontrará muy útil esa herramienta. Bijan, muchas gracias por acompañarnos hoy. ¿Dónde puede encontrarte la gente online si quiere saber más de ti?

Bijan Shahrokhi: Pueden buscarme en Twitter, o X como se llama ahora. Mi usuario en X es bijan_sha. También pueden ir a PM Exercises o Product Management Exercises. Si buscan cualquiera de los dos llegarán a nuestro sitio y podrán contactarme allí.

Hannah Clark: Genial. Muchas gracias por tu tiempo.

Bijan Shahrokhi: Muchas gracias por invitarme.

Hannah Clark: Gracias por escucharnos. Para más ideas útiles, guías y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más conversaciones como esta suscribiéndote a The CPO Club en tu plataforma de podcasts favorita.