Los diversos profesionales de Producto deben trabajar como un solo equipo, con una misma cultura. Esto sin embargo no siempre sucede; ya sea porque los líderes de Product Management, Design, Engineering y Data no están alineados en la forma de trabajar, o porque no forman a sus equipos para que tengan esa cultura. (View Highlight)
Tras mucho debatir, concluimos que estábamos metiendo demasiados procesos cuando el problema estaba en la cultura y en la actitud de ciertos perfiles. Por tanto, decidimos crear un Manifiesto con los Valores de un Product Engineer. En este artículo que escribí enDesdeelbarro expliqué los 5 valores que fijamos.
(View Highlight)
La gran ventaja que tuvimos al final es que íbamos muy rápido. Si “todo el mundo hace su parte” no invertimos tiempo en controles ni en procesos que no sean útiles para sacar una feature que resuelva un problema. Los PMs podían dedicar la mayor parte de su tiempo a hablar con usuarios y negocio, no a diseñar la solución (diseño+ingeniería), escribir user stories (ingeniería) ni a hacer QA (ingeniería). Diseño podía invertir más tiempo en testar las soluciones asegurando la calidad y escalabilidad a nivel de producto de lo que íbamos a sacar. E ingeniería proponía mejores soluciones que nos ayudaban a construir lo que necesitábamos para mejorar las métricas de una manera más rápida mientras aseguraban la escalabilidad técnica de la solución a futuro. (View Highlight)
Si sois dos personas las que lideráis producto e ingeniería (e.g. CPO y CTO), debéis ser uña y carne. Debéis tener claro la forma de trabajar que queréis, y que si cualquier persona pregunta o se queja, la respuesta que obtendrá de ambos sea la misma. No debéis ser Producto e Ingeniería. Debéis ser un solo equipo aunque oficialmente haya varios departamentos. (View Highlight)
Lo mismo que es necesario que suceda en el liderazgo de arriba, debe suceder también en todos los niveles. Un manager intermedio que no crea y que no sea ejemplo de la cultura de producto que queréis implementar, no va a formar correctamente a su equipo. (View Highlight)
Cuando hay conflictos entre roles y las cosas no funcionan, el playbook clásico es delimitar responsabilidades. ¿Qué debe hacer el PM? ¿Qué debe tener la PD para la grooming? ¿Quién hace la user story? Esto puede ayudaros a salir del bache, pero para ser un equipo de producto high performing deberéis ser perfiles multidisciplinares. (View Highlight)
Esto implica que los ingenieros se coordinan con la PM o PD para involucrarse desde el principio del problema, o el Engineering Lead hace el discovery, o la PD escribe la user story, o el ingeniero decide la solución, o el PM hace el QA más complejo. Las tareas del equipo se van balanceando según el proyecto, la disponibilidad, las fortalezas o planes de carrera de cada uno. (View Highlight)
El primero es que los ingenieros deben ser accountable (responsables de su trabajo). Os voy a ser sincero, me parece triste que tengamos que mencionarlo. Se debería dar por hecho que un profesional es responsable del trabajo que hace. Sin embargo, posiblemente por la mala cultura de trabajo que hay en muchas empresas, es un atributo que hay que validar al contratar y que formar continuamente. (View Highlight)
Para mí ser accountable significa que me responsabilizo de la calidad de lo que genero, que levanto la mano si tengo dudas o no estoy seguro, que intento dar lo máximo y que cumplo razonablemente con los tiempos que me comprometo. (View Highlight)
Un ingeniero no es accountable si mueve su ticket a QA o Done y contiene fallos obvios, si tiene dudas sobre todos los edge cases y no levanta la mano pidiendo ayuda, si su parte ya está hecha y no se preocupa de ayudar a su compañero, si tarda un día en hacer una tarea de dos horas o si se le complica una tarea y no lo comunica, ni pide ayuda ni ofrece alternativas. (View Highlight)
Este es el segundo atributo que muchos líderes de ingeniería me repiten constantemente. Todas las personas del equipo deben ser proactivas. Hay muchos ingenieros que no tienen esta actitud. En algunos casos por personalidad, y en muchos otros porque nunca nadie les ha dado voz o incluso se les ha callado. (View Highlight)
Si estás construyendo un producto, los ingenieros son realmente quienes saben cómo están las tripas, y qué es posible a qué coste. Si solo les das user stories a construir, te las harán pero buscarán el reto en cómo hacerlo mejor técnicamente. En cambio, si les das retos de negocio o de producto, te propondrán la mejor manera de hacerlo que respete los principios técnicos acordados. (View Highlight)
