Product Manager

Cualquier crecimiento es una transformación

Uno de los espacios que más me gustó del SOS Zaragoza 2019 fue la que salió de la suma de 2 propuestas de @guilleciencia y Jorge Viarte, con los títulos «Doblar el tamaño sin morir en el intento» y «Postmortem Terminator». Dejando de lado que eran bastante marketinianas y llamaban la atención, la propuesta se basaba en cómo anticiparse a todo lo que puede ocurrir cuando el equipo se escala y así estar preparado para que no ocurra.

Cultura y organizacion

Aunque lo ocurrido en cada caso era distinto, había algo similar. La empresa por fin tenía dinero y podía ampliar el equipo. En una de las compañías, había sido un crecimiento en todas las áreas (almacen, marketing, desarrollo…) y en la otra era más la parte técnica.

Estas decisiones van ligadas al momento financiero de la empresa.

Lo ideal es que el crecimiento sea gradual, pero en muchas ocasiones eso no es así. Ya sea porque el mercado lo impone (por ejemplo, entra un nuevo proyecto), o por tema económico, muchas empresas tienen a gente absorbiendo esa carga extra de trabajo hasta que pueden permitirse crecer. A veces la tecnología permite que un equipo bueno pequeño absorba un crecimiento de 100 a 2000, pero llega un momento en que si la empresa quiere crecer no basta con ello.

Pueden darse muchos casos distintos. En ocasiones la empresa conoce ya a gente que ha trabajado con el equipo o que trabaja de forma continua, y los absorbe. En ese caso, el proceso es mucho más suave, ya que no hay sorpresas en cuanto a su conocimiento, a su «seniority» ya que se lleva tiempo colaborando de forma conjunta. También es más fácil que conozca más sobre la empresa, los roles de los que ya están dentro, el negocio y producto que desarrollan y lo que se espera de ellos.

Otras veces las personas que se contratan no tienen el nivel esperado, o una falta de conocimiento de hasta dónde llega la responsabilidad de cada uno. Esto puede hacer que no se reparta bien el pastel y que algunos acaben asumiendo más trabajo de lo que les toca, quemándose a la larga. Para solucionar esto, entre los asistentes comentaban que una posible idea era realizar un delegation board.

