El cambio es una constante [el camino de un Product Analyst]

El cambio es una constante [el camino de un Product Analyst]

Parece paradójico encontrar la palabra cambio y constante en un mismo titulo, pero no lo es tanto, dado que el proceso de transformación es…

El cambio es una constante [el camino de un Product Analyst]

Parece paradójico encontrar la palabra cambio y constante en un mismo titulo, pero no lo es tanto, dado que el proceso de transformación es lo único que se mantiene en el tiempo, independientemente si lo queremos o no 😛

En el anterior articulo “La adaptación al cambio nos da la ventaja” me centré en como lo equipos y las compañías principalmente requerían cambiar ciertas formas de hacer las cosas, o incluso los objetivos que podían sentenciarlas a la extinción.

Evolucionar o desaparecer: Lecciones de Kodak, BlackBerry y Blockbuster

En esta ocasión abordaré uno de los procesos mas importantes, la transformación personal, de que manera vamos evolucionando a partir de nuestras fortalezas, hasta convertirnos en analista de producto [digital en este caso] inmersos en procesos y actividades que nos llevan a enfocarnos en brindar soluciones y cubrir necesidades insatisfechas a un conjunto de usuarios que esperan ser escuchados.


Nuevo panorama

A partir de nuevos paradigmas como el que plantea David Rogers en su libro “The Digital Transformation”, comienzan a hacerse a un lado los hábitos pasados de pensar y operar como negocio, ahí es donde comienza la transformación digital, enfocando la estrategia de las empresas en relación al servicio ofrecido al cliente y en la propuesta de valor diferencial.

En ese contexto, en el que las empresas empiezan poco a poco a convertirse en User Centric, las formaciones profesionales sobre las cuales fuimos haciendo carrera quedan algo escasas o mejor dicho, incompletas.

La incursión en el mundo de Producto ya no es exclusiva de ninguna competencia, formación o rama de estudios particular, esa vieja creencia que para trabajar en esta área era necesario haber estudiado alguna carrera de sistemas ha quedado sumamente atrás. En este nuevo escenario se abre un panorama para muchos, para los que veníamos como Analistas Funcionales (con formación mas técnica o “dura”) veiamos que ya las tareas no eran solo documentar servicios, especificar los tipos de datos que viajan o hacer el D.E.R, por otro lado, los de formaciones mas “blandas” comenzaban a sumarse e incursionaban en la construcción de productos digitales, algo lejano hasta hace unos años.

Comenzó un era donde los equipos se conforman con Licenciad@s en economía, Ingenier@s industriales, Licenciad@s en sistemas, Matemátic@s, Contadores Públicos, Diseñadores gráficos y mas …

Este tiempo da nacimiento a un rol mas completo, el de Product Analyst.


Metamorfosis

Como muchos casos, la biología puede ser una gran fuente de inspiración para describir ciertos comportamientos y en este caso lo tomo para ejemplificar el proceso, que desde mi óptica, hemos pasado muchos hasta una madurez y entendimiento sobre la construcción de producto.

Dado que no existe enseñanza formal que nos prepare para desempeñar el rol de producto, mucho llegamos en un estado de larva, llegamos con una o varias fortaleza necesarias, pero con un largo camino en este nuevo desafío de la industria y el negocio. El rol de producto conjuga varias habilidades que nos permiten desenvolvernos en un ámbito sumamente complejo y sobre todo, nos permite reconocer los aportes de todos los equipos que intervienen en el desarrollo del negocio y de un producto digital.

En la siguiente etapa de este proceso pasamos a uno de los momentos mas relevante del Metamorfosis, la crisálida. Pero cual es el camino?, Transformarnos en que?

El trabajo de producto es “descubrir un producto valioso, utilizable y factible”, por lo menos así lo describe Marty Cagan

En esa linea hay tres áreas bien marcadas sobre las que trabaja producto y de alguna forma indican la guía de los conocimientos a desarrollar, por eso Martin Eriksson menciona que “un buen gerente de producto debe tener experiencia en al menos uno y pero ser apasionado por los tres”.

Imagen contenida en el articulo “What, exactly, is a Product Manager?” de mindtheproduct.com

TECH

En mi caso, como venia mencionando, mi fuerte estaba en lo técnico, desarrollador de Visual Basic y .Net (dejo referencia para los millennials y cenntenials ) en los comienzos, siempre estuve mas cerca de IT que del usuario y eso me hacia poder pensar el producto desde un aspecto mas duro, pero super necesario.

