Producto Lecciones aprendidas: una conversación con Shreyas Doshi y John Cutler

Publicado: 2021-07-13

En un período de tiempo relativamente corto, Shreyas Doshi se ha convertido en uno de los dispensadores de consejos sobre productos más populares en Twitter. ¿Por qué? Su escritura es clara, humilde y consciente de sí mismo, rasgos que a menudo faltan en medio de la manguera de fuego de tomas calientes. ¿Su formato de elección? Hilos. Y muchos de ellos. Entrelazados pero organizados. Toda una carrera de sabiduría empaquetada en cadenas de 280 caracteres. Disponible para todos aquí.

Tenía mucha curiosidad acerca de la persona detrás de la (buen tipo de) locura. ¡Así que concertamos una entrevista! Cubrimos temas como el liderazgo, convertirse en un mejor oyente, el papel de los mandos intermedios, la carrera y la identidad propia, la terquedad, el teatro del calendario y el tratamiento de sus tableros como productos.

¿Qué se destacó? Shreyas tiene una gran experiencia en gestión de productos. Ha trabajado como gerente de productos de primera línea y gerente de gerentes de productos en compañías como Stripe, Google, Twitter y Yahoo. Es un gran escritor y orador. Pero es su humildad y consideración lo que realmente brilla. Advierte a las personas que no copien ciegamente su consejo y admite abiertamente que ha aprendido muchas de estas lecciones de la manera más difícil.

La entrevista es de 1 hora y 30 minutos (ver el reproductor de audio a continuación). Si desea saltar, hemos creado un esquema de la entrevista a continuación con marcas de tiempo. Para cada sección, Shreyas tuvo la amabilidad de proporcionar enlaces a hilos relacionados.

¿Tiene preguntas de seguimiento para Shreyas? Tuitee sus preguntas, incluidos @Amplitude_HQ, @shreyas y #shreyasinterview. Si hay suficiente interés, intentaremos programar un AMA de seguimiento.

Tengo una pregunta para @shreyas y @johncutlefish #shreyasinterview Haz clic para tuitear

Y si desea obtener más información sobre la estrategia de productos y el liderazgo en la gestión de productos, asegúrese de descargar una copia del libro de jugadas de North Star. Está lleno de orientación y marcos para ayudarlo a impulsar el impacto para su negocio y su equipo de inmediato.

Tabla de contenido de la entrevista

La transcripción completa incluye tweets relacionados para el contexto. ¡Gracias a Shreyas por seleccionarlos para todos!

  • Introducción [00:00:00]
  • “No creas todo lo que escribo…” [00:01:07]
  • Comprendernos a nosotros mismos [00:04:03]
  • Convertirse en un mejor oyente [00:05:13]
  • Transición de IC a gerente [00:11:49]
  • Discutiendo la incertidumbre y la cultura organizacional [00:14:10]
  • Mandos intermedios y la “real verdad” [00:16:52]
  • El papel del liderazgo de producto [00:18:01]
  • Identidad profesional (y el cambio a roles de liderazgo) [00:21:56]
  • El rol del gerente para ayudar a las personas a adoptar comportamientos no predeterminados [00:25:39]
  • Mentalidad, principios y tácticas (y atascarse en las tácticas) [00:30:29]
  • Los fundamentos/bases para un equipo de alto rendimiento [00:35:11]
  • ¿Por qué los equipos que cumplen los requisitos básicos producen productos deficientes? [00:37:31]
  • Intencionalidad y terquedad (con la compañía que quieres ser) [00:39:24]
  • Inteligencia analítica y creativa [00:44:14]
  • Nivel de impacto, nivel de ejecución y nivel de óptica [00:49:13]
  • Sesgos cognitivos y vocabulario compartido [00:54:37]
  • Tratar los tableros como un producto [01:01:51]
  • Calendarios llenos, reactividad, identidad propia y hábitos positivos/negativos [01:08:20]
  • Mejorar la situación actual (y la brecha frente al pensamiento actual) [01:14:24]
  • LNO: tareas de apalancamiento, neutrales y generales [01:18:10]
  • Conclusión [01:21:23]

Transcripción de la entrevista

Introducción [00:00:00]

John Cutler: Buenos días, Shreyas.

Shreyas Doshi: Buenos días, John.

John Cutler: ¿Cómo te va?

Shreyas Doshi: Bastante bien. Es bueno estar aquí.

John Cutler: Así que esta es la segunda vez que hablamos. Y recuerdo que cuando hablamos por primera vez, dijiste, ¿debería seguir haciendo esto de Twitter? O, ¿qué tal un libro? No sé cuántos meses fue eso. Quiero decir, parece que el tiempo de la pandemia aplasta las cosas en general, pero ha pasado un tiempo y las cosas han explotado absolutamente para ti.

Así que me gustaría notar la diferencia desde la última vez que hablamos. Así que supongo, felicitaciones.

Shreyas Doshi: Gracias. Ha sido divertido. Simplemente escribiendo algunos pensamientos sobre el producto y todo eso. 280 caracteres a la vez.

John Cutler: Para aquellos que no lo sepan, Shreyas Doshi, les daré una breve introducción. Es un gerente de producto. Más recientemente en Stripe, tiene experiencia en Twitter y Google, en Yahoo. Es un escritor prolífico. Y creo que eso es todo.

Quería perforar el velo de la invencibilidad, para empezar si está bien. Porque tu escritura es muy concisa. ¿Cuál es un error con el que estabas luchando en los últimos meses?

“No creas todo lo que escribo…” [00:01:07]


Shreyas Doshi: Sí. Entonces, una cosa que me gusta decir sobre mi escritura es, en primer lugar, no creas todo lo que escribo y no tomes todo lo que escribo y simplemente lo implementes porque te gustan mis escritos, o porque la cosa obtuvo muchos "me gusta". , por lo que debe ser cierto. John, eso es algo que a lo largo del año pasado realmente comencé a escribir sobre mis pensamientos sobre el producto, la estrategia, las organizaciones y todo eso.

Antes de presionar el tweet o el botón de enviar, la mayor inquietud que tiendo a tener es oh, aquí están las seis formas en que lo que acabo de decir podría ser dañino, si se toma fuera de contexto o si se implementa en el contexto incorrecto. Esa es una preocupación constante que tengo sobre lo que escribo y, a veces, parte de la precisión y tal vez parte del poder de la escritura, si es que hay alguno, puede sonar más cierto de lo que realmente es en su situación particular.

La escritura está lejos de ser perfecta. Porque es probable que pierda muchos, muchos matices, incluso cuando trato de aclararlo o en algún lugar de la banda de rodadura. Así que ese es uno. En segundo lugar, creo que twitteé esto hace unas semanas que sabes, tiendo a hablar mucho sobre las cosas anti-patrones que no se deben hacer. Y la razón por la que hablo de eso y, a veces, la gente me dice, oh, esto creó una gran claridad. Vi este antipatrón dentro de mi equipo, dentro de mi empresa, dentro de mí mismo, dentro de mi gerente, lo que sea. ¿Y cómo llegaste allí? Entonces, tuiteé este punto, que es, ya sabes, muchos de estos antipatrones sobre los que escribo, he sido ese antipatrón. ¿Derecha?

Lo he visto dentro de mí.

A veces es solo por unas pocas horas que como, oh, estoy entrando en este anti-patrón como, oh, lo sentí, y lo detuve, y tuve éxito en detenerlo. A veces, he tenido cierto anti-patrón sobre el que escribo durante muchos meses. Y hay otras que he tenido durante muchos años y cosas que no hago muy bien por mi cuenta.

Y entonces está ese aspecto de, ya sabes, mucho de lo que escribo, he visto partes dentro de mí, o todo dentro de mí durante diferentes períodos de tiempo. Y, creo que la única diferencia es quizás que, ya sabes, es el tipo de autoobservación, ¿verdad? Una de las cosas que también me gusta compartir es que podemos hablar sobre tácticas y podemos hablar sobre marcos, estructuras y plantillas para la gestión de productos.

Comprendernos a nosotros mismos [00:04:03]

Pero en el lado suave, creo que una cosa muy importante que todos nosotros, como gerentes de producto, debemos darnos cuenta y mejorar como gerentes de producto, es comprendernos a nosotros mismos. Ya sabes, el centro del que hablan, oh, comprender al usuario, comprender al cliente, comprender el mercado, comprender al competidor.

Estoy de acuerdo con todo eso. Pero también entiéndete a ti mismo. Comienza por entenderte a ti mismo. Ahora no vas a entender todo de ti mismo a la vez. Pero si comienza comprendiéndose a sí mismo, encontrará que algunas de estas otras comprensiones del usuario y otras cosas se vuelven más fáciles.

Hay muchas, muchas cosas en las que no soy muy bueno. Recientemente, creo que estaba, de nuevo, estaba teniendo una conversación en Twitter y alguien me preguntó, oh Shreyas, ¿cómo se debe administrar bien dentro de una organización?

Dije, mira, no tengo una respuesta para eso, porque he sido muy malo administrando durante muchos, muchos años. Andrew Yu me había enviado un libro sobre gestión. Entonces le dije: Oye, Andrew, probablemente deberías responder este tuit en lugar de que yo lo haga. Así que ese es solo un ejemplo de algo que sabes, no he descifrado del todo.

Convertirse en un mejor oyente [00:05:13]

John Cutler: Una cosa que realmente disfruto es que a través de tus hilos, eres vulnerable y humilde. Recuerdo un tweet que me gustó mucho, donde observaste que tu yo más joven era un mejor oyente y que entraste en un período en el que no estabas escuchando tan bien.

Y eso fue extremadamente impactante para mí. Porque pensé, he pasado por estas fases en mi vida, y no es una situación estática. Siempre estás aprendiendo. Me preguntaba específicamente con esa situación, ¿cómo fue esa autorrealización? Ya sabes, ¿cuándo te das cuenta de eso y cómo llegaste a lidiar con eso? ¿Y luego qué, qué pasos diste? Y empezaste a detallarlo en el hilo, pero me interesaría mucho que lo explicaras y lo escucharas en persona.

