Cuaderno de Producto
386 subscribers
23 photos
7 files
82 links
Contenidos, publicaciones, tuits, frameworks… sobre Product Management. Todos los links en producto.antoniorull.com
Download Telegram
Llamativo este hilo de Jon Youshaei (ex Product Marketing de vídeo en Instagram) que nos permite intuir algunos de los posibles futuros para BeReal, esa app que se puso muy de moda hace unas semanas y que puede estar haciendo temblar un poco a Instagram.

Jon lo analiza desde su experiencia habiendo trabajado en Instagram pero, sobre todo, acerca de la importancia estratégica de la Generación Z para Meta. A partir de ahí, intuye tres posibles escenarios para el futuro de BeReal que pasan por las manos de Mark Zuckerberg:

1. Meta compra BeReal y lo pervierte como hace con todo lo que compra. El fundador de BeReal es millonario, pero “quizá vendí demasiado pronto”.
2. BeReal le dice que no a Mark y le pasa como a Clubhouse, otra app que pretendía eliminar filtros y hacernos más humanos en las redes pero que ya no es ni parece que vaya a ser lo que fue durante ¿una semana?
3. Los inversores de BeReal empiezan a querer ver ingresos. Eligen la publicidad, pero necesitan muchas impresiones para generar dinero, así que los usuarios acaban pudiendo hacer y ver fotos sin límite en cualquier momento del día. Y eso ya es Instagram, Twitter, TikTok…

Resulta interesante este otro debate en torno a BeReal: ¿es solo una feature o puede ser una red social independiente? Yo no lo tengo claro del todo.

Personalmente creo que la clave del boom de BeReal viene por un error de comunicación de Instagram. Esto le ha pasado varias veces a Telegram, por ejemplo, cada vez que WhatsApp comunicaba algún cambio controvertido. La realidad es que WhatsApp no deja de ganar usuarios, aunque Telegram se lleve alguna migaja, y ahora es cuando está empezando a necesitar de monetización.

De los tres escenarios yo me quedo con que en ningún caso el futuro de BeReal es demasiado bueno: o acaba siendo una feature de Instagram, o acaba en el cementerio al lado de Clubhouse y similares. Estoy seguro que hay un cuarto escenario que ni Jon ni yo imaginamos.
Hoy, un meme para aliviar tensiones y síndromes del impostor. No estás solo/a 🤗
Os comparto este modelo de estrategia de producto de Roman Pichler que me parece muy útil al resumir en cuatro tablas la conexión entre el trabajo estratégico y el táctico.

Roman resume este proceso en cuatro pasos:

- Visión de producto: describe el propósito del producto, la razón última de su creación y el cambio positivo que debería provocar.

- Estrategia de producto: comunica el enfoque elegido para hacer realidad la visión y para que el producto tenga éxito. La elaboración de una estrategia requiere tomar cuatro decisiones importantes:
Seleccionar las necesidades a las que debe responder el producto.
Determinar el mercado o el segmento de mercado.
Elegir las características más destacadas que diferencien el producto de la oferta de la competencia.
Establecer objetivos empresariales realistas que describan los beneficios que el producto generará para la empresa.

- Roadmap: se basa en los objetivos del producto, que describen los resultados que el producto debe crear.

- Backlog: los objetivos de más alto nivel se traducen en otros más detallados y específicos.

A cambio de vuestro email, Roman os cede las dos plantillas donde rellenar esta información.

Además, Roman separa los pasos de este proceso en:

- Visión
- Objetivos de usuario y negocio
- Objetivos de producto
- Objetivos del sprint

Personalmente me parece un framework algo lioso, pero me quedo con las recomendaciones de la parte estratégica y el recordatorio de cómo este proceso debe ser lineal y horizontal, conectado de principio a fin y con una comunicación impoluta para evitar bloqueos o confusiones.