Necesitamos conocer el código o desarrollar ? , claro que no.

  • Conocer los equipos y los Stack de aplicaciones: Es vital conocer los equipos de tecnología con lo que vamos a trabajar, sobre todo, tener una relación cercana para evaluar factibilidad y alternativas que nos permitan pensar las soluciones y posibles M.V.P.
  • También es fundamental tener un conocimiento general de los componentes del producto (capa de servicios, capa de UI, capa de datos, capa de integración, capa lógica, etc) para reconocer el impacto y los tiempos que pueden implicar avanzar en una u otra solución.
  • En muchas empresas, incluso será necesario conocer el lenguaje o nombre de las aplicaciones que brindan servicios y entender que potencial de información tiene, para ello, nada mejor que recurrir al glosario o armar uno simple.

BUSINESS

Otra de las áreas a dominar es la que fundamenta la propuesta de valor de cara a la compañía y está representada por el Negocio o el área Comercial, pero además es trabajar sobre los procesos relacionados con la administración de los proyectos.

Necesitamos conocer sobre contratos y negociar comisiones?, claro que no.

  • Conocer la estrategia de negocio y el valor que aportan nuestras acciones en pos del objetivo, sobre todo para tomar decisiones que acompañen las metas de la compañía.
  • Reconocer el retorno de inversión (R.O.I) de cada iniciativa que surja desde esta área es vital para poder realizar un plan acertado y sobre todo un seguimiento de los indicadores que realmente se alineen con los objetivos. En general suele presentarse en forma de caso de negocio (Business Case) donde se plantean escenarios variados y resultados esperados que está bueno desafiar en la previa y validar a posterior.
  • También es mas que importante el orden y prolijidad con la que se lleva adelante un proyecto, con la metodológica que uno prefiera, pero considerando: Visibilidad de avances; claridad en los acuerdos entre los interesados; cuales son los Interesados principales que con los cuales vamos a interactuar (importante reconocer el cargo de las personas con las cuales mantendremos comunicación) y planificación de las iniciativas para hacer un buen seteo de expectativas.
  • Dejo para el final la piedra basal que le da fuerza al rol, el conocimiento de los indicadores principales del producto, del mercado y de los usuarios con los cuales deberá interactuar. Tanto el seguimientos de indicadores como su medición es lo que le brinda interpretación de lo que está sucediendo mas allá de un código “lindo”, un diseño “limpio” o una gran producto negociado por el equipo comercial.

UX

Por último el área mas blanda y mas cercana al usuarios sobre todo por la naturaleza de las herramientas que utiliza que buscan constantemente retroalimentación con ellos.

Necesitamos saber diseñar o conocer Sketch ?, claro que no.

  • Tener presente los patrones de diseño utilizados y el histórico de los diseños, para ver el espectro de elementos disponibles al momento de evaluar cualquier iniciativa o pensar soluciones.
  • Conocer a través de las investigaciones o reportes que se puedan llevar adelante el equipo de Research, tanto en pruebas de nuevos features, entrevistas o guerrillas (pruebas con prototipos reducidos en funcionalidades con los usuario) que nos dan feedback.
  • Importante nunca dejar de tener contacto directo con los usuarios a partir de la lectura de reseñas de los usuarios, comentarios de la experiencia o incluso aquello que dicen sobre la competencia para no perder de vista aquello que pasa en el mercado.
  • También es importante poder representar de forma básica prototipos que ejemplifiquen soluciones y que sean mas gráficos al momento de discutirlo con interesados diversos.

En resumen

Un analista de producto no nace como tal, se hace, se forma en diferentes áreas para aportar valor al momento de priorizar que iniciativas dan mas valor a la compañía conociendo aquello que espera el usuario, pero sobre todo, haciendo match con aquello que tenemos para ofrecer como empresa.

Cuando ocurre ese match y nos planteamos objetivos medibles, tenemos que ser capaces de representar con claridad lo que se espera para trabajar en una solución visual, evaluado los costos de construcción de un producto mínimo que aporte valor al usuario en un plazo relativamente corto.

Dominar estas áreas con fluidez (no digo con sincronía de reloj suizo), nos coloca en el kilómetro uno de una etapa final del aprendizaje como Product Analyst, ya no somos los mismo que entraron ese primer día, superamos diferentes etapas y nos transformamos, abrimos las alas (etapa adulta) para comenzar nuestro vuelo, para continuar sumando conocimientos en este cambio continuo.

Si considerás que te aportó nueva información para enteder el rol de producto dejá tus “Claps” en el articulo de Medium y tus “Likes” en la publicación de LinkedIn. 😀 Se agradece de antemano y también quedo a atento sobre algun aspecto del Product Manager que quieras que escriba, solo dejá tu comentario.

Gracias !

Metamorfosis de las mariposas

Artículos relacionados e inspiración