Shreyas Doshi: Entonces, solía ser un excelente oyente cuando era niño. Al principio de mi infancia, también tenía una memoria bastante fuerte. Ese ya no es el caso. Ahora me olvido de las cosas todo el tiempo. Pero yo empecé así. Y muchas cosas en la escuela, por ejemplo, fueron fáciles para mí desde el principio porque solo escuchaba lo que decía el maestro.

Y luego pude retenerlo durante mucho tiempo. Eso cambió en mi adolescencia y principios de los veinte. Sabes, no sé por qué. Debe haber sido justo lo que pasas en tu juventud. Donde simplemente, en algún momento, simplemente me desconecté por completo en la universidad.

Y no tenía idea, estaba sentado allí físicamente, pero no tenía idea de lo que se decía. Y eso continuó. Simplemente se convirtió en este patrón. Mientras que cuando comencé mi carrera como ingeniero de software, ya no era ese grado de apatía sobre lo que se dice en una reunión o lo que dice otra persona. Pero simplemente perdí esa habilidad, debido a que no la usé durante cinco o seis años en ese momento.

John Cutler: ¿Hubo un momento en que dijiste, espera, perdí esto? Como, ¿cómo lo hiciste, cómo te di cuenta, o fue como una combustión lenta? ¿O tal vez fue un gerente o alguien que compartió la noticia contigo? ¿Cómo, cómo te diste cuenta?

Shreyas Doshi: Sabes, John, me di cuenta de esto muy tarde. Así que quiero decir que estaba en el estado de ser un buen oyente, durante aproximadamente 12 años cuando comencé mi carrera. Lo que eso significaba era, por supuesto, que estaba escuchando. estaba procesando, etcétera. Pero yo estaba en este modo del clásico formando mis propios pensamientos. Formando mi respuesta, y preparando mi respuesta. O no escuchar realmente lo que se decía, sino escuchar lo que quería escuchar.

Así que estuve en esa fase durante al menos 12 años en mi carrera. En algún momento, la mayor realización para mí fue que la clave para comprender a la otra persona será asegurarme de que sepa que la entiendo. ¿Derecha? Así que comencé con ese primer paso. Y ese fue un tipo muy táctico, no se basó en ningún principio. Era una táctica como está bien.

John Cutler: Tenías que pensarlo en tu cabeza que...

Shreyas Doshi: Sí. Para ser un buen gerente, necesito asegurarme de que la otra persona entienda que entiendo lo que está diciendo. Ese es el lugar donde comencé. Y luego hice eso, y diría que tal vez me llevó de ser quizás de un cuatro de 10 a ser un seis de 10. Lo cual está bien. Es una mejora.

Pero luego, la siguiente gran realización, y el cambio cuántico que pude hacer, fue cuando me di cuenta de que cuando escuchas solo lo que se dice y estás completamente presente, las respuestas se crean solas. ¿Derecha? Así que en realidad no tengo que pensar mientras hablas. O ni siquiera tengo que pensar cómo voy a resumir lo que estás diciendo, solo para asegurarme de que te entendí.

Solo quiero estar cien por ciento presente. Y quiero ser curioso. Ese fue el cambio. Fue esa curiosidad genuina y desarrollar esa curiosidad genuina, junto con la habilidad de poder estar presente y poder observar mis partes, y regresar exactamente a las palabras que se pronunciaban.

Luego, cuando hice eso, cuando lo abordé desde esta genuina curiosidad y presencia, fue cuando vi, oh, wow, cuando estoy haciendo esto, suceden dos cosas. Una es que estoy [00:10:00] simplemente pareciendo que esta otra persona está mucho más interesada en lo que está diciendo. Y segundo, la calidad de mi respuesta es mucho mayor.

Mientras que anteriormente, a menudo, la respuesta tendía a tener una sensación de, está bien, te escuché, y dada mi función, a menudo es como si te hubiera escuchado, y este es mi consejo. O aquí está mi respuesta. La respuesta se convirtió en una pregunta, en lugar de una declaración.

Así es como entendieron que realmente los estaba entendiendo. Y yo estaba haciendo un intento genuino de comprenderlos mejor. Me dijeron algo. Yo estaba realmente presente. Yo estaba genuinamente curioso. Y por eso, les hice una pregunta que de otro modo no hubiera hecho. Y esa pregunta nos acercó a poder entender mejor la situación. Cuando comencé a hacer eso, me di cuenta cada vez más de que, oh, esto es realmente efectivo. Hacer preguntas a la gente es mucho más efectivo, si son las preguntas correctas. Y, si se basan en una comprensión profunda, o tan profunda como puedas, de lo que la otra persona está tratando de decir sobre la situación.

John Cutler: Parece que desarrollaste algo, con el transcurso del tiempo, y simplemente te volviste mucho mejor en eso de esa manera. Como, puedes hacer mejores preguntas en uno a uno, etcétera.

Shreyas Doshi: Claro. Y, ya sabes, he sido gerente de PM en cada una de las cuatro empresas en las que he sido PM. En tres de esas cuatro empresas, me uní como colaborador individual, incluido mi empleador más reciente, Stripe. Me uní como colaborador individual y luego comencé a administrar personas.

Transición de IC a gerente [00:11:49]


Así que pasé por esa transición de IC a gerente. Mucha gente pasa por eso una o dos veces. Uh, y luego siguen siendo gerentes. Lo he pasado varias veces. Y no me importa estar en IC donde tiene sentido. Así que me ha ido bien.

Aunque cada vez ha sido diferente. Porque a medida que he crecido como gerente. Creo que cuando comencé a administrar, tenía nueve meses como gerente de producto. Me dijeron, oh, nos gusta lo que estás haciendo. ¿Por qué no gestionas un equipo pequeño? Mirando hacia atrás, no me di cuenta en ese momento, pero mirando hacia atrás, sentí que era un terrible, terrible gerente de PM. Esto se remonta a, ya sabes, muchos de estos antipatrones. he sido eso Porque recuerdo desde el principio, estaba tan seguro de que tenía la respuesta.

Y ese fue uno. Y segundo, pensé que mi trabajo era dar la respuesta. Si encontré resistencia dentro de mi equipo para aceptar o tomar esa respuesta, entonces sentí que mi trabajo era convencerlos a través de medios muy analíticos, ¿por qué esta es la respuesta correcta, verdad?

Yo era simplemente horrible como gerente en ese entonces. Y, por supuesto, ahora tomo un enfoque muy diferente. Mucho de eso tiene que ver con, ya sabes, cultivar esa curiosidad genuina, supongo, también la madurez general de la vida. Pero también poder observar mis pensamientos y comprender qué es lo que debe hacer un gerente de PM.

¿Cuál es su trabajo y cuál es su papel? Ahora tengo una mejor comprensión, mientras que anteriormente solo me pedían que comenzara a administrar personas, como si no tuviera idea de lo que se suponía que debía hacer.

John Cutler: Cuando piensas en las empresas en las que has estado involucrado, quiero decir, creo que una cosa que he notado sobre ciertas culturas empresariales es que tratan de manera muy diferente la discusión sobre la incertidumbre. En algunos, ya sabes, nunca se menciona la incertidumbre a menos que tengas un plan absoluto para reducirla.

Y en otras culturas, parecen mucho más abiertos a que un líder diga, simplemente no lo sé en este momento. Entonces, ¿cuál es tu plan de juego para eso? Como si hubiera estado en estas organizaciones, pero ¿cómo entendió la cultura de vulnerabilidad para los líderes?

Porque obviamente es importante, pero se manifiesta de manera diferente en diferentes culturas.

Discutiendo la incertidumbre y la cultura organizacional [00:14:10]

Shreyas Doshi: Me gusta que hayas mencionado la cultura allí, John, porque todo se remonta a eso. Hay culturas donde. Sí, se supone que debes estar seguro. Y si no está seguro, y si no tiene toda la justificación, la justificación analítica, se le considera incompetente.

Hay otras culturas, donde una cierta cantidad de incertidumbre se ve como parte de lo que hacemos, que es, sí, no sabremos cómo va a funcionar esto y eso está bien.

Eso no significa que la segunda categoría de cultura sea menos rigurosa. Yo diría que es más riguroso. Porque no se basa en ilusiones sobre resultados matemáticos estrictos basados ​​en ciertas entradas. Entiende la aleatoriedad involucrada cuando tomas un producto [00:15:00] y lo llevas al mundo exterior. Entiende otra aleatoriedad, el propio sistema en el mercado y todo eso.

Funciona dentro de ese tipo de comprensión del mundo real de estas cosas. Frente a algunos idealizados, ya sabes, oh sí, deberíamos poder probar esto en un enfoque tipo hoja de cálculo. Raya es un buen ejemplo. Donde, ya sabes, tendríamos revisiones de productos donde nuestros fundadores, o nuestros líderes, dirían, sí, no hay forma de que estemos seguros de esto.

Entendamos cuáles son los comentarios de los clientes. Entendamos cuál es el contexto del mercado. Y luego, en base a eso, tomaremos la mejor decisión según las circunstancias. Pero, ya sabes, no tenemos que estar seguros de que esto funcionará.

John Cutler: Correcto. Eso es un modelado increíble, ¿verdad? Como desde el punto de vista de un líder. Y eso significa que va un largo camino. Si un líder dice eso, seguro.

Shreyas Doshi: Sí. Sí. Y, ya sabes, también está la clásica puerta de un solo sentido, puerta de dos sentidos, que realmente vi practicada en Stripe. Esta es una decisión que podemos deshacer. ¿Derecha?

Así que hagámoslo. Está bien. Si nos equivocamos, simplemente lo desharemos. El costo de deshacerlo no será sustancial. Y luego quizás haya otras decisiones que serán más difíciles de deshacer, o que no podemos deshacer. En realidad, dediquemos nuestro tiempo a hacerlo bien. Entonces, de nuevo, todo lo que estoy diciendo aquí, John, se siente obvio, como sí, por supuesto que deberías hacerlo en la mayoría de los casos.