-----
Por cierto, al hacer mi web multi-idioma ha cascado el RSS del Podcast, así que ha desaparecido de Spotify, Apple y Google. Se pueden seguir escuchando en mi web y volverán a las plataformas, pero solo cuando adivine cómo solucionarlo 😅
Hoy he tenido un día de romper esquemas y re-aprender muchas evidencias sobre cómo hacer producto.

Este mediodía asistí a una charla de Jens-Fabian Goetzmann (Head of Product de Revenuecat, y muy citado en este canal y enlazado en la base de datos web) titulada: ‘Por qué los Product Manager no deberían ser data-driven’. Tiene una versión de texto en su blog.

Lo que Jens, obviamente, viene a decirnos no es que hagamos caso al CEO o al de Ventas para construir o mejorar un producto, sino que no nos podemos dejar engañar por los datos. Partiendo de la ley de Goddhart se entiende mucho mejor: “Cuando una métrica se convierte en un objetivo, deja de ser una buena métrica”. Dicho de otra forma: si tu objetivo es aumentar el engagement de tu producto, mandarás muchas notificaciones push; efectivamente aumentará el engagement, pero no estás aportando nada de valor a tus usuarios.

¿La solución? Ser data-informed: pregunta a tus usuarios, utiliza los datos, realiza experimentos, …

En paralelo he visto este vídeo donde Kristen Berman (Científica conductual y CEO de Irrational Labs) explica que no debemos hacer preguntas a nuestros usuarios porque, normalmente, nos mienten.

Para mí, aquí reside el arte de hacer buen user research y hacer las preguntas correctas, además de poner contexto a las respuestas. Como explica en el vídeo Kristen, a preguntas sobre actitudes del pasado solemos olvidar la realidad, y las preguntas del futuro esconden intenciones más que realidades. En esencia, las respuestas se basan más en lo que creemos que debemos contestar más allá de en la realidad, a veces avergonzante. “¿Te lavas siempre las manos después de ir al baño? Por supuesto” No lo sé, Rick… 🤔

Lo que propone Kristen es dejar de prestar atención a lo que nos dicen los usuarios y poner el ojo sobre lo que hacen. Esto es “Diseño conductual” y, personalmente, creo que no hace falta ser científico para aplicarlo, pero al igual que el caso de “data-informed” que indica Jens, considero necesaria una buena cultura de trabajo alrededor de estos conceptos y un esfuerzo por hacer cosas que ni te aseguran quick wins ni son fáciles de vender a los stakeholders.
Desde que vi la noticia de que Google ponía punto y final a Stadia me interesó mucho entender el por qué. Vale que el mercado está lo suficientemente saturado como para que una derrota así no sea sorprendente, pero estamos hablando de Google. En paralelo, Microsoft ha venido dando pasos en torno al cloud gaming y ha alcanzado el éxito con Game Pass, un modelo de suscripción dentro de un mundo acostumbrado a que los juegos se compran y punto.

Sigo pensando que Stadia lo tenía todo para triunfar, pero algo ha fallado en estos años para que, finalmente, Google decidiera que lo mejor es tirarlo a la basura. Ese algo puede ser esto que destaca Peter Yang (Product Lead en reddit) acerca de la cultura de trabajo de Google:

Promocionar a personas en función de lo que lanzaron (en lugar de impulsar la adopción o resolver los problemas de los clientes) es probablemente una de las peores formas de medir el éxito.

Aunque los comentarios no son actuales y es probable que vengan de personas no muy contentas con su paso por Google, ese hecho enlaza con la ley de Goddhart de que hablamos hace unos días. "Si una métrica es el objetivo, no es una buena métrica". En este caso, parece que la métrica del career path de Google es 'número de productos lanzados'. Saber encontrar el Product Market Fit te habilita para ascender en la empresa teniendo que dejar ese proyecto, en lugar de seguir en él y hacerlo crecer y triunfar.

Esto también me hace preguntarme por Google como empresa. La mayoría de sus ingresos vienen y vendrán por la publicidad. ¿Están simplemente formando a sus trabajadores en proyectos inmensos para, a posteriori, meterlos donde realmente está la chicha? ¿Google realmente quiso disrumpir la industria de los videojuegos, o ya le va bien solo con intentarlo, poner nerviosa a esa industria y usarlo para mantener la imagen de empresa tecnológica innovadora?