Otro de los asistentes, con uno de sus comentarios (como muchas veces agudos y certeros9 sugirió que la situación del mercado actual de recruiting la hemos generado nosotros por lo que también tenemos que arreglarla. Sino encuentras seniors, contrata lo que encuentres y gasta el presupuesto en hacerles seniors.

Seguir leyendo «Cualquier crecimiento es una transformación»

¿El backlog cuesta dinero?

Mantener inventario cuesta dinero. Ya sean sacos de plástico apilados al lado de la máquina para ser inyectado, tomates en una nevera de un restaurante, o pantalones en un camión esperando su transporte, es dinero almacenado. Además existe la posibilidad de que si hay una inundación, entran bichos, o simplemente se pasa de moda, pierde su valor.

Lo más fácil sería que no fuera necesario mantener ese material almacenado, pero claro eso tiene otros costes asociados. No te puedes quedar fuera del negocio por no tener ruedas para fabricar más coches o cerveza para servir un día caluroso. De ahi el Sistema de producción Toyota, precursor del «Lean manufacturing» o la Teoría de las restricciones o limitaciones (Theory of Constraints, TOC).

Pero, ¿esto también sucede cuando hablamos del desarrollo de un producto digital?

Pues si, que no sea un producto físico y tangible, no significa que no tenga grandes costes asociados.

En cada una de las etapas por las que pasa el código antes de llegar al consumidor final, es «producto almacenado». Desde la User Story definida por el product owner, hasta el tiempo que un tester se pone a probar el código desarrollado, es material almacenado.

El coste del inventario de código es enorme.

En algunos casos pueden tardar meses en llegar a las manos del consumidor final. Esto puede ser la diferencia entre sacar al mercado un producto novedoso o estar constantemente copiando a los más vendidos. Y es que ser el primero muchas veces marca la diferencia en un mercado donde los consumidores están constantemente pensando en la siguiente novedad.

Y dado que los recursos que normalmente se disponen en las empresas son escasos, es muy importante focalizar y no perder tiempo en escribir algo que no va a ser utilizado o salir a producción.

Backlogs

Durante el desarrollo de un producto digital pueden surgir muchas ideas de funcionalidades que jamás llegan a ver la luz. Tal cual vienen, ya sea en una sesión de grooming o porque un cliente o alguien de la empresa hizo una sugerencia, se escriben y se almacenan en un backlog.

El problema es que el 90% de las cosas que están en el backlog nunca se implementarán. NUNCA.

Por ello cada minuto que se gasta escribiéndolas, detallándolas, diseñándolas o discutiéndolas es tiempo desperdiciado.

La mente es compleja, y como describe la metodología GTD® (Getting Things Done® de David Allen) es mejor poner algo por escrito y dejar de pensar en ello, que no tenerlo rondando por la cabeza y estar inquieto. Pero debe almacenarse en el lugar correcto y de la forma correcta. A lo mejor una línea de texto en la herramienta que uses de forma personal como PO bastará para almacenar esas ideas que jamás se programarán.

Seguir leyendo «¿El backlog cuesta dinero?»

Los silos de conocimiento

Como sucede en muchas empresas lo que llaman «recursos» no son infinitos. Ya sea el dinero para marketing o los desarrolladores del equipo técnico, uno de los retos más importantes es decidir donde se tiene que poner el foco.

Ya sea una startup con limitado presupuesto o una gran empresa que puede contratar quien quiere, a veces 9 mujeres no hacen un hijo en un mes, por lo que hay que decidir qué hacer y en qué orden hacerlo.

Silos de conocimiento

En varias empresas he visto que el problema surge de los silos de conocimiento. La sabiduría, el know how, pertenecen como es lógico a aquellas personas que llevan más tiempo, siendo normalmente las más ocupadas y por ello, las que suelen hacer de embudo y tapón en la toma de ciertas decisiones.

Por ello por mucho que se disponga del poder  de aumentar el equipo, si éstos perfiles no tienen tiempo para analizar y evaluar en que dirección se debe avanzar, o si son los únicos que saben realizar ciertas acciones, la empresa tiene un problema.

Es complicado, cuando entras en la rueda diaria de las tareas planificadas del sprint en el JIRA, reuniones, fuegos que saltan de repente…. el poder sacar tiempo para ir traspasando ese conocimiento, pero es algo necesario que sino se hace a la larga va a ser peor tanto para la persona como para la empresa.

Seguir leyendo «Los silos de conocimiento»

Personas tóxicas, primera charla en SOS Zaragoza

El primer debate al que asistí en el SOS Zaragoza 2019 fue el propuesto por @amaliahern sobre personas tóxicas (término por cierto muy de moda últimamente que ya implica algo negativo).

Entre los asistentes comenzó una conversación sobre definir qué era una persona tóxica, como se puede detectar, en que entorno y situaciones pueden surgir, si se les puede cambiar y cómo….

Muchos en ocasiones se definían que en según que circunstancias habían sido personas tóxicas para su equipo.

Por ello, ¿puede ser un momento puntual que esa persona se está comportando así? Debido a la carga de trabajo, las presiones, ciertas situaciones personal… Estoy seguro que muchos no nos hemos comportado con los compañeros de la mejor manera…

Pero y si, ¿es algo habitual?

Como manager, creo que es tu responsabilidad que el equipo no tenga un persona así, que genere mal ambiente. Creo que es el deber de la persona al cargo, empatizar con esa persona y averiguar por qué está así, definiendo el tiempo que estás dispuesto a soportar esa situación o que el equipo puede aguantarla.

Sino se sabe como tratar el problema, puede ser una buena ayuda contratar a un facilitador profesional, alguien ajeno a la empresa.

Si está pasando esto, es porque cm managers estamos dejando q suceda.

Y es que una de las definiciones que se mencionaron, fue que es gente que cuando no va trabajar todo el mundo se encuentra mejor, y el clima en la oficina cambia. En el caso de que se vaya o la despidan, es cuando todo el mundo empieza a comentar sobre actos o situaciones pasadas y que bien se está ahora.

Pero, ¿y si ese comportamiento es favorecedor desde el punto de vista de la dirección?

En mi opinión, hay que saber como tratar a cada persona. Es decir, lo que a una le puede motivar, a otra le puede causar estrés. Con lo cual, no creo que sea saludable para ninguna empresa, gente que genere mal ambiente. Una cosa es que haya que sacar un proyecto y los timing sean ajustados y haya algo de presión extra, y otra cosa es que haya mal ambiente, en cuyo caso creo que surge el estrés malo y la ansiedad. No ese estrés bueno, que te impulsa que te motiva a dar lo mejor de ti.

También se comentó que no existen personas tóxicas sino que son actuaciones tóxicas en personas cosa con la que estoy totalmente de acuerdo, aunque si que creo que existe gente mala.

Si la empresa busca contratar buena gente, preocupándose de hablar con antiguos compañeros y conocer su pasado, veo complicado que surjan ciertas situaciones. Si puedes tener una crisis personal y tener meses malos, pero eso ya es cuestión de cada uno traspasarlo a la vida laboral o no saber gestionarlo de alguna forma (pedirte unos meses de excedencia, hablar con los compañeros o con tu jefe…)

También la cultura de empresa puede influenciar mucho en favorecer la aparición de este tipo de personas. La forma en la que se toman ciertas decisiones puede influenciar la aparición de estos comportamientos. Se deben definir unos principios, unos valores, y con ejemplos de posibles situaciones. Y que todo lo que se salga de ahí, esté fuera.

Growth Hacking

El growth hacking es la aplicación del método científico para el diseño, implementación y prueba de estrategias repetibles y escalables para maximizar las métricas en cada etapa del funnel general de producto digital.

¿De dónde viene el término?

En 2009 cuando Facebook iba a salir a bolsa, Mark Zuckerberg escribió una carta a todos los posibles grandes inversores de los que dependía el éxito de este movimiento, mencionando cual era la cultura de la empresa “The hacker way” con la que los empleados atacaban los posibles retos. Esta se basaba en 5 valores:

  1. Focalízate en los importante
  2. Muévete rápido
  3. Se atrevido
  4. Se abierto
  5. Construye valor social

Funnel de producto

El funnel es una de las herramientas que se usan para conocer el estado de tu producto y poder mejorarlo, ya que visualizas en una sola imagen lo que importa cuando desarrollas, mejoras o quieres hacer crecer un producto digital.

Puedes diseñar tantos tipos de funnels como objetivos quieras conseguir, pero el funnel general de producto es el que sus siglas forman la palabra «AARRR», la conocida métrica pirata:

  1. Acquisition (Adquisición) > Llegan a tu web
  2. Activation (Activación) > Se registran
  3. Retention (retención) > Vuelven
  4. Revenue (Beneficio) > Te pagan
  5. Referral (Referencia) > Hablan de ti

Muchas veces se añade una etapa anterior llamada «Captación». El funnel nos aporta una gran cantidad de información pero tenemos que aprender a leer correctamente, y no dejarnos engañar por las métricas que no aportan valor, como las «vanity metrics«.

Seguir leyendo «Growth Hacking»

3 consejos para escalar equipos técnicos por Jorge Gómez Sancha

Hola,
os recomemiendo mucho escuchar los PodKast de KFund ya que tratan muchos temas variados con gente super interesante. En concreto este de Jorge Gómez Sancha (@jorgesancha), actualmemnte trabajando en Carto como, hablando sobre «Escalando equipos técnicos», un tema que siempre me ha parecido super interesante ya que creo que uno de los mayores problemas de las empresas es la gestión del talento y del trabajo cuando comienzan a crecer.

Escalando equipos

Imagen extraída de la web de blog.kfund.vc

Como no, mucho mejor escucharlo en directo. Pero me he quedado con 3 consejos que da al final y que me gustaría resumir:

  1. Tener claro a quién reporta cada uno. Al crecer lo que funcionaba hacer 3 meses ya no funciona por lo que hay que ir definiendo la forma de trabajo continuamente.
  2. Un único sitio en el que saber que tiene que hacer cada persona. Que cualquiera de la empresa pueda mirar y sepa lo que esta haciendo y su siguiente prioridad. Parece fácil pero al crecer no lo es. Lo primero que hizo al entrar en Carto fie estandarizar el Kanban, con una única forma de gestionarlo. Luego cuando lo dominen que ya evolucionen (si te gusta esto te puede interesar este resumen sobre Equipos de alto rendimiento, de la genial charla de Israel Alcazar (@ialcazar) en la CAS 2017 ).
  3. Comunicar mucho más de lo que crees que tienes que comunicar. Por qué estamos haciendo las cosas «estamos haciendo esto porque la estrategia era uno, dos y tres», repetir las cosas mil veces… Nunca hay tiempo, nunca es prioritario pero hay que hacerlo.

Y es que como comenta Jorge, muchas veces en una empresa se asciende a alguien interno que está haciendo un buen trabajo y se le convierte en Manager o CTO, o VP…

Pero eso no quiere decir que se le de bien gestionar, saber tratar a la gente y todo lo que implica el trabajo además de que seguramente va emplear muchas más horas de lo que cree. Sobre todo en startups donde el perfil puede ser más joven, Sancha recomienda dedicar tiempo a darles pautas: tienes que hacer “One to one”, checkings….

Yo he estado en empresas que he visto como ponían a gestionar a magníficos desarrolladores, pero que no servían para nada sabiendo motivar al equipo, controlando el avance el trabajo en base al road map planteado, reportando al CEO o a Inversores las nuevas mejoras o los problemas encontrados, no sabiendo pedir ayuda al ver que todo se le escapaba de las manos…

Lo malo es que cuando el puesto es alto, aunque los de abajo vean lo que ocurre, desde arriba aun se puede tardar varios quarters en ver lo que pasa. Y eso es mucho dinero. ¿Y una vez detectado? Posibles soluciones: ponerle un coach que le enseñe, cambiarlo de posición al puesto que antes hacía tan bien, poner a otra persona a hacer la parte que menos controla…

Lo dicho, espero que os guste el podKast, a mi me ha parecido genial!

Diseñando experiencias organizacionales

Israel Alcázar y Janire Paskua de la empresa Thinking with you hablan en el pasado congreso de experiencia de usuario Experience Fighters 2018 sobre Cynefin una palabra galesa traducida como «habitat«, para definir un framework conceptual usado para ayudar en la toma de decisiones. Creado en 1999 por Dave Snowden cuando trabajaba en IBM Global Services, se basa en la investigación de la teoría de sistemas, la teoría de la complejidad, la teoría de redes y las teorías del aprendizaje.

Cynefin UX

El mundo ha cambiado y hay que adaptarse. Para afrontar el desafío en estos entornos de cambio, las organizaciones necesitan generar modelos de gestión más líquidos y emergentes que les permitan navegar por la incertidumbre. Alcázar y Paskua nos cuentan su experiencia como diseñadores de experiencias organizacionales, el proceso de arranque y los principales actores y problemas que se encuentran.

5 habitats o contextos

Para ello se debe entender los diferentes contextos en los que las organizaciones se mueven, los diferentes habitats que existen. Cynefyn ofrece 5 contextos de toma de decisiones o habitats, que sirven para ayudar a los gerentes a identificar cómo perciben las situaciones:

  1. Simple
  2. Complicado
  3. Complejo
  4. Caótico
  5. Desorden

El contexto de lo Simple trata de que las relaciones entre una causa A y una solución B, son directas. Siempre para una misma causa existe una solución. Mismo problema, misma solución. En la Formula 1 el cambio de neumáticos y el repostaje son un ejemplo. Está claramente especificado como hacer el mejor repostaje. Como resolvemos el proveedor de papelería… siempre es la misma solución.

El segundo, es el dominio de lo Complicado. Ya no es tan fácil la relación causa, efecto, solución. Para un mismo problema podemos tener muchas soluciones. Necesitamos para ello expertos, es decir, se necesitan conocimientos y experiencia en el tema. En el mundo de las organizaciones serían las buenas practicas: design thinking, service design…

Seguir leyendo «Diseñando experiencias organizacionales»

Vuelta a Centraldereservas.com como Product Manager

Después de que hace 3 años cambiara de ciudad por motivos personales de Zaragoza a Valencia para formar parte del equipo de UX de Capgemini, vuelvo como especialista de UX y PM a Centraldereservas.com.

Web de Centraldereservas.com

Imagen de la home de Centraldereservas.com

Tras llevar un tiempo trabajando como consultora UX para clientes de  diferentes sectores, tenía muchas ganas de volver a formar parte de un equipo (o varios) dentro de una misma empresa, y que mejor de volver a aquella en la que había estado tan a gusto durante más de 2 años.

Por ello que desde junio vuelvo a formar parte de la web de venta online de alojamientos, vuelos, actividades… que intenta luchar por ofrecer una experiencia de cliente espectacular frente a gigantes como Booking, Trivago…

Mi trabajo en palabras del CEO, Ricardo Buil, consiste en integrar negocio, imagen y usabilidad.

Y es que todos los canales de la compañía deben desarrollarse y crecer formando parte de un conjunto homogéneo que consiga que la compra de un hotel o paquete vacacional sea una experiencia única y memorable.

Seguir leyendo «Vuelta a Centraldereservas.com como Product Manager»

La intuición no aplica en Ontruck

Seguimos con los post de la masterclass de @nachogil (diseñador de producto en Ontruck) en Factorystartup tocando ahora el tema de cómo realizan el proceso de diseño de producto.

Nacho nos cuenta el proceso de 8 pasos que siguen con cada nuevo desarrollo o proyecto basado en las características del producto de Ontruck.

Los 3 productos de Ontruck no son para cualaquier usuario. Es decir, no es un producto genérico tipo Facebook o Gmail. Con lo cual, el equipo de producto no es usuario de su producto, por lo que basan su aprendizaje en ser humildes y escuchar.

Eso les obliga a construir el producto que necesitan nuestros usuarios.

1. Comprender

  • Las ideas o problemas proviene de cualquiera.
  • Lo primero que hay que hacer es entender el problema.
  • No se piden soluciones, se plantean problemas. Las soluciones están sesgadas por la persona que las propone. Por cómo ve el problema, por cómo le afecta.
  • Nos importan los problemas, no las soluciones. Los problemas son más fáciles de compartir y discutir.
  • Observamos a los usuarios para comprender sus necesidades.

Y dijo esta frase que más valdría que muchas personas que cuestionan el coste de la UX y los métodos de research (investigación) deberían tener en cuenta:

Perder 1 día en ver y hablar con varios clientes te evita gastar 1 mes en desarrollo.

Clarito, ¿no?

2. Divergir

Una vez definido el problema, en una sesión de 2 horas, se reune todo el equipo (desarrollo, diseño y producto) e intentan pensar en soluciones obvias. El objetivo es intentar no seguir esas ideas, y generar entre todos la mayor capacidad de innovación.

Crazy Eights

Para ello, para diverger, y generar el mayor número de posibles soluciones, aplican técnicas para divergir y encontrar otras ideas, como Crazy Eights, Mapas mentales, Mapas de empatía,  How Might we…? o simplemente coger post-its y poner ideas y luego clasificarlas…

3. Decidir

En esta etapa el objetico es de las ideas viables que entran en scope clasificarlas y quedarse con una. Para ello:

  • Se decide el alcance del proyecto (scope).
  • Siempre se orientan a reducir el desarrollo. Mínimo desarrollo posible en todo (minimal waste, puro lean!), tanto en diseño como en código. Si puedes falsear la solución con algo manual, comprueba que es la adecuada y ya invierte el tiempo en hacerlo.
  • Se comparte con Tech, QA, Operaciones, Ventas y Mkt.
  • El resultado suele ser un plan para dividir el proyecto en varias fases.

Desarrollo de producto Lean

Ese plan siempre comienza con un MVP (Minimuml Viable Product) que si se puede hacer sin pintar pantallas y sin tirar código mejor.

Seguir leyendo «La intuición no aplica en Ontruck»

Proceso de desarrollo de producto en Ontruck

Continúo con la masterclass de @nachogil (diseñador de producto en Ontruck) y cual es su proceso de desarrollo para diseñar producto diseñado por Javier Escribano. Esta fue de las parte que más me gustaron con la que contaré en el siguiente artículo, por todo lo que me gusta aprender sobre metodologías de trabajo.

No creo en otra forma de desarrollar un buen producto que no sea siguiendo la filosofía Agile. Por ello creo en el trabajo colaborativo entre los diferentes miembros de los equipos, cuya aporte de conocimientos diversos es lo que hace que la suma del TODO sea mayor que cada una de sus partes.

No creo que exista un método perfecto, sino que cada empresa debe encontrar el que mejor se ajusta a su proceso. Pero después de haber pasado por varios tipos de empresas de desarrollo (producto propio, consultorías, startups…) creo que esta forma de trabajar va bastante bien encaminada.

El concepto es muy similar a lo que intentaban implantar en las otras empresas pero por lo que contó Nacho, bien hecho. La diferencia con las otras empresas está en el equipo (desde mi punto de vista). Ontruck está formado por un equipo senior que cree en esa forma de trabajar y tiene claro los objetivos que quiere conseguir.

Plan de producto

Un poco de información: Ontruck tiene un año de vida, 3 aplicaciones (una para los camioneros, otra para las empresas y otra interna para unis los 2 mundos) y están ya cerca de tener un equipo de casi 100 personas.

Formato de trabajo

Su formato de trabajo es el siguiente:

  • Cada año, lo dividen en 4 trimestres.
  • Cada uno con 2 Roadmaps estables de 6 semanas: 5 semanas de trabajo y 1 de reflexión.
  • Cada Roadmap tiene 2 sprints de 2 semanas cada uno de desarrollo de producto y una de estabilización.

Semana reflexión

Esta planificación basada en roadmaps es suficientemente corta para que no cambien las prioridades de negocio y suficientemente larga para poder construir productos/proyectos pequeños.

Seguir leyendo «Proceso de desarrollo de producto en Ontruck»

Scroll hacia arriba