5 lecciones aprendidas en el Mind the Product Con que todo Product Manager debe saber | Life & Tech

Corría el año 2014, cuando estaba trabajando en bq junto a José Carlos Díaz y entre café y café hablábamos de Marty Cagan y sus charlas para crear productos que la gente ame o Jeff Patton y sus técnicas de User Story Mapping para organizar el jaleo de una planificación temporal y de historias de usuario en un producto. Cuando salió el nombre de Mind the Product, una comunidad exclusivamente dedicada al Product Management; sus posts y reflexiones de alta calidad y dando en la diana sobre lo que realmente me interesaba me hicieron pronto desear ir a alguno de sus dos eventos anuales que organizan en San Francisco y Londres. Este año por suerte y gracias a Guillermo y DEISER he podido asistir al de éste último, no podía estar más ilusionado.

Lo primero que me sorprendió al llegar al Barbican Theater de Londres es la magnitud del evento que era. Estoy acostumbrado a grandes citas del mundo de la tecnología como los Summit de Atlassian o AtlasCamps, eventos multitudinarios (más de 2000 personas) y con unos cuantos millones de dólares detrás. Pero claro, una cosa son los grandes eventos organizados por una multinacional que cotiza en bolsa y otra el de una comunidad. Por eso cuando vi el despliegue en medios, sponsors, voluntarios, etc lo primero que me pregunté es: ¿de veras esto es una comunidad? Quizás sí pero de las caras, o al menos por el precio de los tickets podríamos afirmarlo.

La jornada se desarrolló con un único track de charlas en el teatro principal donde fueron pasando speakers más o menos conocidos pero todos con un mensaje muy claro e inspirador para hacernos pensar de manera diferente y hacer mejores nuestros productos, aquí van algunas de las lecciones que a mi se me han quedado:

Embrace the awkwardness, no pasa nada por ser un impostor porque hace falta un impostor (Martin Eriksson)

El cofundador de la comunidad Martin Eriksson empezaba el evento soltando la bomba y mentando al elefante en la habitación. ¡Todos somos impostores! pero no pasa nada, porque es bueno y hay que aceptarlo.

Se refería al famoso síndrome del impostor, el cual hace sentir a una persona que está por debajo del nivel de otras que están a su alrededor porque éstas están mucho más especializadas en su trabajo y el tuyo es hacer de pegamento, guiarlas o llevar la estrategia. Si bien este sentimiento es totalmente subjetivo porque el resto de gente sí que te ve valioso, tú mismo te ves como un impostor.

En el mundo tecnológico es cada vez más común pues hay roles como el de Scrum Master o Product Manager que tienen una componente social muy fuerte y parte de tu trabajo es sacar lo mejor de cada miembro del equipo. Yo he de confesar que a lo largo de los años en puestos como estos a veces me he sentido un impostor, sé que está solo en mi cabeza pero el hecho de escucharlo en otros PM’s y asumir que es algo normal me ha ayudado mucho a aceptarlo.

A product is made of decisions, not pixels and code (Kim Goodwin)

El código fuente de un producto software es parte esencial, por supuesto, se podría decir imprescindible (aunque hay productos sin una línea de código, dedicaré otro post a esto).

Pero lo que nos contaba Kim Goodwin es que lo vital es tomar decisiones, casi cada día, decisiones que tienen que estar basadas en datos, sin éstos no somos nadie y sin las métricas y números nuestro producto estará ciego.

Uno de los aspectos más importantes de las métricas es que siempre deben estar acompañadas de un objetivo, medir por medir no vale para nada.

HEART (Roan Lavery)

Roan nos habló del framework HEART, diseñado por Google. En cual consiste en diferentes áreas de métricas para evaluar la experiencia de usuario y como va tu producto. Consiste en cinco grupos de métricas:

Cada una de ellas tendrá diferentes indicadores que dependerá del producto, plataforma, etc.. En la imagen Roan nos enseñó las que el usa, sin duda es algo que implementaré en breve.

Do the right things in the right order for the right reasons (Joe Leech)

La charla de Joe fue una de las más fascinantes, se adentró en un mundo tan necesario como normalmente desconocido en product management: la psicología.

Nos enseñó la diferencia entre comportamientos estáticos y tautológicos en procedimientos y secuencias por que son éstos los que las personas entienden e interiorizan mejor. Secuencia, secuencia, secuencia y además siempre la misma y si vas a introducir cambios, por nimios que parezcan, es mejor hacerlos muy poco a poco para no perturbar el mapa mental de la interfaz que tiene el usuario. “ Si lo haces de golpe, lo rechazará, por muy bueno que sea el cambio.”

Experiments don’t fail, hypothesis are proven wrong (Rick Higham, Skyscanner)

¿Cómo podemos estar seguros de la dirección a tomar si no hacemos experimentos y evaluamos si funciona? Todos tocamos el agua de la ducha a ver si está lo suficientemente caliente antes de meternos, ¿verdad?

La formulación y validación de hipótesis es la piedra angular de todo producto, ya que no tenemos ni idea de cómo se comportará el mercado ni el rumbo de nuestros competidores, ni la psicología de nuestros usuarios. No debemos tener ningún miedo a formular una hipótesis, y probar que es incorrecta por que no es un fallo nuestro o del producto, es asegurarnos del comportamiento de todos los factores que he nombrado antes.

Rick decía que una hipótesis debe ser “testeable” y poder ser demostrada falsa.

Como herramienta nos dejó http://experimentationhub.com un toolbox con muchísimos recursos, consejos y guías para experimentar bien se con tests A/B, plantillas de formulación de hipótesis y análisis de resultados.

Estas son las lecciones más importantes que me marcaron en la MTP Con de Londres pero hubo muchísimos más consejos y acciones que me llevo de vuelta y seguro usaré.

Originally published at https://lifeandtech.page on October 29, 2018.