Como, por supuesto que deberías hacerlo. La pregunta es ¿por qué esto no sucede? ¿Por qué la mayoría de las organizaciones son muy imperfectas en este sentido? Y creo que tú y yo hemos discutido este tema del teatro de certezas. Y creo que eso tiene mucho que ver con la seguridad psicológica que la cultura crea para los mandos intermedios en particular.

Mandos intermedios y la “real verdad” [00:16:52]

La forma en que veo a los mandos intermedios es que son la forma en que la organización garantiza que pueda llegar a la verdad real. Existe la verdad sobre el terreno y, ya sabes, las personas que trabajan muy directamente en esa verdad. Y luego, cuando vean esa verdad, la transmitirán a los mandos intermedios. Y luego, la gerencia intermedia actúa como este representante, justo entre la verdad que ves en el terreno. Y luego la verdad que los ejecutivos de la compañía están viendo a escala macro.

Así que creo que es muy importante que los mandos intermedios se sientan libres de expresar las verdades que ven en ambos lados. Sin tener que preocuparse de que su trabajo esté en peligro, o su posición esté en peligro, o el éxito de su carrera esté en peligro.

Y si pueden hacer eso, esa es, creo, la clave para desbloquear un mejor tipo de flujo de la verdad en ambas direcciones dentro de una organización.

John Cutler: La gerencia intermedia no es solo una capa. En muchos casos, son múltiples capas. Entonces, ¿cómo mantienes la verdad fluyendo en ambas direcciones a través de dos o tres capas de eso?

El papel del liderazgo de producto [00:18:01]

Shreyas Doshi: La primera observación es que en realidad no estamos hablando de cuál es el trabajo y cuál es el papel de un líder de producto. ¿Derecha?

Mi observación es que la mayoría de estos líderes de productos con, ya sabes, tremenda experiencia, excelentes currículums. Si les preguntas, ¿cuál es tu papel? Como, ¿cuál es tu papel real? Lucharán. Y no los culpo porque, ya sabes, nadie les enseñó cuál es su papel. Entonces simplemente comenzaron a hacer cosas y luego, lo que sea que estuvieran haciendo, si funcionaba, si obtenían alguna validación externa, hacían más de eso. Y luego suprimieron las cosas por las que no obtuvieron validación.

Así que de alguna manera llegué a cierto estilo, o cierto enfoque, o alguna definición de rol implícita. Eso ahora está tan profundamente arraigado en sus hábitos, que no pueden describirlo del todo. Como, está bien, mi papel es X, Y y Z.

Y creo que eso es muy importante. Una vez que comprende el rol, queda claro lo que debe hacer, ¿verdad? Lo que debe hacer es permitir el éxito del producto a través de otros, ¿verdad? Eso es efectivamente lo que debe hacer como líder de producto en la gerencia media en algún lugar.

Y para permitir el éxito de ese producto a través de otros, y hablo de ello en términos de crear equipos autogestionados, ¿no? Por lo tanto, crear equipos autogestionados es tan vital. Lo ideal como líder de producto, ya sabes, no es solo como apagar incendios y tener que aparecer en ocho revisiones porque necesitas estar allí, y necesitas examinar todo, y nada sucede sin que tú estés allí.

Y sé que esta es la realidad de muchos líderes de productos, nuestro trabajo diario, por lo que muchas veces es muy estresante. Y entreno a muchos de estos líderes de productos con bastante regularidad, y es [00:20:00] sorprendente para ellos que no tiene que ser así. No tiene que ser la forma en que lo está haciendo, ya sabe, literalmente 40 reuniones o 50 reuniones por semana.

Hay una broma que he escuchado muchas veces. Que es como, oh, eres un líder de producto, por lo que nunca vas a estar en tu escritorio, ¿verdad? Como siempre vas a estar en las reuniones. Jaja. Lo aceptamos como realidad. Rechazo absolutamente esa premisa. En realidad, como líder de producto, debería pasar mucho tiempo en su escritorio. Y si no lo está haciendo, significa que no está cumpliendo con el segundo aspecto de su rol, que es crear equipos autogestionados. ¿Derecha?

Así que creo que se remonta a la comprensión del papel. Y una vez que entiendas el rol, tus acciones serán bastante diferentes en términos de cómo delegas, cómo no solo dices, bueno, no me gusta este enfoque de este flujo que me estás mostrando, sino que me gusta algo más, pero en su lugar diga, mire aquí, así es como pienso sobre esto.

Así es como pienso en los objetivos del usuario. Así es como pienso sobre los objetivos de conversión que tenemos. Y luego aquí hay quizás algunos principios para que los consideremos. Aquí hay quizás algunas métricas que debemos buscar para descubrir cuál es la respuesta correcta, ¿verdad? Esa es la conversación que debe tener como líder de producto con su equipo, porque así es como se crea un equipo autoadministrado en lugar de, oh, Bob, a Bob solo le gusta el flujo de una sola página, ¿verdad? Me gusta, o pasos de una sola página. Y así es solo una peculiaridad de Bob. Y así que asegúrese, este es el gerente de producto diciéndole al diseñador, solo asegúrese de hacer eso, ¿verdad? Me gusta, pero falta el por qué de eso. Se trata más de, oh, si desea obtenerlo con éxito a través de la revisión de Bob, deberá hacer esto. derecho. Lo cual no tiene sentido porque ahora creaste algo así como lo contrario de un equipo autogestionado.

Identidad profesional (y el cambio a roles de liderazgo) [00:21:56]

John Cutler: Una cosa que también me viene a la mente es que, a menudo, los gerentes de producto parecen disfrutar de esta naturaleza nebulosa de su rol, comenzando incluso desde el IC PM. Casi se identifican a sí mismos como el cambiaformas. Tipo de empujarse a sí mismos en todo lo que hay que hacer.

Y me puedo imaginar que esa persona, cuando se convierta en director, ascienda. Tal vez a veces no pueden dejar de lado eso. Tal vez eso es algo que conduce a la incapacidad de aclarar su papel.

Shreyas Doshi: Oh, ya sabes, John, lo que acabas de decir resuena con tanta fuerza. Quiero compartir dos cosas en respuesta a eso. La primera, es que tienes este ejemplo clásico. Y de nuevo, este era yo hace muchos, muchos años. Esta era yo hace 12, 13 años. Gerente de producto aparentemente competente, alguien que es realmente bueno en el trabajo central de la gestión de productos.

Quién sabe, está bien, queremos que administres los MP. Bien, ahora, lo que sucede en esa situación es realmente interesante. Y creo que si esto les sucede a muchos, muchos PM competentes. Lo que los convierte en líderes de producto un poco menos competentes, al menos el primero o el segundo...

John Cutler: ¿Está diciendo que los PM se vuelven cada vez menos competentes a medida que ascienden en una organización?

Shreyas Doshi: Bueno, los requisitos, la barra cambia. ¿Derecha? Entonces, por ejemplo, en mi caso, todavía estaba construyendo y desarrollando mi conjunto de habilidades básicas de gestión de productos. No estaba completamente construido, pero me pidieron que lo administrara, lo cual está bien, eso también sucede en muchas otras funciones. Pero el desafío es que yo tampoco estaba mentalmente allí, ¿verdad?

Como si supiera que tenía estos vacíos, y en algún lugar dentro de mí, todavía tenía ese impulso para demostrar que soy un gran gerente de producto. No un gerente de gerentes de producto, sino un gerente de producto realmente excelente. Y la forma en que se manifestó con mi equipo es, ya sabes, surge algo y digo, oh, esta claramente no es la respuesta correcta. Así es como debemos pensar sobre esto. Como, solo mira mi lenguaje. ¿Derecha? Como estas son las palabras que solía usar.

Y lo que realmente estaba haciendo, ahora lo entiendo, no lo entendía entonces. Lo que realmente estaba haciendo era probarme a mí mismo que todavía lo tenía. Y tratando de probar y mostrar a los demás, al igual que lo bueno que soy en el trabajo de colaborador individual central de IC. Ah, y veo esto con los gerentes de producto, especialmente en sus primeros tres o cuatro años, todo el tiempo cuando se involucran en la gestión de gerentes de producto. Todavía están tratando de desempeñar la función de gestión de productos, la función central de IC, en lugar de la función de gerente.

Y eso crea todo tipo de desafíos para ellos mismos. Porque, ya sabes, cuando adoptas ese tipo de enfoque IC, vas a ser el gerente que dice, [00:25:00] oh sí, necesito ir a esa reunión. ¿Puedes por favor invitarme? Porque necesita ese contexto sobre el terreno para que pueda formarse una opinión sobre la estrategia del producto o la dirección del producto, ¿verdad?

Versus, desarrollando la habilidad de entender eso a través de tu gente. Y luego molesta a la persona de su equipo porque es como, ¿por qué mi jefe se presenta a esta reunión? No tiene sentido. Y, oh, mi jefe es un microgerente. O mire, oh, debido a que mi jefe se presentará en esta reunión, ahora necesito actuar en esta reunión en lugar de solo ser vulnerable, yo mismo, haciendo preguntas legítimas y genuinas y todo eso.

El rol del gerente para ayudar a las personas a adoptar comportamientos no predeterminados [00:25:39]

Les diré una cosa relacionada con este tema que estamos discutiendo que tengo en mente, es ver el rol del gerente, específicamente en el contexto de la gestión de productos, ver el rol del gerente, el rol del director, el rol del VP, el rol del CPO como se trata de ayudar a las personas a comprender cuándo deben adoptar sus comportamientos no predeterminados.

Tomemos un ejemplo específico. Encontrará, ya sabe, en algún lugar de una publicación de blog, o tal vez en un hilo de Twitter, este tipo de, oh, esto es lo que un gerente de producto necesita para...

John Cutler: Podríamos haber sido corresponsables de esto, por cierto. Así que creo que podemos,

Shreyas Doshi: Absolutamente. Estas son las cosas en las que estoy como, oh, estoy nervioso presionando enviar ...

John Cutler: …Tengo pesadillas sobre esto, así que mantendré mi…

