¿Debe un gerente de producto contribuir activamente a la base de código de una empresa o producto?

Primero, supongamos que estamos hablando de una compañía establecida de algún tamaño con un equipo de desarrollo dedicado. Ciertamente, alguien que forma parte de una startup de tres personas y designó al “gerente de producto” probablemente esté contribuyendo a la base del código.

Dado ese supuesto, entonces no, un gerente de producto no debería estar involucrado en la codificación de algo en lo que está trabajando activamente como producto. Esto difumina la línea demasiado lejos entre la definición del cómo y el por qué. Los desarrolladores y los evaluadores de control de calidad son responsables del código; Los PM son responsables de proporcionar dirección. Los PM nunca deben escribir código que vea la luz del día para un cliente o cliente. La carga de escribir, probar y mantener ese código no es más que una distracción del propósito principal de un PM.

Ahora, habiendo dicho eso, lo complica un poco agregando “ejecutar consultas pequeñas”. Personalmente, he encontrado que es extremadamente valioso en mi tiempo como PM para ser lo suficientemente hábil en SQL para ejecutar mis propias consultas en bases de datos de respaldo ( nunca en producción). Sin embargo, esto no es realmente “codificación”, al menos no en los conceptos tradicionales de escribir código, comprometer código y probar código. Es más una actividad secundaria, y debe hacerse solo cuando está buscando datos para respaldar una hipótesis o para construir su propia comprensión de sus usuarios y su comportamiento.

Un gerente de producto es un trabajo a tiempo completo. Siempre hay algo que él o ella podría estar haciendo, durante un ciclo descendente, en apoyo de su rol de producto. Investigar a los competidores, hablar con los clientes y hacer una lluvia de ideas de nuevos productos siempre se gastan mejor que la codificación.

Pero digamos, solo por el argumento, que el gerente de producto tiene algo de tiempo extra para codificar. Estaría de acuerdo, pero tienen que seguir las mismas prácticas y trabajar dentro de los estándares del equipo de ingeniería. En mi experiencia, este es el mayor problema con los gerentes de producto que escriben código. Hacen algo que está fuera de banda con el resto del código y termina causando trabajo adicional para los ingenieros. También es mejor que el gerente de producto esté completamente preparado para admitir ese código cuando se rompe en medio de la noche. Recuerde que el equipo de ingeniería es responsable de su trabajo.

Si.

En realidad, depende de lo que quieres decir con contribuir activamente. ¿Se le pide al PM que codifique activamente? Si es así, ¿por qué la compañía siente que el primer ministro no debería estar con los clientes mirando cosas como JTD y estudiando el mercado?

Si es voluntario, depende de muchas cosas como la cultura, su posición en la empresa, etc. A continuación está mi opinión basada en mis experiencias.

A veces un PM tiene un gran punto de vista. Siempre creo que si usted no es la persona que realmente está resolviendo el problema, puede ofrecer muchas ideas únicas que podrían no ser evidentes para los demás que analizan el problema.

Desde mi experiencia, al ofrecer una sugerencia, he visto a muchos desarrolladores que desean hacer una mejor y superarme por un margen significativo. Ganar-ganar. Además, a veces simplemente no tendrán el ancho de banda para investigar un nuevo tema para mejorar y es posible que solo les proporcione información suficiente para comenzar.

Siempre que haga esto, nunca olvide que es la persona que entiende mejor a los clientes y que siempre aporta esa perspectiva incluso a las ideas de desarrollo.

Sin embargo, diría que en su lista de prioridades como PM, esta actividad debería ser bastante baja. (<= 5% más o menos de su tiempo disponible)

Depende de los siguientes aspectos:

• Tamaño de la empresa o del equipo.
• Tu conjunto de habilidades.
• Voluntad y aptitud
• Rol del gerente de producto en su empresa (¿es como el dueño de un producto?)
• Las responsabilidades principales no se ven comprometidas, sin embargo, está teniendo un impacto en la entrega

Recuerde que es solo un complemento y depende de varios aspectos además de estos.

En una nota al margen, probablemente este artículo ayudaría a comprender la “ingeniería” que es bueno tener para un gerente de producto: 6 maneras para que los gerentes de producto mantengan a sus desarrolladores felices e inspirados

Si el primer ministro tiene un minuto adicional más allá del usuario, el dominio y los datos, entonces debería dedicarse a evangelizar su producto para que los mejores diseñadores y desarrolladores trabajen en él, en lugar de codificarse.

No estoy de acuerdo con el dogma de que la única forma en que puedes ser un buen gerente de producto es si aprendes a codificar. Creo que las empresas que requieren un título en ciencias de la computación para sus puestos de producto están pasando por alto un gran talento de producto.

Dicho esto, sé cómo codificar, me gusta construir cosas por diversión y comencé mi codificación profesional. Creo que hay beneficios para que todos aprendan a codificar. Escribí más sobre por qué aquí: ¿Deberías aprender a codificar?

Los gerentes de producto deben poder comprender una discusión técnica y las ramificaciones de las decisiones técnicas. ¿Necesitas ser un programador para determinar eso? Usualmente no. ¿Los desarrolladores necesitan saber cómo entrevistar a los clientes para hacer su trabajo? No, necesitan entender cómo usar la información que traes de una de esas entrevistas.

Ver mi publicación de blog – Carrera: ¿Deberías aprender a programar?

Si.

El equipo de desarrollo debe tener una retroalimentación posiblemente rápida sobre su progreso actual y el gerente de producto debe comprender qué es posible y cuáles son los mayores desafíos tecnológicos.

El gerente de producto seguramente debe centrarse en hablar con los clientes y construir el producto a través del equipo de desarrollo, pero de vez en cuando es bueno si comprende cómo funciona toda la aplicación.

Si.

No hay necesidad de establecer reglas artificiales sobre nunca codificar.

De hecho, pienso menos en cualquier gerente de producto que no pueda codificar. Y creo que es menos un gerente de producto que el que puede codificar, pero establece alguna regla para no hacerlo.

Dicho esto, la gestión del tiempo también es clave. El rol de trabajo de un gerente de proyecto es administrar el producto. Entonces, si eso significa solo pasar 5 minutos al día o 5 minutos a la semana codificando, que así sea.

En realidad, la demanda viene a borbotones. Un primer ministro podría no tener una necesidad real de codificar durante semanas, y de repente aparece una nueva fecha límite y se pone las mangas y ayuda al equipo durante 2 días seguidos.

Después de lo cual, las cosas vuelven a la normalidad.

Aún así, el respeto que el primer ministro recibe por ser capaz de “salir de la banca” hará que esa persona sea mucho más poderosa y respetada.

No. Creo que un gerente de producto debe tener una gran comprensión del código y de cómo funcionan las cosas, pero ensuciarse las manos es una pérdida de tiempo, debe concentrarse en problemas mucho más grandes a corto y largo plazo.

Como dijo Cliff, esto se basa en la suposición de que no estás en una pequeña startup que cubre muchos roles diferentes