Esta es una pregunta fabulosa y una que abordamos recientemente en una publicación muy popular titulada – Hey Gerentes de Producto – Deja de molestar a los ingenieros. Tiene que hacer y qué no hacer para los PM basados en nuestra experiencia en la construcción de seis compañías de software y ahora ¡Ajá! – La nueva forma de crear hojas de ruta de productos brillantes.
La intersección entre producto e ingeniería es donde sucede la magia para las compañías de software. Y una buena gestión de productos suele ser la diferencia entre mediocridad y asombroso. Si bien nadie extrañaría la administración de productos si (y usted) desapareciera en el corto plazo, garantizar la alineación del producto con la estrategia comercial, la oportunidad de mercado y la necesidad del cliente es lo que hacen los PM de superestrella en las compañías líderes del mercado.
Sin embargo, la realidad es que necesitas ingeniería más de lo que te necesitan a ti. Pueden continuar produciendo productos sin usted (y estar contentos de hacerlo), pero no puede escribir una línea de código usted mismo. Los ingenieros son el motor de fabricación que impulsa el negocio hacia adelante y son el activo no cliente más importante de la empresa. Estás por encima.
Entonces, ¿por qué la gente de productos sigue enojando a la ingeniería? “No los enojo”, piensas, pero considera las siguientes cinco formas comunes en que los PMs molestan a los ingenieros todos los días. Es una oportunidad para hacer una pausa y reflexionar verdaderamente. Sé honesto, ¿cuáles haces? Es un poco como el olor corporal, el autoexamen y la honestidad sin miedo.
Se misterioso
Lo que puede pensar: los ingenieros están ocupados y no les gusta hablar con la gente. Codificar todo el día es divertido, hablar con la gente es una tortura. Los ingenieros se confundirán si hablamos de la visión y la estrategia del producto. Además, ¿qué saben sobre el mercado, la competencia o los clientes? Mi visión es pura y deben seguirla. Es bueno involucrarlos lo más tarde posible y este nivel de misterio los mantiene interesados en lo que vendrá después.
Realidad : construir un gran producto es un proceso de colaboración que funciona bien si todos están de acuerdo con la visión y la estrategia del producto. ¿Por qué esperar para involucrar a la ingeniería en la planificación de su hoja de ruta hasta que haya establecido la dirección del producto? La transparencia genera confianza y la confianza conduce a un gran esfuerzo. Involucre la ingeniería temprano y con frecuencia, para que todos tengan la oportunidad de contribuir a la visión del producto y comprar el producto hacia donde se dirige.
Solo sigue hablando
Lo que piensas : no salen mucho y, aunque la codificación es divertida, puede ser solitaria. Confían en mí para contarles sobre el mundo real de los negocios y lo que piden los clientes, por lo que es mi responsabilidad contarles todo al respecto. Si sigo hablando en las reuniones de mi equipo de productos y preguntando qué necesito, les ayudará a construirlo. Y es difícil detallar las características, entonces, ¿por qué molestarse? Discutamos.
Realidad : escríbelo. Usted es un experto en ingeniería y propenso a cambiar las prioridades según lo que le pidió el último [ complete el espacio en blanco con el cliente, ventas, ejecutivo]. Es poco probable que tu visión más reciente sea más importante que en lo que ya estaban trabajando, así que deja de molestarlos. Poner en marcha un plan y articular características e historias de usuarios en detalle te hace apreciar los matices de lo que estás pidiendo y lo que se necesita para construirlo. También le da al equipo una forma de comentar y hacer preguntas, en última instancia, ayuda a refinar lo que está pidiendo antes de escribir una línea de código.
Explica cómo hacerlo
Lo que puede pensar: He estado cerca de ingenieros por mucho tiempo y sé la diferencia entre NoSQL y MySQL. Y no hay duda de que habría sido un gran ingeniero si hubiera aprendido a programar, lo encontrara gratificante y liderase una tonelada de proyectos de código abierto. Por lo tanto, es mi responsabilidad recomendar cómo la ingeniería debe implementar lo que pido. El “cómo” es un aspecto importante para sacar el producto por la puerta, y voy a estar allí con ellos en cada decisión arquitectónica importante.
Realidad : Está desperdiciando su tiempo y la paciencia de la ingeniería. Concéntrese en el “por qué” y el “qué” y deje los bits “cómo” se desarrollan para la ingeniería. Y hagas lo que hagas, no entierres un agujero más grande al sugerir lo difícil o fácil que es algo o cuándo el equipo lo entregará.
Crédito acumulado
Lo que puede pensar: soy gerente de producto porque prospero en el centro de atención. ¿Quién más en la organización tiene la visibilidad para el equipo ejecutivo como yo y a quién se llama con más frecuencia para cerrar un trato, salvar un trato, hablar con la prensa, convencer a los analistas o comprometerse con un socio? Soy una fuerza de negocios unipersonal y los elogios son mi combustible. La mayoría de nuestras grandes ideas son mías de todos modos y yo soy quien impulsa la ingeniería para entregar.
Realidad : los grandes líderes desvían los elogios y dan crédito a los demás. Lo hacen porque saben que el equipo casi siempre logra grandes esfuerzos y que desviar los elogios genera confianza y es la mayor recompensa por el éxito. Los gerentes de productos de Sage siempre tienen la cabeza en alto y están pensando en lo que sigue y cómo trabajar en el interés del equipo. Para cuando el equipo cumple, los PM brillan. Reparta los elogios como si fueran dulces en Halloween en Atherton.
Echar la culpa
Qué puede pensar: tengo una excelente estrategia de producto y escribo requisitos perfectamente claros. Pero construir un gran software es difícil e impredecible (sin importar la metodología de desarrollo que estemos usando). Y todos saben que a veces las cosas salen mal, independientemente de mis esfuerzos hercúleos. Incluso se nos anima a fallar rápido. Sin embargo, solo para estar seguros, siempre es bueno destacar públicamente lo que podría salir mal con un lanzamiento. La buena noticia es que cuando las cosas salen mal, generalmente es el software y todos sabemos quién crea el software: ingenieros. Con esto en mente, es bueno plantar las semillas de la incertidumbre temprano y asegurarse de que los problemas potenciales se identifiquen como centrados en la ingeniería. Solo trato de ser transparente sobre los riesgos.
Realidad : debes buscar la incertidumbre y los problemas y absorberlos. Recuerde que le encanta ser un gerente de producto, por lo que debe tener sus propios problemas en todo el producto, incluido el producto de software central. Comprenda los matices de un problema determinado y aprenda a articular claramente cualquier impacto y solución. Explicar las diferentes soluciones potenciales y las compensaciones de cada uno y verdaderamente liderar. Grandes PMs desvían los elogios mientras están bajo la gloriosa luz del sol y absorben los problemas en las sombras.
¿Haces alguna de las anteriores? Todos lo hacemos.
Solo recuerde que los grandes gerentes de productos operan desde una posición de conocimiento y confianza, pero dependen de los ingenieros para el éxito del producto, el negocio y la carrera. Su trabajo es liderar humildemente con convicción, centrarse en el “por qué” y el “qué” y poner a su equipo de productos e ingeniería en una posición para brillar.