Shreyas Doshi: ¡Seguro! Entonces, tomemos un tipo hipotético de publicación de blog sobre lo que se supone que deben hacer los gerentes de producto. Y es como si un gerente de producto estuviera ahí para su equipo. El jefe de producto desbloquea el equipo. El gerente de producto verifica con el equipo lo que el equipo necesita y entrega lo que necesitan para que puedan ser eficientes.

Pueden ser efectivos. Un gerente de producto se asegura de que estén haciendo controles regulares con ingenieros individuales para asegurarse de que están obteniendo lo que necesitan, bla, bla, bla. Derecha. Entonces puedes imaginar este tipo de publicación de blog hipotética.

Y diga que soy un gerente de producto, o un nuevo gerente de producto, y diga, está bien, todo esto tiene sentido. Y voy a empezar a hacer esto. Y, ¿adivinen qué sucede? Como empecé a hacerlo, y funciona muy bien. La gente dice, oh, ya sabes, Alice se unió como PM para nuestro equipo. Y ha sido asombroso. Ha sido una diferencia de día y noche. No puedo creer que estuviéramos operando sin un PM, y esto es increíble, más PM, ¿sabes?

Asegurémonos de reconocer a Alice por nuestras contribuciones como gerente de producto, etcétera, etcétera. Derecha. Bueno. Funciona genial. Entonces, ¿qué pasa ahora? Si soy el gerente de producto, hago de este mi comportamiento predeterminado. Porque este es mi primer año haciendo el trabajo. No sé nada sobre la gestión de productos en varios contextos diferentes.

Supongo que estoy recibiendo validación para estas acciones. Así que tengo que hacer la misma cantidad o más de estas acciones, ¿verdad? Ahora, transpórtame a un equipo diferente. Or a different company. Bueno. Now, in this company, or on this team, let's just say on this team, well the engineers are very independent. They are already talking to customers directly, right?

They're talking to sales directly to understand requirements. They are talking to marketing. You know, the designers are doing end to end research and validation as well as again, kind of very customer centric. And it's generally a very high agency team, right?

Like again, the tech lead, or the lead designer, isn't afraid to go to the VP or the CEO and ask questions or ask for what they need and whatnot. ¿Derecha? You can bring in this product manager, who's performing these defaults, in this situation, what happens, right?

Same product manager, different teams. And the feedback is, oh, you know, we think Alice needs to create more room for ideas. We think Alice can sometimes create an unnecessary obstacle for us. We think that is a lot more process. We think there are many more check-ins than there need to be. We don't have to provide status on a daily basis for what we are doing, et cetera, et cetera. ¿Derecha? Same product managers, same actions, different contexts. Doesn't work. So with this now let's get back to the thing I've been mulling over recently, which is where is the failure here?

I don't think the failure is at the level of the PM. It's not Alice's failure. It's the manager's failure, right? It's the manager's responsibility to help a PM understand the context within which they are [00:30:00] operating and then nudge them towards non-default behaviors.

John Cutler: It's funny you had that conversation. I think there was a thread with Dee Hawk where he said, I talk about principles and these deep things, and you actually made the point where you said most people just want to get ahead.

You know, so talking about principles is a little tougher. I'm paraphrasing. I think I remember this in the back of my mind. But I thought what was interesting — that point — is it's also the toughest thing, right?

Mindset, principles, and tactics (and getting stuck on tactics) [00:30:29]

Shreyas Doshi: So, so a couple of thoughts there. One is it does depend on where one is at, right? There are three things that one needs to understand and use in order to get really good at something.

There's mindset, there's principles, and tactics, right?

People often will start with tactics. Which is here is a recipe for how to run this meeting, right? Here's the template for a product review. Here's a template for a product strategy doc, or what have you, right. Tactics are amazing. You need tactics to figure out the basics of a role and to be productive in that role and to learn by doing right. So tactics are really, really important.

What happens though, is for many people, they get stuck at tactics for the majority, if not the entirety, of their career. And that's where there is a problem. ¿Derecha? Which is once you have reached a certain degree of proficiency, you are not going to be able to, you know, seek the 37th tactic for doing this thing in order to actually be effective. Right. And, and so what you need at that point, is a better understanding of the principles. Because with the principles, what you will do is you'll know which tactic to employ. But even more amazingly, once you start understanding these principles, you can create your own tactics, right?

And then mindset is the most important thing. All of us know we need to do certain things. I know I need to write that PRD, why am I not writing that PRD? And instead, spending my time on Slack, and replying to email, and convincing myself that I'm being productive by doing that.

And there is a very good reason why I'm not writing that PRD. I need to understand myself. I need to understand what is really going on. What I'm really fearful of when I'm avoiding writing that PRD that I really should be writing. So there's much more to mindset than that, but the point is to achieve the highest degree of competence in a certain field — and particularly, I think, I can only speak for product management really to achieve the highest degree of competence in product management — you do need to understand each of these three extremely well.

Depending on the context, some of this is just not possible. Look, a lot of what I talk about the implicit background there is it's, we're talking about you know, like Marty Cagan calls it empowered teams, right? Where people are given the right tools, and the freedom to arrive at the right answer. Without taking tremendous personal risk in order to do so. I have been fortunate to have largely worked at organizations where the teams have just been empowered by default. My perspective comes from that. I frankly don't know what it's like, and what success is like, in environments where teams are not empowered, where individuals are not empowered. A lot of what I might say in that context can probably be boiled down to, grow as much as you can in the environment, such that now you will have the optionality to move to an empowered environment where you can really exercise your skill and achieve, hopefully greater potential.

But even as I say that I'm in two minds, right? Like, I feel like, okay, it makes sense to try to grow as much as one can, based on the cards one is dealt. ¿Derecha? It seems to make sense to do that. My own personal experience. I was very early in my career. I was in these highly disempowered teams. That's sort of what I tried to do, but again, I'm a sample size of one. What works for me doesn't necessarily work [00:35:00] for everybody. So that part of me says, okay, yeah, maybe this should work. But the other part I'm not quite sure about is just like is it possible in every environment where teams are disempowered? .

The basics/foundations for a high-performance team [00:35:11]

There are some basics that you need to have in order to have a chance of being a high-performance team or a successful team. Without those basics, yeah, with survivorship bias, you can find one team that managed to, against all odds, to succeed without those basics. But we can't really bank on that. Right. Because we have one life, we have, you know, we are single threaded. We can't run a hundred simulations and then just pick the winning simulation. Right. Or even like thread, like do three jobs on a given day. Right. And see which one, see which one worked out better. And just like, uh….

John Cutler: A multivariate job experiment. That's really

Shreyas Doshi: So, so we can't do that. So, you know, any kind of like, oh, there's all these problems and they, yet we succeeded. So learn from us. Right. Like there's very little to learn from that in my opinion. Because you're so single-threaded as a team, as a person, as a company it makes sense to just make bets that have a high expected value.

So let's assume that the basics are met. And what are some examples of basics that you have the right people in the right roles as an example, Right. It doesn't have to be the world's best people doing whatever, but at least there is some match to what the job is, and the people, who are supposed to do the job, as one thing.

You might even put a certain bar of empowerment. It doesn't necessarily have to be the highest empowered team ever. Because like that could have its own issues. But like a certain bar of empowerment. So anyway, you can make up some reasonable basics around, okay, any team or any situation needs to satisfy these basics, for it to have a shot at creating something that makes an impact, creating something that's remarkable.

Bueno. Now that these basics are covered, what's next? What do we need to do to increase the probability that we can meet our potential as a team? You know, as a thinker I have been thinking a little bit about a lot of my writing and what the general theme is. And one of the themes that I've been able to extract after the fact, is that really I'm trying to answer the following question in many different ways.

Why do teams with the basics met produce poor products? [00:37:31]

And the question is why do smart teams with sufficient resources– by resources I mean, money, all of that, right, not number of people necessarily– so why do smart teams with sufficient resources still produce mediocre or poor products? The current environment, again, sort of certainly you know, with startups and high growth tech companies, is that we all like to think we have smart teams. In this current funding environment, we do have somewhat sufficient resources in most cases, perhaps too many resources in some cases, and yet, many teams are not as successful as they ought to be.

And so why does that happen? ¿Derecha? I don't think I've answered that question just for myself. First trying to do this for myself, and then for everybody else. But I think the answer lies in a lot of different things that we just talked about. Around, oh, you know, one of the aspects of success is understanding the truth.

A lot of this goes back to things like decision-making, how do you collect inputs, how do you determine outputs? How do you get to those outputs? And then what are the right outcomes for us to achieve? Are we being sufficiently both logical and creative about how we get there?

I don't have an answer to sort of like the overall question of what distinguishes, you know, either poorly performing teams or high-performing teams and how are they different. I like to think about it as like, you know, this concept of assuming the basics are met, what needs to happen in order to maximize chances of success? And that's where I think context also plays a pretty large role.

Intentionality and stubbornness (with the company you want to be) [00:39:24]


John Cutler: What I've observed, at least in some of the companies that I admire the most is that someone is around who is just really stubborn about something, you know. They are stubborn about maybe engineering quality, or they're stubborn about connecting with customers. So anyway, that's, I'm offering that up as maybe an area that I'm looking into. That's what I've been thinking a lot about lately is stubbornness. We should connect our threads of research on this because I think it'd be interesting.

Shreyas Doshi: Yeah. I want to take that and do a live mashup of what you're talking about, uh, with this other idea that I [00:40:00] often bring up in conversations with startups, particularly as they're kind of starting to think about scaling that product development efforts. As they're thinking of adding product management. One of the questions I will often ask is what type of company do you want to create? Concretely. This is in the context of, you know, oh, I'm looking to scale my engineering team, looking to scale my product management. And I ask people to be quite intentional about what type of company you want to…

John Cutler: Because it's easy to give non-answers to that. I've heard a lot of non answers to that question.

Shreyas Doshi: Yes. And as it pertains to product work, right? Like what is going to be your focus? So that's one way to look at it. Do you want to be a customer focused company? Do you want to be an infrastructure focused company? Do you want to be a growth focused company? Do you want to be a product focus company?

Do you want to be a sales focused company…