Dudo que en Google no sean conscientes de esto y tengan un plan real que tenga sentido. Por otro lado, su anterior CEO también dice no tener ni idea de cómo formar a buenos managers si no están en la oficina, así que yo qué sé 🤷‍♂️

Pensándolo bien, quizá algo así es lo que le pasó a las Google Glass. Lanzamiento por todo lo alto, pero a la basura.
Un buen ejemplo de que, a veces, "mejor hecho que perfecto" trae consecuencias amargas:

Hoy publica Joanna Stern en el WSJ cómo varios iPhone 14 han estado detectando accidentes de coche, avisando a las autoridades y los familiares de esas personas. La realidad es que esas personas estaban en una montaña rusa, y el algoritmo no supo diferenciar esa actividad de un accidente real.

Esto me ha hecho reflexionar sobre la responsabilidad que tenemos quienes nos dedicamos a construir productos. Es cierto que lo que falla en el mundo digital se queda, normalmente, en ese mundo digital; en cambio, el iPhone puede impactar en el mundo real, no porque no se haya probado esa nueva funcionalidad "con miles de horas de datos, pruebas de laboratorio y conducción real", como indican desde Apple, sino porque un fallo de este tipo moviliza a policía, bomberos y ambulancias para nada, a la vez que da un susto de muerte a tus contactos más cercanos.

¿Qué pasaría si 30 personas se montaran en esa atracción con sus iPhone 14? La policía recibiría 30 llamadas sobre un accidente en la misma ubicación. Imagínate el despliegue para nada, y la cantidad de personas asumiendo que su hijo, su hermana o su pareja están gravemente heridos.

En esta situación, ¿es mejor no lanzar la funcionalidad o asumir un porcentaje de falsas alarmas?
Llevo un tiempo viendo, de cuando en cuando, como referencia de muchas buenas prácticas para PM, CPOs y equivalente el libro “The art of Action”, de Stephen Bugay (Todostuslibros - Amazon). No sé si empieza a ser el ‘Inspired’ de quienes ya tienen experiencia y empiezan a ganarle terreno al management, pero lo he vuelto a ver en esta serie de pasos que George Nurijanian utiliza a modo de plantilla para enmarcar la estrategia de un producto:

1. Contexto
2. Intención superior
3. Mi intención
4. Tareas, responsabilidades y timing
5. Libertades y límites
6. Resumen

Podemos discutir si construir una estrategia debe seguir unos pasos concretos (no en todos los casos, opino yo), pero sí creo que ayudan a estructurar ese trabajo estratégico y, sobre todo, comunicarlo eficazmente.
Hoy me tomo la libertad de hablar de un proyecto personal que vio su fin estos días. Tras casi dos décadas online, enCancha.com -el medio digital sin ánimo de lucro especializado en baloncesto que fundé en 2004- decía adiós porque ya era el momento de decir adiós. La misión está más que cumplida y no tiene sentido prolongarlo más para que muera solo.

enCancha fue la primera casa de muchos actuales profesionales de la comunicación, pero también de gente que encontró otras pasiones. En mi caso pasaba más tiempo con Dreamweaver (sí, el CMS lo monté con Dreamweaver. WordPress apenas tenía un año de vida. Eran otros tiempos. No-code antes de que estuviera de moda 😜 ) y Photoshop que redactando o haciendo fotos (yo estaba estudiando Periodismo...).

¿Qué aprendizajes saqué de aquella etapa?

