Primero de Product Manager (I): el equipo de tecnología.
O ¿cómo trabajar con un equipo de tecnología sin ser ingeniera?
Para crear productos digitales que los usuarios adoren y que sirvan a los objetivos de negocio se necesita un equipo de tecnología fuerte y motivado. Y como Product Managers podemos aportar mucho aun sin tener un perfil técnico.
He trabajado con excelentes equipos de desarrollo en mi paso por idealista, Solera GDC y Tuenti (ahora como Telefónica Customer Experience) y he podido comprobar qué cosas funcionan mejor (y también las que no funcionan tan bien) a la hora de trabajar con tecnología. Aquí va la lista de las cosas que sí funcionan ;)
👩💻 El equipo de ingeniería en todas las fases del proceso.
¿Quién ha dicho que el equipo de desarrollo no debe participar en el descubrimiento del producto? Mucho antes de que se haya decidido qué producto digital se quiere desarrollar (Product Discovery) hay mucho trabajo de análisis previo de necesidades de negocio, investigación con usuarios para encontrar las oportunidades, estudios comparativos… todo esto normalmente recae sobre los equipos de Producto, Diseño y Research pero es imprescindible que el equipo de tecnología está involucrado desde estos momentos iniciales. Les ayudará a tener mucho más contexto sobre lo que se va a trabajar. Y además todo el feedback que recibamos por su parte nos ayudará a definir mejor el producto que queremos lanzar.
Hay muchas fases en la creación de producto digital en la que el equipo de tecnología participa, pero una en las que no se les suele incluir es al analizar los resultados de cómo está funcionando el producto que hemos lanzado: qué uso se está haciendo de él, qué más hace un usuario que está usando la funcionalidad que hemos desarrollado, en qué parte del flujo se pierden los usuarios, etc. Así todos podremos conocer de primera mano cómo está funcionando nuestro producto y ver en qué puntos (tanto técnicos como de diseño o producto) podemos iterar para mejorar.
🎯 Crear nuestros objetivos como equipo conjuntamente.
No importa si usamos metodologías como las de OKR (Objectives and Key Results) o si simplemente hacemos planificaciones anuales, en cualquier caso siempre necesitaremos que los objetivos del equipo hayan sido definidos por todo el equipo en su conjunto. No es responsabilidad exclusiva del equipo de negocio o del Product Manager elegir qué se debe conseguir en un plazo de tiempo, sino que nuestro objetivo y propósito es algo que debemos decidir conjuntamente entre tecnología, producto, diseño y análisis de datos. Ésta es la magia de equipos multidisciplinares, autónomos y empoderados.
💬 Comunicación, comunicación y más comunicación.
La comunicación es más importante que los procesos establecidos. Vamos, que hablando se entiende la gente. No importa si es en la daily (reunión diaria), por chat grupal o individual, levantando la vista del ordenador para preguntar… nunca dejes de preguntar algo que no tienes claro, y nunca dejes de dar toda la explicación, justificación y contexto necesario ante cualquier duda que plantea el equipo.
🖊️ Define de tal manera que facilites el trabajo al equipo de desarrollo y de calidad.
Aquí dependerá mucho de las preferencias de cada equipo y de los procesos establecidos en cada empresa, pero por nombrar algunas herramientas:
- PRD (Product Requirement Document) un documento vivo, alimentado al mismo tiempo por producto, diseño, tecnología, y analítica de datos, donde se describe una funcionalidad o producto. Un elemento clave para realizar estimaciones, y para ir actualizando y cambiando a medida que avanza el desarrollo. Es un documento del equipo en el que todos debemos colaborar.
- Historias de usuario (User Stories) ya sea en JIRA, Trello o cualquier otra plataforma. Hay muchas maneras de escribirlas, pero un básico “Como persona (rol), quiero (acción), de tal manera que (beneficio)” nos puede ayudar a pensar, dar contexto y estructurar la historia.
- Criterios de aceptación (o escenarios) que ayudan a saber al equipo de desarrollo y de calidad (QA- Quality Assurance) que la historia de usuario consigue su propósito. Aquí también la estructura básica es “Dado (un contexto), Cuando (el usuario hace algo), Entonces (tiene que ocurrir esto)” es muy útil para definir lo que se espera de una historia de usuario.
🙋Participa en el proceso de desarrollo, integración y puesta en producción.
Cuando los ingenieros inician el desarrollo no termina el trabajo de Product Manager, ¡en absoluto! Durante el desarrollo surgen muchas dudas que deben resolverse rápidamente, se deben tomar muchas decisiones de qué tareas empezar y asegurar que no tengan bloqueos, y en cuanto hay algo listo que se puede “ver”, hay que realizar demos, recoger las primeras impresiones, verificar las tareas antes de que pasen a integración, revisar en varios entornos, etc. Si no sabes cómo, pide ayuda a tu Tech Lead. Estará encantada/o de que te preocupes de todo el proceso.
Así que no importa que no sepas tirar ni una línea de código, que no sepas leerlo, que no entiendas las llamadas que se realizan al servidor… puedes y debes aportar mucho. Habla con tu equipo, pregúntales qué puedes hacer para ayudarles más en su trabajo. No lo preguntes una sola vez, pregúntalo muchas veces. Así poco a poco construiréis vuestra propia forma de trabajar que sirva a vuestros objetivos.
Y en tu caso, ¿qué es lo que te funciona mejor para trabajar con el equipo de tecnología? ¡Te escuchamos!