John Cutler: I want it all…

Shreyas Doshi: And exactly, right!

Like, so that's what people say quite a bit. But then they start getting it, which is like, oh Yeah, Okay. I like, I need to be like, as a founder, my company is my product. And so I need to be quite opinionated or stubborn– so, this is where I'm connecting to your stubbornness– about what I want to create.

Because what happens is you, you can't have it all. And if you're not intentional about it, you are focused on something it's just, you don't know what it is and then there's confusion, right. Like for yourself and for others. And so you take examples, right? It takes time to go through this conversation because, you know, it's, it's an odd

John Cutler: It starts out very high level too. It's like…

Shreyas Doshi: Right, it's, it's very high level…

John Cutler: …y luego tienes que alejarte y tomar un poco de café y decir, espera, tenemos que bajar otro nivel.

Shreyas Doshi: Está bien. Derecha. Y, y así, lo que he observado es que como 10 minutos en 20 minutos en 30 minutos, hay un momento de bombilla típicamente para el fundador. Porque el fundador también suele estar muy cerca de lo que quiere hacer. Entonces, nuevamente, es una de esas cosas en las que hacer la pregunta es el principal valor agregado, no necesariamente la respuesta.

Pero si tomas ejemplos, se vuelve más claro, que es Google, como ejemplo, y ciertamente durante el tiempo que estuve allí, que fue hace como 10, 10 años, era en gran medida una empresa centrada en la infraestructura. Ese era su enfoque implícito. Cuando hablé con un ingeniero y dije, esto es lo que necesita el usuario, ¿cómo podemos construirlo? La respuesta sería, oh, eso es muy interesante. Es un problema asombroso. Voy a tener que construir esta infraestructura backend. Me llevará seis meses construir esta infraestructura de back-end. Y entonces tendrás esta característica. Y como persona del producto, por supuesto, esperaría, pero eso suena como mucho tiempo para que me guste, esta no es una característica masiva.

Como, no, no, no. Así es como hacemos las cosas, ¿verdad? Como, necesitamos tener la infraestructura. Y de nuevo, no hay elección correcta o incorrecta. También me gusta señalar eso. Derecha. Que es como, ya sabes, tienes Facebook, que es muy, al menos ciertamente me parece desde el exterior y de las personas con las que he hablado, es una empresa muy centrada en las métricas.

Toman decisiones basadas en lo que mueve las métricas en gran medida. Y es por eso que Google y Facebook funcionan de manera muy diferente. Internamente, operan de manera muy diferente debido a ese enfoque.

La elección fácil de hacer es oh, queremos centrarnos en el cliente. Y luego tengo que recordarle a la gente que, está bien, si dice que quiere ser una empresa enfocada en el cliente, pero está vendiendo software empresarial, sepa que con el tiempo, en lo que realmente se convertirá es en un empresa enfocada en las ventas. Y nuevamente, hay ejemplos de compañías tremendamente exitosas que se enfocan en las ventas.

Entonces, no estoy diciendo que sea necesariamente una elección incorrecta. Pero solo siendo intencional al respecto y vinculándolo nuevamente a su punto de terquedad, esa es una forma de ver las cosas, ¿verdad? Que es como, así es como hacemos las cosas. Sé que suena más negativo de lo que debería ser, o esto nos funciona, ¿no? Esto funciona con la cultura que tenemos. Esto funciona con las personas y las habilidades que hemos contratado, etc. Y eso puede ser bastante poderoso, especialmente si lo haces intencionalmente.

Inteligencia analítica y creativa [00:44:14]


John Cutler: Un par de veces en nuestra conversación, mencionó esa palabra analítico. Y luego ha hablado de la alternativa a eso, tal vez una inteligencia creativa. ¿Podrías profundizar un poco en eso?

Y específicamente, estoy pensando en mi trabajo diario, donde pensamos en la medición. Y una cosa que he observado es que hay una gran diferencia entre usar la medición para controlar a las personas, o controlar la narrativa, u obtener la respuesta perfecta, y usar la medición para aprender. Se sienten muy, muy diferentes.

¿Cuál es la diferencia entre la inteligencia analítica y la inteligencia creativa en tu mente?

Shreyas Doshi: En la raíz se construyen unos sobre otros.

Sin embargo, no es así como la mayoría de la industria lo ve. Y creo que las prácticas en varias empresas, incluidas las empresas [00:45:00] altamente exitosas, a menudo tienden a ver una como mejor que la otra. Y por lo general, y nuevamente, mi contexto es mucho de, ya sabes, empresas basadas en el valle o empresas similares al valle, sin importar dónde se encuentren geográficamente, es que de alguna manera tendemos a ver las razones analíticas como extremadamente importantes y correctas.

Tendemos a descartar la creatividad del producto, y tendemos a descartar el instinto y el juicio y varios otros tipos de aspectos.

John Cutler: Hay una dualidad, ¿verdad? Como también exageramos mucho el instinto de las personas, los instintos de ciertas personas, pero sé lo que quieres decir.

Shreyas Doshi: Sí. Así que ese es un tipo de problema interesante que creo que, de nuevo, se remonta a la pregunta central de por qué los equipos inteligentes con los recursos adecuados aún producen productos mediocres o deficientes. Lo que olvidamos es que muchos equipos y muchas culturas empresariales hacen que sea muy difícil para las personas generar ideas creativas. Incluso de nuevo, en empresas muy exitosas en general.

¿Dónde comienza mucho de esto? Comienza en la reunión, ¿verdad? Así que tomas tu reunión típica de producto a cualquier nivel. En la mayoría de las empresas de este tipo, dará la impresión de ser mucho más competente si muestra cinco gráficos diferentes. Muestras un par de tablas. Y luego algunas ideas cualitativas. Y luego dices, y por lo tanto, esto es lo que debe suceder. No creo que haya nada de malo en nada de eso. Derecha.

Pero lo que sucede con ese enfoque y esa mentalidad es que, por lo tanto, las conclusiones o las recomendaciones son bastante limitadas. Están en esta caja. No sabes que en realidad son como en esta caja. Pero lo son, ¿verdad? Ahora, si permitieras la inteligencia creativa de la misma manera, lo que sucedería es que las conclusiones contendrían algunas ideas extravagantes, ¿verdad? Como algo que no se sigue estrictamente de los datos, ya sean cualitativos o cuantitativos. Tal vez incluso esté en ese sobre de, oh, no tenemos una fuerte convicción sobre esto, pero deberíamos intentarlo. Lo que sucede, de nuevo, en la reunión, en una reunión de revisión de productos, es que el gerente de producto se confunde o se ve extraño cuando presenta una idea creativa.

O cualquiera, solo estoy eligiendo el gerente de producto como un rol, pero el ingeniero o quien sea. En segundo lugar, es probable que luego reciban comentarios del gerente de Me gusta, y la forma en que se enmarcaría como no tanto, no traigas ideas creativas, porque nadie quiere decir eso, sería como, necesitas respalda tu propuesta con datos.

Necesita respaldar mejor las cosas, y esa es la retroalimentación que le estoy dando como gerente, ¿verdad? Ese fenómeno ocurre muy regularmente incluso dentro de empresas muy exitosas. Y eso se interpone en el camino de que los equipos puedan crear estos productos que realmente alcancen el potencial, eh...

John Cutler: Alguien dijo recientemente que tenemos demasiados hipopótamos para tomar decisiones en mi empresa. Tenemos que usar datos, ¿verdad? Tenemos que usar datos para hacer que los hipopótamos desaparezcan. Y luego dije, bueno, ¿qué va a pasar cuando tengas una idea visceral?

Y dijeron, bueno, bueno, por supuesto, ya sabes, por supuesto que vamos a utilizar el mismo enfoque. Tenemos que tener todos los datos para hacer eso. Y yo estaba como, mira, tu problema no son los hipopótamos. Porque eventualmente vas a querer tener ideas creativas.

Si solo tienes una idea, es terrible. Si tienes 50 ideas, eso es paralizante. ¿Tienes tal vez tres? Y mi amigo Dan North dijo, no, quieres siete. Porque la primera, la primera es tu idea, la segunda dos, tres o cuatro ideas básicamente sustentan tu idea. Así que quieres siete porque en el cuarto, el quinto, el sexto y el séptimo son cuando estás saliendo de tu zona de confort.

Nivel de impacto, nivel de ejecución y nivel de óptica [00:49:13]

Shreyas Doshi: Sí. Un marco que creo que es un marco muy fundamental que abarca la mayoría de los contextos de productos, y ciertamente todos los contextos de productos con los que me he encontrado, que creo que debemos reconocer mejor, es lo que llamo el marco fundamental del trabajo del producto.

Así que hacemos todo este trabajo de producto, ¿verdad? ¿Cómo debemos pensar en esto? ¿Cómo pensamos sobre el trabajo de este producto? La idea que tuve recientemente fue que hay tres niveles de trabajo de producto. Está el nivel de impacto. Está el nivel de ejecución. Y luego está el nivel de la óptica. Y muchos desafíos [00:50:00] dentro de los equipos de productos, culturas de productos, se deben a un desajuste o una mala comprensión del nivel en el que estamos teniendo una discusión. O el nivel en el que estamos operando.

A menudo encuentra que una persona en el equipo está operando y pensando en el nivel de impacto. Y otra persona está pensando en el nivel de ejecución. Pero no están hablando de eso. Están litigando las minucias de la situación, ¿verdad? Entonces, un ejemplo clásico es un PM que trabaja muy duro. Por así decirlo, un PM que opera en el nivel de ejecución trabaja muy duro contra viento y marea.

No se les repartieron buenas cartas, pero hicieron que este producto sucediera, ¿verdad? Como el producto es una realidad. Son felices. El equipo está feliz. Ingeniería, gestión de productos, diseño, ciencia de datos, todos ellos, personas que trabajan en el producto central, están muy emocionados de construir algo.