- Timing. Ser pionero está muy bien al principio, pero deja de tener valor con el tiempo.
- Las puertas se te abren si estás haciendo algo de valor. Todavía no me explico cómo una web de chavales de 20 años tenía acreditaciones de prensa.
- Reúnete de gente y deja hacer. Un proyecto crece mejor si tiene varias personas al timón, sobre todo cuándo no tienes claro qué rumbo tomar.
- Hay que saber cuándo parar y salirse de un proyecto que no te aporta.
- Di no si no está claro el . En su momento me ofrecieron comprar enCancha, pero incluso con mi inexperiencia supe darme cuenta que habría sido una mala idea, tanto para el proyecto como para mi carrera.
- Arquitectura de la información. No es fácil catalogar y hacer accesibles fotos y noticias de uno o varios equipos que juegan en una o varias ligas durante diferentes temporadas con frecuentes cambios de nombre.
- Prepárate para cuando jueguen sucio contra ti. Plantear una rotura del statu quo tiene consecuencias tarde o temprano.

Conclusión: tened un side-project ^_^
Hace unos días fue bastante viral este post en reddit sobre un PM que se había rendido; decía que sí a los stakeholders y era más feliz que haciendo Product Management. Aparte de lo cómico de la situación y el hartazgo que refleja, es interesante contraponer esa visión, pasar de decir que sí a todo y a todos a decir casi siempre que no a todo y a todos. ¿Qué es mejor?

En este post de 2015, Jason Burke aborda precisamente lo contrario al post de reddit: cómo y por qué decir que no.

"La diferencia entre la gente de éxito y la gente de mucho éxito es que la gente de mucho éxito dice 'no' a casi todo"
- Warren Buffet

Así empieza el artículo, y su premisa es simple: ante una lista infinita de cosas que hacer, la respuesta a “¿cómo vamos a hacer todo esto?” es simple: no vamos a hacer todo esto.

Más fácil decirlo que hacerlo, y tras ese gran ‘no’ hay otra herramienta: la priorización. Lo que Jason recomienda preguntarse para hacerla bien:

- ¿Qué queremos hacer?
- ¿Cómo va a beneficiar al negocio construir esto? (Añado yo aquí, ojo con la Ley de Goddhart en esta pregunta)
- ¿Cuánto va a costar construirlo?

Y una apreciación subjetiva basada en la experiencia personal: saber decir que no es más valioso en B2B que en B2C.
Por cierto, gran reflexión de Íñigo Medina (CPO de Filmin) en los comentarios del post de ayer https://t.me/c/1669300610/178. Os animo a participar
Volviendo al terreno de las herramientas prácticas y útiles en el día a día de un Product Manager, os comparto esta web, que no es más que una evolución mucho mayor de mi propio proyecto, enfocado en cuatro aspectos interesantes:

- Systems thinking
- Decision making
- Problem solving
- Communication

Me han gustado también sus Prompt questions, para localizar rápido un framework o una matriz que ayude a resolver una pregunta más o menos concreta.
1 Xy0MPcpTJGf6bNqoIJwylw.jpg
78.8 KB
Mei Zhang ha conseguido clasificar diferentes métodos de diseño en un mapa mental para organizar el camino de la construcción de una visión de Producto.

En este enlace de Miro está el mapa completo, y en este post cuenta con detalle el sentido de ese mapa.

Lo divide en:

- Entender
- Definir
- Idear
- Ejecutar
- Validar

Y señala el equipo o disciplina más acorde para ejecutar cada caso:

- Diseño
- Product Management
- Tecnología
- Comunicación

Ya enlazado en el repositorio web para que no se pierda.
Si estás siguiendo todo el culebrón Twitter y Musk seguramente te sea familiar un enfoque del agile que ha provocado muchísimas opiniones encontradas. Si no sabes de qué te hablo, aquí va una ayuda.

No voy a entrar en el debate aquí, ya lo hice en Twitter, pero sí lo voy a usar como percha para compartir esta experiencia de Paweł Huryn, que descubrió en el agile una manera diferente y mejor de trabajar con su equipo:

"Mis equipos estaban poco comprometidos, no mostraban ningún interés en hacer nada más de lo que se les pedía, y la calidad de nuestros productos era pésima. A menudo me he preguntado cómo es posible que cuando personas adultas y educadas van a trabajar, empiezan a comportarse como niños."

