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.

Sigue leyendo

Trabajando como Product Owner

Recientemente he trabajado como Product Owner, y me gustaría dejar constancia de como se estaba realizando esa tarea, ya que me parece un approach muy bueno para el desarrollo de un producto.

En este caso la empresa tenía un equipo de Producto que eran los que efectuaban el desarrollo del producto (research, entrevistas con usuarios, Design Sprints…) y cuyos stakeholders trasladaban las insights y nuevas necesidades de los usuarios al Storiesonboard.

Era mi misión dividir esas nuevas ideas en formato de User Story juntándolas en Releases, en base al valor aportado (marcado por los OKRs) al backlog en JIRA.

A continuación muestro una imagen del ciclo de desarrollo de US que empleábamos:

Produc Owner Cycle

Este ciclo no tenía porque hacerse completo. Si mientras ha estado en el backlog, se habían descubierto nuevas ideas, la User Story volvía al descubrimiento y al StoryMap. La cuestión era:

Minimizar la cantidad de trabajo no realizado.

Empleábamos:

  • Artefactos: Storiesonboard, JIRA, Trello y Slack.
  • Ceremonias (siempre con timing): Daily por squad y grupal (diaria, 15´), Syncro (una cada 2 semanas, 30-45´), Retros (cada 3-4 semanas, 60´) y Asamblea (cada 2 meses, 2h).

Story mapping

Para realizar storymapping usabamos Storiesonboard.com, un software (de pago) que actúa como una panel donde puedes ir distribuyendo las User Stories (US en adelante) en releases y features, y que permite organizar el crecimiento atómico del producto.

Story mapping

En los cuadrados azules, estaban los OKR de la compañía, en los amarillos las MMFs necesarias para alcanzar esos OKR, descritas como adjetivos. Por último, en blanco, debajo de la columna de cada feature, las US necesarias para alcanzarlas. A la izquierda, en letra azul, se marca en que Release o  MVP están esas US.

Lógicamente las MMF que tenían más valor estaban más a la izquierda, así como las US con más valor estaban más arriba. Para organizarlo es necesario que el PO disponga de conocimientos y experiencia en aspectos de negocio.

El JIRA estaba dividido en 3 paneles, uno para cada tipo de usuario que trabajaba con él, enlazando así el trabajo del equipo de desarrollo a los objetivos de negocio, muy importante para conocer el estado de una feature y seguir su trazabilidad.

MMF Board

El primer panel, es el MMF Board que posee 3 columnas “To Do, In progress y Done”. Las MMF son las Minimum Marketeable Feature, y puede haber varias por release, enlazadas entre ellas por una etiqueta de JIRA que indica el nombre de la release.

Sigue leyendo

Product Owning en Flywire

Al dejar Capgemini me surgió la oportunidad de colaborar durante 3 meses como externa en Flywire, una conocida empresa valenciana por su gran equipo de desarrollo.

Flywire

El trabajo en sí consistía en ser Product Owner de uno de sus squads, dentro de la nueva metodología de trabajo que les estaba ayudando a implantar @XaV1uzz, ya que han crecido muy rápidamente, y como sucede en muchas empresas cuando este caso ocurre, el proceso de ajuste y evolución es complejo. No es lo mismo pasar de gestionar 6 personas a 150 en 5 años.

Si acepte el reto (al día siguiente de finalizar en Capgemini) fue porque conocía la empresa gracias a que esponsorizaban los UXAcademy y a gente que trabajaba dentro de ella.

Además creo en las metodologías Agile y era una manera de aprender como lo estaban aplicando (había estado en otras empresas que se denominan “Agile” y quería ver otro ejemplo), con el añadido extra de que la mitad de la empresa está en Estados Unidos por lo que toda la comunicación es en inglés.

Sigue leyendo