Derecha. Y lo llevan a su revisión ejecutiva, ¿verdad? O una revisión de lanzamiento. Por supuesto, hay alguna demostración involucrada en la revisión del lanzamiento. Y nuevamente, las tácticas no importan cómo se hace de forma sincrónica o asincrónica. El punto es que se revisa. Tiene un ejecutivo de producto que está operando en el nivel de impacto. Entonces, el ejecutivo de producto mira el producto y el mensaje básico es que esto no es lo suficientemente bueno.

John Cutler: El medidor de amenazas se activa.

Shreyas Doshi: Los niveles de cortisol aumentan.

John Cutler: …aumentar…

Shreyas Doshi: Y el PM está frustrado, tal vez el gerente de PM también esté confundido. ¿Te imaginas toda la dificultad que tuvimos que enfrentar para llegar hasta aquí? Solo se nos debería permitir lanzar esto. Sé que son todos estos defectos, pero no, no, no, no. Deberíamos tener permiso para lanzar esto.

Entonces, el problema aquí es el ejecutivo: están operando en el nivel de impacto y están pensando en el impacto para la marca, correcto, de lanzar un producto con esta calidad, que es decir más bajo que el nivel que han tenido. . Y esa es una situación interesante porque la gente empieza inmediatamente a hablar de arreglos, ¿verdad?

Lo cual es como, oh, ya sabes, tal vez cambiemos esta una o la segunda cosa, nuevamente, es importante hablar de todo eso, pero primero es importante reconocer esa falta de coincidencia. Y también diré que será difícil para el PM, el líder de ingeniería o el líder de diseño. Va a ser difícil para la gente allí señalar esto, cierto, solo desde el punto de vista de la seguridad psicológica.

Entonces, la forma en que los ejecutivos pueden operar mejor, y esto se aplica a las personas en todos los niveles, es reconocer por qué el equipo está orgulloso de lo que han hecho, en realidad lo han ejecutado contra grandes probabilidades. Y están operando a ese nivel de ejecución. Y luego grite explícitamente, en lugar de decir, ah, esto no es lo suficientemente bueno, o no cumple con el estándar o lo que sea, esto es excelente en el nivel de ejecución, esto se queda corto en el nivel de impacto, ¿cómo podemos lograrlo? saber, un mejor resultado aquí?

Lo último que diré sobre esto, como parte del ejemplo aquí, es que en muchos lugares, las personas están optimizando el nivel óptico cuando están trabajando con productos. El director ejecutivo, el fundador o un poderoso ejecutivo que tiene un instinto, o alguna idea creativa, que la gente simplemente se traga. ¿Derecha? Bob dijo esto, así que trabajemos en eso porque esto es realmente...

John Cutler: …y fueron muy decisivos. Es como, bueno, por supuesto que fueron decisivos. Son el director ejecutivo y todos los están escuchando.

Shreyas Doshi: Luego, la otra cosa es que las conversaciones paralelas son, a menudo, sí, no creo que esto vaya a funcionar. Pero como, esto es lo que Bob quiere, así que vamos a hacer esto. Y no siempre tiene que ser de arriba hacia abajo por cierto. ¿Derecha? Al igual que a veces también es la dirección opuesta. ¿Derecha? Construyes algo y lo enmarcas como si fuera más exitoso de lo que realmente es para administrar la óptica.

Así que no digo que la óptica sea mala. En realidad, necesita administrar una cierta cantidad de óptica, solo para que pueda expresar fielmente el impacto de su trabajo y la calidad de su ejecución. El nivel de la óptica debería ayudar a los otros dos niveles. Y entonces necesitas hacer suficiente trabajo allí. Pero hay muchos equipos que optimizan principalmente para la óptica.

La gente habla de incentivos y de cómo la gente básicamente seguirá los incentivos. Y así. No uso el lenguaje de incentivos. Creo que una cuestión más fundamental aquí es, en qué medida su cultura y su organización obligan a las personas a gestionar hacia la óptica, en comparación con la gestión hacia la ejecución o la gestión hacia el impacto.

Sesgos cognitivos y vocabulario compartido [00:54:37]

John Cutler: Entonces, una parte de mi viaje con el mundo del sesgo cognitivo, porque en cierto punto estaba súper metido en eso. Empecé a tratar de investigar formas en las que hemos sido efectivos para contrarrestar el sesgo cognitivo, incluso cuando lo sabemos. Y no ayudó mucho a mi capacidad para combatir la falacia del costo irrecuperable cada vez que la encontraba. ¿Qué ha visto que no funciona y qué ha visto que funciona en términos [00:55:00] de tratar de contrarrestar estas cosas?

Shreyas Doshi: Creo que se trata del vocabulario compartido que creas para el equipo. Y creo que el vocabulario compartido es solo otro tema que es mucho más amplio que los sesgos cognitivos, que creo que es tan vital.

Si desea que su equipo sea saludable, o más saludable, tal vez piense en cuál es el vocabulario compartido de su equipo en torno al trabajo que realiza. Y no me refiero solo a las palabras de moda de la industria como Scrum o cualquier otra cosa, ¿verdad? Como, quiero decir, no, no, no. ¿Cuál es el vocabulario que no está viendo como parte de la literatura estándar de gestión de productos, pero que va a compartir con el equipo? ¿Por qué funciona esto en el contexto de los sesgos cognitivos? Es muy difícil para alguien decir Bob, estás siendo víctima de una falacia de costo irrecuperable, o heurística de disponibilidad, o lo que sea. Es muy difícil en la mayoría de las organizaciones que alguien sea capaz de...

John Cutler: …lo que estás diciendo no es una reunión de tarifa estándar, no es como, gracias, sí, me gustaría señalar la falacia del costo irrecuperable… la reunión de zoom se cierra bastante rápido. Si esa persona comienza...

Shreyas Doshi: ¡Exacto! Uh, y es como, oh, esta persona no funciona bien con la gente. O lo que sea. Derecha. Como la gente consigue...

John Cutler: …han leído demasiados libros. Oh,

Shreyas Doshi: Se les asignan etiquetas. Así que creo que es importante darlo a conocer. Por eso no hablo de sesgos cognitivos individuales. Suelo hablar de nuestros sesgos cognitivos a nivel de equipos. Derecha. Porque entonces es mucho más fácil tener esa conversación de que, como equipo, esto nos puede pasar. Podemos caer presa de la falacia de la orientación de la ejecución. Que es donde decidimos hacer algo que sabemos que es fácil de ejecutar, aunque puede que no sea el equipo adecuado para ejecutarlo, pero nos da la satisfacción de comenzar. Y la satisfacción de crear algo.

Una vez que lo hagas saber a todos, y segundo como líder, la responsabilidad de lo que voy a decir recae completamente en el líder, es decir, miren, voy a ser presa de esto. Y como grupo, podemos ser víctimas de esto. Solo quiero establecer la expectativa de que hablaremos de esto. Y lo marcaremos cuando veamos que esto sucede.

No es una debilidad si marcamos esto. En realidad es lo contrario de eso. Que somos capaces de ser conscientes de lo que realmente está pasando, y quizás tomar una mejor decisión o llegar a una mejor conclusión. Entonces creo que el vocabulario compartido, y luego lo que acabo de decir es responsabilidad compartida

En general, odio la palabra responsabilidad, pero ese es un tema completamente aparte. Pero me gusta en este contexto, que es una especie de responsabilidad compartida como equipo en torno a recordarnos unos a otros, y recordarnos a nosotros mismos como equipo, sobre los errores que podríamos estar cometiendo. O una falta de claridad que podamos tener.

Como ejemplo, está este proyecto que estaba haciendo recientemente, que era un proyecto extremadamente ambicioso con muchas incógnitas. Compartí con el equipo por adelantado, en realidad, en ese caso, compartí dos cosas. Uno estaba relacionado con el sesgo cognitivo, que es, mira, es probable que seamos presa de estos, estos, estos sesgos cognitivos o sesgos cognitivos del equipo.

Y así que seamos conscientes de eso. Lo segundo que señalé también fue: los detalles no son importantes, pero era una situación muy compleja, con varios equipos involucrados, y esos equipos no habían trabajado mucho entre sí. Eran como trabajar por primera vez.

Y entonces les compartí que una de las principales cosas que se interpondrán en nuestro camino aquí es que no seremos directos ni abiertos entre nosotros, especialmente a través de los límites de este equipo. Eso probablemente, más probablemente, hará que este proyecto no funcione que cualquier tipo de error analítico que cometamos.

Lo hice aún más explícito con ese grupo. Estoy más preocupado por nuestra capacidad para trabajar bien con los demás, ser directos y comprender las perspectivas de los demás, que cualquier otra cosa. Cualquiera de los otros tipos de cosas analíticas de las que estamos hablando, que es como, oh, cómo encajamos en estas tres opciones de navegación dentro de este espacio limitado o lo que sea. Eso no va a determinar nuestro éxito. Lo que va a determinar nuestro éxito es si estamos dispuestos a tener conversaciones difíciles entre nosotros sobre este tema. ¿Y estamos dispuestos a escucharnos unos a otros y las perspectivas de los demás? La otra táctica que me gusta es, también señalo, también quiero decir que tal vez estás pensando que esta es una conversación tonta porque es muy esponjosa, ¿verdad?

Como si no fuera el material analítico. Pero si estás pensando eso, mi [01:00:00] pedido es que por favor hables conmigo al respecto. Todos tenemos que ser abiertos unos con otros. Si está descubriendo que este no es un uso útil del tiempo, entonces eso es lo primero sobre lo que debe estar realmente abierto. Y entonces…

John Cutler: Te estás anticipando a su escepticismo de que los estés instando a... ¡Me gusta!

Shreyas Doshi: Sí.

John Cutler: Estás tratando de cubrir todas tus bases aquí, esencialmente.

Shreyas Doshi: La otra cosa que tenía que hacer en esta situación es, porque nuevamente, no había trabajado con algunos de los miembros del equipo con los que íbamos a trabajar, entonces establecí uno a uno. con algunos de los miembros clave del equipo, solo para enfatizar esto nuevamente. Es como, mira, esta es mi preocupación como líder del equipo.