Leyendo lo que hacía se puede intuir que aterrizaba mucho todo, no dejando espacio a que su equipo se hiciera las preguntas correctas que ya él había respondido sin contar con ellos.

En una conferencia de Agile entendió que podía cambiar su forma de trabajar para modificar esa dinámica y empoderar a su equipo. Entre otras que indica en el post hizo:

- Dar a los equipos problemas que resolver en lugar de tareas específicas
- Mostrar confianza en lugar de ejercer el control
- Comunicar regularmente la visión y la estrategia

----
Seguramente habréis notado una reducción en la frecuencia de publicaciones de este Cuaderno de Producto. El motivo es que estoy preparando un curso en el Instituto Tramontana titulado "Negocio y producto para diseñadores", que tendrá lugar en Madrid a mediados de diciembre. Os invito a que lo compartáis con quien consideréis que le puede venir bien.

También ando preocupado con Twitter. No sé qué va a pasar, pero sí sé que Mastodon no es su alternativa; no creo que Twitter se muera, pero sí que estoy más incómodo en él. Hoy ya directamente me recomienda seguir a Donald J. Trump. No recuerdo que antes me recomendara a Ocasio-Cortez, por ejemplo. Llámame loco... Si estás por Mastodon, me puedes encontrar como antonio@mastodon.gal
👋 Reactivo este canal en esta semana rara, donde muchos estamos de vacaciones y otros disfrutan trabajando tranquilamente sin los que estamos de vacaciones 😜

Os quiero compartir este vídeo con un caso real en el que Madhur Chadha (Product Manager en Google) repasa todos los sombreros que termina poniéndose un PM. Es una buena manera de explicar el rol, a la vez que entender el caos (en el buen sentido) que a veces envuelve a estas tareas.

En el vídeo repasa diferentes momentos clave del proceso:

- Retos legales
- El producto per se
- ¿Qué alternativas aparecen?
- Marketing
- El resultado y la elección
- Tirarlo todo

-----

🎁 Y coincidiendo con la generosidad de las fiestas, me gustaría premiar vuestra fidelidad repartiendo entre quienes sean más rápidos enviándome un DM:

- 5 invitaciones a Cron
- 5 invitaciones a Arc

Elegid bien, porque solo daré uno por persona (es decir, no se vale abusar y que me pidáis invitación para los dos 😏)

-----

Confío en que sigáis pasando unas felices fiestas, sea lo que sea que celebréis estos días: Navidad, Saturnalia, Festivus, Janucá, Rohatsu... 😄
Me ha resultado muy útil este hilo de Johnny Rodgers (Product & engineering en Slack) en el que pone de manifiesto un escenario que se contradice al típico "tú no eres el usuario". Ellos usan Slack para seguir construyendo Slack 😝

En el hilo destaca diferentes aspectos relacionados con el feedback interno que es útil:

- Al principio de cada nueva funcionalidad, un grupo reducido prueba y da feedback sobre el prototipo. Si va teniendo sentido, el grupo se va ampliando.
- Una vez que hay confianza, e incluso se involucra a stakeholders y ejecutivos, hacen lo que llaman una "Tiny Speck" (una release interna que coge el nombre original de la empresa). Informan en un canal interno de Slack y piden que den feedback en otro canal interno.
- Antes de hacer la release a todos los usuarios, se prueba con otro grupo de usuarios diferentes que también dejan su feedback.

Johnny pone el ejemplo de los Huddles para cristalizar la cantidad de tiempo y feedback que una feature puede recibir, lo cual implica muchas revisiones antes de que esté listo para ser lanzado. A la vez, esa cantidad de tiempo puede ser pequeña si la funcionalidad no es buena y se decide matarla a tiempo.

¿Y qué consiguen con algo que coquetea con la parálisis por análisis?
1. Feedback y mejora continua
2. Agilidad para pivotar
3. "Las buenas ideas pueden venir de cualquier sitio"
De cuando en cuando leo predicciones sobre la extinción del rol de Product Manager. No es solo que la IA vaya a encargarse de nuestras tareas, sino también entiendo que es un trabajo cuyo impacto es difícil de cuantificar.