Y, en general, llegar a conocerlos lo suficiente como para que sientan la capacidad y la voluntad de abrirse y compartir cuando las cosas no funcionan. Entonces, ya sabes, este es un ejemplo de ir en contra de los valores predeterminados. En general, evito este tipo de controles individuales regulares, ¿verdad? Seguimos agregando y, en cierta medida, se hace cargo de su calendario.

John Cutler: No habrías hecho muchos amigos si hubieras hecho eso todas las semanas durante los últimos cinco años. Creo que la parte brillante de esa respuesta es que cuando las personas aprenden sobre los sesgos cognitivos, es una locura. Lo que hacen es que siempre están como, bueno, esto explica el comportamiento loco de todos los demás. Ajá. Ahora sé por qué los ejecutivos se comportan como son. Es como si todos primero, al pensar en los sesgos cognitivos, todos experimentan un sesgo de atribución fundamental, ¿verdad?

Shreyas Doshi: Creo que si no quieres creer si, como individuo o como equipo, no quieres creer en la mayoría de los sesgos cognitivos, tal vez esté bien. Siempre y cuando creas firmemente en dos: el sesgo de confirmación y el sesgo de atribución fundamental.

Tratar los tableros como un producto [01:01:51]

John Cutler: ¡Sí!

Cambiando de tema solo por un momento, he querido preguntarte esto durante mucho tiempo. Tenías esa idea de tratar los tableros como un producto. ¿Cuál fue la inspiración para eso, ese pensamiento?

Shreyas Doshi: Esa fue una colección de algunas observaciones diferentes que hice a lo largo de los años sobre cómo se usan los tableros. Y cómo la gente en general, los equipos de productos, piensan en los tableros.

John Cutler: …las personas altamente analíticas de las que estamos hablando.

Shreyas Doshi: Sí. Y es como, oh. se supone que tienes un tablero. Muy bien, tendré un tablero. Así que permítanme compartir un par de esas observaciones que hice en el camino.

Primero, hay muchos PRD que se escriben sobre una función o producto no trivial, que no cubren cómo se verá el tablero para esta función o para el producto. Y está bien. Como, lo que estoy pidiendo no está aquí como una maqueta detallada.

Muéstrame una lista con viñetas, ¿verdad? Aquí están las métricas que vamos a rastrear para comprender las métricas de uso, que es como, ¿cómo se usa esta función? ¿Qué están haciendo los usuarios con esto? Y, el segundo es el impacto. Hay mucho enfoque en las métricas de impacto a veces y no lo suficiente en las métricas de uso.

John Cutler: Absolutamente.

Shreyas Doshi: Pero como, yo diría que como...

John Cutler: No lo llame métrica de éxito. ¡Porque entonces habla de seguridad psicológica! Todo está hecho en ese momento. Indicador clave de rendimiento, ya sabes, es...

Shreyas Doshi: Sí.

John Cutler: …no importa en este punto.

Shreyas Doshi: De nuevo, el vocabulario es muy importante. Ese es un gran punto. Debe ser propiedad del gerente de producto o de quien esté desempeñando esa función.

John Cutler: Necesitas mucho conocimiento del dominio para conseguir eso, cierto...

Shreyas Doshi: Correcto.

John Cutler: …está la naturaleza única del uso.

Shreyas Doshi: Y la mayoría, la mayoría de los equipos tienen la otra categoría de métricas, que es la métrica de salud. Porque, por lo general, los equipos de ingeniería se asegurarán de tener la instrumentación adecuada y el tablero adecuado para eso.

Esa es la primera observación, no lo especificamos adecuadamente. derecho. Entonces, lo segundo es supongamos que un equipo especifica eso, y un tablero, o algún correo electrónico de métricas, no me importa de qué se trate. Como algo que se construye y ahora comienza a darte una idea de las cosas que importan. Cómo la gente lo usa, cuál es la adopción, cuál es el impacto, eso es todo, genial.

La segunda observación que hice es que nadie está mirando ese tablero.

John Cutler: Puedo confirmar esta dinámica basada en alguien que ofrece una de estas herramientas que muchas de ellas son como árboles que caen en el bosque. Hay cementerios de tableros. Pongámoslo de esa manera.

Shreyas Doshi: Seguro. Si eres tú y tu equipo, no te sientas mal. Esto es el 90% de lo que he encontrado en diferentes puntos. Derecha. Sí. Hemos dedicado todo este esfuerzo a crear este tablero. Casi nadie lo está mirando.

Entonces, ese fue el segundo tipo de observación. Cuando me di cuenta de esto, lo que me di cuenta es, oh, espera un minuto. No le estamos haciendo a nuestro tablero de métricas, [01:05:00] lo que decimos es lo correcto para nuestros productos. Así que hay un cierto tipo de autorreferencia aquí. Es decir, si creamos un producto, sabe claramente que lo correcto es realizar un seguimiento de su uso, realizar un seguimiento de las métricas, etcétera.

Entonces, si está viendo el tablero, que le brinda información sobre su producto, ¿por qué no verlo como el producto en sí? Y realice un seguimiento de las métricas de uso de su tablero. Como un simple contador, por ejemplo. Cuántas personas han visto este tablero que dedicamos mucho tiempo a crear la semana pasada.

¿Derecha? Algo tan simple como eso, solo un recuento de vistas, como ejemplo. Y luego puedes mirar eso y ver, oh, espera un minuto, en realidad nadie está mirando las métricas. Así que eso crea dos posibilidades. Una es que no es útil en términos de conocimientos o toma de decisiones. O hay algún problema, cierto, como con nosotros y así tenemos que resolver. Pero solo puedes comenzar a hacer eso si piensas en ello como un producto, ¿verdad?

Una vez que comience a pensar en el tablero como el producto, por supuesto, creará requisitos para el tablero y lo hará parte del PRD original. Que es como, esto es lo que necesitamos rastrear. Es por eso que necesitamos rastrearlo. Así es como lo rastrearemos. Y luego, obviamente, instrumentará las cosas en el tablero de manera que comprenda su uso y así sucesivamente.

Y lo último que diré es que gran parte de todo esto no es intención ni competencia ni nada más. No creo que sea porque la gente sea incompetente que estas cosas sucedan. Creo que es porque es difícil. Creo que en realidad es tan simple como la fricción, ¿verdad? Esta es otra cosa que tienes que pensar en hacer durante tu ajetreado día. Sabes que es lo correcto. Para ver sus métricas de uso de vez en cuando. O al menos consúltalos cuando vayas a tomar la siguiente decisión.

Pero hay fricción. Hay una carga cognitiva que tienes que manejar. Y ahora, nuevamente, pensando en ello como un producto, ahora puede comenzar a pensar en términos de cómo eliminar la fricción. Porque eso es lo que hacemos en nuestros propios productos, ¿verdad? ¿Pensamos en cuál es la fricción del usuario y cómo la eliminamos?

Y eso lleva a posibilidades interesantes. Como uno de los hábitos que he tenido durante muchos años, en este momento, tengo mis pestañas pin en Chrome. Y tengo mi correo electrónico, mi Slack y mi calendario, que están fijados. Una de las otras cosas que está anclada es mi tablero de métricas principal. Así que está ahí. No tengo que abrir una nueva pestaña, escribir ninguna URL, simplemente está ahí. Otra cosa que he notado es que a la gente le encantan las métricas de correo electrónico. ¿Por qué? Porque elimina la fricción, ¿verdad? Simplemente aparece. Y existe este tipo de contrato que al menos hemos hecho con nosotros mismos de que deberíamos mirar los correos electrónicos. Entonces, lo que termina sucediendo es que las personas miran mucho más de cerca las métricas que reciben por correo electrónico que, más o menos, las métricas que tienen que buscar de manera proactiva.

Entonces, a menudo, para proyectos importantes, diría, oh, ya sabes, enviemos también un correo electrónico de resumen. Puede ser tan simple como algunas estadísticas de alto nivel y solo un enlace al tablero. Incluso ese enlace que se le envía por correo electrónico lo hará mucho más fácil para usted y eliminará la fricción. Frente a tener que pensarlo y hacerlo.

Calendarios llenos, reactividad, identidad propia y hábitos positivos/negativos [01:08:20]


John Cutler: Cuando ves estos calendarios de personas y ves estos PM que están en modo reactivo todo el tiempo. Que ni siquiera tienen un momento para pensar en estas cosas. ¿Cuál es el primer consejo que les das? ¿Cómo reinan esto?

Shreyas Doshi: Pasé los primeros cinco años de mi carrera de PM en un estrés extremo y en un grado considerable de estar a la defensiva, todo el tiempo. Necesito asegurarme de que las cosas no se desmoronen. Eso es todo lo que estoy haciendo, y eso está consumiendo toda mi energía. Y creo que en gran parte se debe, por supuesto, a que probablemente era mucho menos competente en el papel. Y entonces las cosas solían llevarme más tiempo, y así sucesivamente. Y entonces no quiero descartar eso, ya sabes, que hay una curva de aprendizaje, y esa curva de aprendizaje tiene un costo. Y es un viaje por el que todos deben pasar. Derecha. Asi que. Sí.

No creo que sea necesariamente algo malo. Usas la palabra hábito y creo que ahí está el problema. Lo que sucede es que debido a estos primeros años, nuestros años formativos como gerentes de producto, adquirimos ciertos hábitos. Suponiendo que, en realidad, somos bastante buenos en lo que estamos haciendo, vemos el éxito. Y entonces ciertamente piensas, está bien, sí, parece que estoy haciendo lo correcto. Y entonces debería hacer más de esas cosas. Realmente ayuda tener reuniones individuales con cada ingeniero del equipo semanalmente, verificar con ellos lo que está sucediendo y luego también conectarse con ellos a nivel personal, etcétera, etcétera. Así que voy a hacer más y más de eso. Estupendo. Funciona cuando tienes 10 ingenieros en el equipo, ahora tienes más alcance. Ahora hay 20, luego hay 30. [01:10:00] ¿Qué, qué haces?

John Cutler: ¿Verdad? Luego, mientras tanto, se enorgullecen de sí mismos, se identifican a sí mismos por tener tan buenas relaciones con todos los ingenieros. El agujero negro uno a uno de...

Shreyas Doshi: sí. Entonces, John I, y creo que desencadenó algo interesante, que es, creo que quizás son dos cosas. Es su hábito e identidad. Esto es lo que soy. Así es como hago las cosas, ¿verdad? Oh, ¿esa cosa de la que estás hablando, o esa cosa de la que está hablando esta otra persona?

No, no, no, no, eso no me funciona. Derecha. Como soy diferente. Esta es mi identidad, así es como opero. Así que está el hábito y la identidad. Y veo todo el tiempo, personas en situaciones en las que es completamente inmanejable. No saben qué hacer.

Simplemente piensan que así es como es. A veces, sus gerentes les dirán, sí, así es como es el trabajo de PM. Mira mi calendario, ¡es aún peor! Y luego está esta pequeña comparación también, que es como, oh, de quién es el peor calendario. Y como, esa persona es más un PM, ¿verdad?

Esto es muy difícil debido a la cuestión de la costumbre y la identidad. Es difícil para la gente aceptar que hay un camino alternativo aquí. Si piensas en el público, ellos están escuchando esto, siempre que se publique. Sin duda habrá un grupo de personas que dirán, sí, lo que sea que se discuta aquí no se aplica a mi situación. Y no se aplica a mi empresa por mi jefe, por esta razón, porque mi equipo es diferente, porque sea lo que sea que sea diferente, tengo ambiciones más grandes, lo que sea. Entonces, lo que diría es que esto no se puede resolver hasta que acepte que en realidad hay una mejor manera.

You have to understand that you want to solve this problem, versus thinking this is the way it is. But once you start entertaining that thought, that there are other ways that this problem can be solved or at least should be mitigated, now we can talk. ¿Derecha? So now we are at a smaller part of the audience that is really stressed, but it's perhaps more open to sort of exploring those ways.

And then what I would say this goes back to the role of a product manager and particularly the role of a product leader. Remember we talked about building self managing teams. Derecha. Well, what happens when you actually build self managing teams? You have to do less management, right? Because they're self managing. That's sort of the goal. Now, it doesn't solve the problem because how do we get to the goal?

The way one needs to think about these situations is you know, yes, I can stay on top of everything. And you know, in some cases, like we talked about, the context requires you to stay on top of everything. But, you don't have to make that your default, and you don't have to do it in every single situation.

So one of the things I like to tell, especially new managers, is assume there are things you are not going to be on top of. Because then you will have to go to every single meeting. You'll have to accept every single input in order to, sort of, figure out what to do.

So assume that's not going to happen. And what you need to do is to figure out ways in which now you're going to get those inputs through people on your team. And you are going to organize your one-on-ones in a way that you're able to get those inputs. You're, uh, you're going to organize rituals on your team, whether it's product reviews, or other rituals on execution check-ins or what have you, in order to get the right signal .

This is all easy for me to say, but it is hard to do, and it requires practice. And it requires trying to identify your unique style of doing it, et cetera, et cetera. But the beautiful part, when you cannot like, do this, and do this with some degree of success, is now all of a sudden you are able to be much more useful, and much more effective, right?

You are able to get more clearly to the thing that matters, right? You are able to help your team members. You are kind of like coaching them through experience around expressing to you the stuff that matters. Derecha. And then you are able to also give them the independence, and the leeway, to be able to operate on their own versus kind of handling them through all of this.

Improving the current situation (and gap vs. present thinking) [01:14:24]

So, concretely, the common sort of argument I hear is yeah, yeah, things are horrible right now, but it's because I don't have a full team. Like I have this four or five head count. Once I get these people, and get them to be productive, things will be better. And guess what happens? You get those four or five engineers on the team, or four or five PMs on the team if you're a PM manager. Situation is worse, not better. But at that time, it's like, oh, you know the problem is we are not organized properly. My team should not [01:15:00] belong to this organization. It should be in this other part of this organization. And that's what's creating the problem for me. You know, so it's like this, kind of, basically we are on the treadmill forever right?

I'm not discounting the validity of these reasons. What I am suggesting is that regardless of external factors, which we should try to improve, and we should feel high agency towards making the organization better, and improving whatever situation we are in. But we need to also be very cognizant of how I can best manage the current situation I'm in. Versus like, basically I noticed that especially the managers and product managers that tend to get extremely stressed, and let the work affect all parts of their personal lives and whatnot is… they're constantly looking for the next thing that is outside of them that's going to fix this issue. And then that results in burnout, that results in frustration when it doesn't happen. And they don't pay enough attention to, okay, given this current situation, what do I need to do differently?

John Cutler: My friend Jabe Bloom has this interesting thing, which is gap thinking versus present thinking. And he makes the point that standard business school, standard consulting is all about the gap. What's the current thing? Exactly where do we need to go? How are we going to get across that particular gap?

Like that's a very tried and true way to think about it. And then he presents this other idea that present thinking is not adverse to thinking ahead. It's like, what's going on right now? What do we visualize as the better version of right now? Where do I have agency to act right now? Instead of just the gap, you know, it's like there and you have to go across it. It's kind of like little mini gaps, right. But the one part, the one thing you said that really resonates there is, you know, in some ways, as humans by, gap thinking is always a way to also “other” the problem.

It's the tendency of people to combine gap thinking with fundamental attribution bias, which is like, not only is there a big gap that we need to get across and there's the perfect plan to get across it. But the road involves other things in the org that have to happen, et cetera, to make it to it.

So I don't know if that's, I've liked that distinction between gap thinking and present thinking. One thing that's hard is that a good chunk of modern business is centered around gap thinking. What's the gap, bring me solutions, not problems, you know, like how are we going to get across the gap all the time? Asi que…

Shreyas Doshi: Yeah, that resonates a lot. One other thing I want to share around this topic of PM stress and this constant feeling of inadequacy, and I'm not doing enough to move the product forward, and and my schedule is crazy, and I'm just not able to perform at the level I need to et cetera, et cetera. All of which, by the way, again, a common theme is this was me for the first five PM career. And I used to share all of this with my wife all the time and like, you know, huge kudos to her to just like, listen…

John Cutler: She taught you how to listen…

LNO: Leverage, Neutral, and Overhead Tasks [01:18:10]

Shreyas Doshi: Exactly. So I think one key thing that was a turning point for me was the understanding of —uh, and I don't even know where I read it, it was some blog posts that I read and what I'm about to share is a paraphrasing of that, I can't find the blog post anymore for whatever reason— but it's what I termed as the LNO framework for PM effectiveness. Which is the observation that there are three kinds of tasks that I tend to do as a PM.

There's a leverage task, there's a neutral task, and then there's an overhead task. The leverage task, you know, as the name suggests, gives greater than what you put in. The neutral task will give you the same. And the overhead tasks will give you less. What most PMs do, and certainly what I did during those highly stressful days of my career as a PM, was I approached every task, any given task in the same way. Which is, oh, I'm going to try to do an awesome job. I was like some, you know, inner perfectionist, et cetera, et cetera. So I would spend a ton of time without understanding whether this is a leverage task, a neutral task, or an overhead task, right?

And, and what's right for the company you work for– and certainly for your team and very likely for you– is for you to understand that upfront. And then, you know, adjust the amount of energy and the amount of time based on that understanding. And I think what that does is, it certainly did for me, is it means spending more time and exerting more energy on certain things.

Because now you understand that this is a leveraged task. So instead of spending two hours on writing that, you know, completing that PRD, maybe you ought to spend four hours today to do that. Now of course, that extra two hours have to come from somewhere else. So find out [01:20:00] what are your neutral tasks or overhead tasks.

And so one example of, you know, usually a neutral, sometimes an overhead task, is you will get some requests for certain reports from finance, like, what's our 24 month projection for how the product is going to– like how much headcount do you need or whatever. Now, you know, I look at those things and, you know, there's the perfect way of doing it. And I see all these sometimes PM leaders, especially going to these meetings, and talk about all the analytical stuff of what's going to happen in September of 2022. And, November of 2023. And people are having all these discussions. Again, it goes back to, oh, we think we, we have certainty around what's going to happen.

They end up spending a ton of time on all of these things. And, what I typically do is like, again, usually– you know, sometimes it's an exception– but usually when I get these requests, I get them done in five, 10 minutes. Derecha.

Like these, these are the assumptions. Here you go. And if you need something more detailed, then please let me know how this is going to materially change, you know, things from a budgeting perspective or something else.

So that's just an example of where you kind of get back that time. And what I found is that as I started doing more and more of this, and on a tactical level what I would do is I created the to-do list, I would actually prefix the task just as a reminder to myself with L, N, or O .Right?

So when I started doing the task, I was like, okay, this is a leveraged as to how I'm going to approach

Conclusion [01:21:23]

John Cutler: I love that. I love ending with something really actionable. And so that's something that I'm going to do with the rest of my day too. To do these things. But, Shreyas, I wanted to thank you. We could have gone on for hours cause there's just so much, uh, so many questions I have. And I'm amazed too, about your ability to weave in and out your frameworks too. So you've actually inspired me thinking about how to be more actionable in these types of conversations. Because you've left people with specific frameworks, but we also went really deep into everything about intentionality, and culture, and stuff. So I really, really appreciate it.

And I'm super grateful for the opportunity to chat with you. And yeah, we'll stop now. But we should do it again at some point. Maybe people will have questions. Maybe we could do a follow-up like rapid fire, uh, answers to those questions if that would work for you.

Shreyas Doshi: Yeah, I would love that this was a blast. Tienes razón. We could have gone on for hours and this is fun stuff. So thanks for that.

John Cutler: I want to leave people with that one thing that Shreyas opened with. We've both probably learned the hard way. So when you see us tweeting assume that we've made the mistake 55 times, and we've had to work through it, context always matters, that would probably be like a footnote on those things. And three, I loved your statement too. You know, if you're in an unhealthy environment, you know, don't just assume you can just jump in. I think taking care of yourself, that's my theme, you know, as the tail end of the pandemic, is that people need to take care of themselves too.

Product Analytics for Dummies