Este hilo de Itamar Gilad (entre otras cosas, creador del framework GIST) reflexiona precisamente sobre cómo medir ese impacto a partir de una premisa simple: dos PMs tienen dos ideas sobre las que trabajar. Uno construye una funcionalidad, y el otro llega a la conclusión, a través del Discovery, de que sería una mala idea construir la funcionalidad. ¿Quién tiene más impacto? ¿Quién hace mejor su trabajo?

Como explica Itamar, depende de la definición de 'impacto' sobre la que se guíe la empresa y sus managers. Se puede afirmar que en la mayoría de los casos una entrega tiene mayor impacto que una no entrega, pero en el caso del segundo PM también es cierto que hizo bien su trabajo.

Itamar también reflexiona sobre dar outcomes en lugar de ideas a los PM, y cómo esto tampoco es la clave definitiva ya que son complicados de asignar a una persona en concreto:

"Es una métrica subjetiva que puede motivar a la gente a inflar sus proyectos, equipos o actividades"

Como termina Itamar -y suelo aplicar en momentos de bloqueo- quizá estamos queriendo responder la pregunta equivocada:

"¿Estamos optimizando engranajes de una máquina o ayudando a seres humanos imperfectos a colaborar mejor y obtener más resultados?"
¿Cómo se relaciona el Mapa de Impactos con la definición de OKRs en equipos de Producto?

Es la pregunta que se hace y contesta Tim Herbig en este post de Linkedin. En él desgrana diferentes aspectos de ese mapeo que impactan en la adecuada definición de OKRs, que se organizan por:

- Impacto
- Actores
- Outcomes
- Outputs
- Experimentos

La cuantificación de las cadencias de los Experimentos puede ser útil como KR adicional para que un equipo de producto mejore su práctica. Por otra parte, los experimentos deben presentarse con vínculos claros a los OKR de resultados previamente comprometidos, por ejemplo, como parte del roadmap.
Una inocente pregunta en reddit ha generado bastante debate alrededor de las maneras de priorizar basadas en puntuación: "¿Cómo puedo medir el alcance y el impacto en RICE?", preguntó jeefski la semana pasada.

No voy a entrar en si RICE es un buen framework de priorización o no, pero sí me quedo con algunas reflexiones:

"El alcance es difícil de medir y es un indicador poco fiable"
"Los números de RICE pueden parecer arbitrarios para una feature concreta, pero eso no importa en absoluto. El único propósito de RICE es ayudarte a diferenciar entre todas las features"
"Por lo general, si el esfuerzo de implantación es grande, necesitarás algún tipo de argumento de negocio para validar el problema, solución, valor y alineación estratégica. Si el esfuerzo es bajo, deberías poder usar simplemente tu criterio como PM"

Queda claro que un framework como RICE es una herramienta, y no un fin; no se puede seguir a ciegas sino que ayuda a recorrer el camino y depende del contexto.

Pero la chicha que me ha llamado mucho la atención es esta que indica pangresearch:

"No se puede 'medir' el alcance y el impacto formalmente en marcos definidos arbitrariamente que tienen una escala de valores aleatoria en las entradas y salidas. Claro que se pueden introducir números y obtener una lista de características clasificadas como resultado, pero sus premisas son una basura inestable y lo más probable es que sólo conduzcan a un "sesgo de confirmación" sobre la clasificación de características que quieres. El campo del Product Management está en pañales todavía".

¿Afinar la certidumbre nos va a sacar de esa infancia, o sencillamente es imposible encontrar el santo grial de las priorizaciones y estimaciones en la evolución de un producto en el mercado e invertir este esfuerzo en otros aspectos? ¿Estamos de verdad en esa infancia, o es solo lo que se percibe del rol, fruto de esa incertidumbre?
Un meme para desearos un gran fin de semana 😂