¿Debe un gerente de producto saber codificar? ¿Es un requisito que un PM sea desarrollador o sepa cómo escribir un código?

Sí.

No necesita ser tan bueno como ingenieros de tiempo completo, y no necesita contribuir a la base de código de producción.

Pero sí necesita ser fluido en los fundamentos para ganarse el respeto de los ingenieros de su equipo y comunicarse efectivamente con ellos sobre las prioridades y las compensaciones.

El gerente de producto es un papel muy crítico para el éxito del negocio. Sin embargo, para convertirse en gerente de producto, debe dejar de ser ingeniero y comenzar a buscar el producto como la perspectiva del usuario. Si ha comenzado su carrera como programador, no es fácil hacer la transición, aunque no es imposible.

Como gerente de producto,

1. Deja de pensar en el código y comienza a pensar en los usuarios

2. Obtenga un sólido control sobre el mercado, la competencia y las tendencias.

3. Comprender los problemas profundamente

5. Piensa experiencias, no características

6. Invierta en diseño

7. Escucha atentamente

8. Generar confianza con el equipo.

9. Pase mucho tiempo en marketing

10. Anima al equipo y celebra las victorias

Lea este hermoso artículo que nos inspiró y compartimos entre nuestro equipo.

El día que realmente me convertí en gerente de producto – Creación de prototipos: de UX a Front End

Soy Nachiket Patel, cofundador de Digicorp. Desde 2004, Digicorp está creando productos de software significativos y utilizables para nuevas empresas y pequeñas empresas. Ahora también desarrollamos nuestros propios productos y derivamos el más prometedor como un negocio separado.

No hay una respuesta correcta a esta pregunta. Pero una buena comparación que puedo ver es con los gerentes profesionales de clubes de fútbol / fútbol: “¿Cuántos de ellos no han jugado al fútbol?” Creo que la respuesta sería: “0”, lo habrían jugado por diversión al menos, si no profesionalmente Similar es el caso con el rol de un “Gerente de Producto”. El diagrama clásico de PM muestra a PM como una persona que actúa como un punto de intersección para negocios, clientes y tecnología.

Y para lanzar el producto, PM debe trabajar muy de cerca con los equipos de ingeniería, entrenándolos, guiándolos, ¡entusiasmándolos a ganar! Esencialmente similar a lo que hace un entrenador de fútbol: estar con los jugadores para tener éxito. Al mismo tiempo, él / ella aprende otros matices que conlleva ser un gerente (gestión de clubes, finanzas, marketing, etc.). Entonces, saber: cómo codificar tiene sus ventajas. Sería como hablar un idioma que los ingenieros entienden, lo que facilita el proceso de comunicación. La mayoría de las veces, los equipos fallan porque el líder no habla el idioma del equipo. Imagina una situación en la que eres un gerente de la Premier League inglesa y reclutaste a un jugador indio (que solo habla hindi). ¡Será difícil ayudarlo a triunfar y jugar de la manera que quieres que juegue!

Dicho esto, al desarrollar habilidades en otras áreas, como los negocios, los clientes también son igualmente importantes. Cuanto más se hablen diferentes idiomas que hablan los diferentes círculos, usted como PM estará preparándose para el éxito del producto y su crecimiento.

Si bien saber cómo codificar tiene distintas ventajas, también puede ser un PM exitoso con una sólida experiencia en negocios / clientes. Un buen PM aprenderá a comprender todos los pilares: cliente, empresa y tecnología, a fin de imaginar un producto increíble y registrar un excelente crecimiento.

Soy un primer ministro para un producto web de consumo y hago mucha experiencia de usuario. Me llamaría no técnico. Estas son las áreas en las que he encontrado un poco de conocimiento útil, o donde he deseado tener más opciones de codificación:

Alcance y priorización del trabajo.
Poder entender por qué algo va a tomar 4 semanas cuando crees que debería tomar 4 días es importante. Aprenderá de la experiencia cuando los proyectos sean astutos y difíciles, pero no está de más conocer los fundamentos sobre lo que dificulta un problema desde una perspectiva de codificación.

Dicho esto, siempre me ha parecido valioso preguntar: “¿Pueden ayudarme a comprender qué hace que este sea un proyecto grande / difícil?” Hacer preguntas y luego hacer preguntas de seguimiento puede llevar a una solución creativa que ahorre mucho trabajo sin matar la experiencia de usuario. Entonces, para este, diría que algunas habilidades técnicas (o simplemente mucha experiencia) lo ayudarán a comunicarse con los desarrolladores, pero nunca debe dejar de hacer preguntas (ya sea que sepa cómo codificar o no).

Tener valiosos comentarios de interacción y no pedir una experiencia de usuario de ciencia ficción.
Ahorrará mucho tiempo y dolor a todos si sabe lo que se puede y no se puede hacer con HTML y CSS. Si sus comentarios de UX son, “¡solo hágalo caliente!” o “¡haz que sea esa escena en Minority Report!” probablemente deberías repasar tus conceptos básicos.

Estoy un poco pasado ese punto, pero todavía soy débil en todas las cosas geniales que CSS y jQuery tienen para ofrecer. Saber lo que puede hacer con el diseño interactivo es una habilidad importante para los PM que hacen UX.

Ayudando donde puedas
Especialmente en un inicio pequeño, poder enviar ajustes de copia, cambiar la página de inicio o algún HTML estático, rediseñar algo, etc. son todo tipo de cosas con las que te encantaría evitar que tus desarrolladores tengan que lidiar.

La codificación no es un requisito absoluto para un PM si eres realmente bueno en otras cosas, por ejemplo, si eres un experto en dominios en el espacio de problemas de tu cliente, tienes una visión clara de una posible solución para resolver el problema de tu cliente, conoces el diseño UI / UX al revés, etc.

Sin embargo, aprender a codificar o, al menos, poder leer el código de sus ingenieros es muy útil si desea entregar un producto a tiempo. Bill Gates solía leer el código de sus programadores y enviar correos electrónicos al respecto.

Un gerente de producto también tiene la gran responsabilidad de poder elegir las mejores tecnologías que se necesitan para construir un producto. Un primer ministro necesita comprender las capacidades de las últimas tecnologías de vanguardia (y sus API) que el equipo de ingeniería está promoviendo para construir su producto.

Hay algunas situaciones en las que debe comenzar a codificar y administrar su equipo de ingeniería si su equipo de ingeniería tiene menos experiencia y no tiene un gerente de ingeniería de nivel superior en el personal para guiarlos.

Haga clic en https://www.linkedin.com/pulse/s … para ver lo que tuve que hacer en una situación reciente. Por lo tanto, aprender a codificar o, como mínimo, poder leer el código de otros es una muy buena habilidad para un PM.

Sí, creo que los PM deberían saber cómo codificar si están trabajando en productos de software. Como he trabajado como ingeniero de software y un primer ministro, puedo ver varios motivos:

1. Como PM, lideras por influencia y no por autoridad de un gerente de ingeniería. Poder hablar con los ingenieros y hablar su idioma ayuda a convencerlos de que vale la pena trabajar en su idea o característica propuesta. Los ingenieros generalmente se dan cuenta de que informan a un gerente de ingeniería y no a un primer ministro y, por lo tanto, no son realmente responsables ante un primer ministro. Además, los ingenieros a menudo tienen opciones de proyectos o ideas para trabajar, pueden cambiar proyectos o equipos si no están convencidos de la idea. Por lo tanto, poder hablar, entusiasmar y convencer a los ingenieros para que trabajen en su idea requiere conocimientos técnicos. Además, ser técnico lo ayudará a identificar qué ingenieros tienen las habilidades adecuadas para trabajar en su proyecto.
2. Una de las responsabilidades clave de un PM es priorizar las tareas y clasificarlas según la cantidad de esfuerzo o recursos requeridos. Tener una formación técnica ayuda a evaluar mejor las tareas y priorizar bien las cosas durante la planificación del sprint o al hablar con los clientes.
3. Si usted es un primer ministro que trabaja en un producto técnico como una API, plataforma de datos, plataforma de prueba A / B, etc., estos productos a menudo requieren mucho control de calidad y se aseguran de que las preocupaciones del cliente se aborden bien. Un PM que sea técnico puede escribir rápidamente sus propias pruebas unitarias, scripts, SQL, hacer análisis de potencia o mirar archivos de registro para comprender los problemas que enfrentan los clientes. Esto puede ayudar a mejorar la comunicación con la ingeniería y entregar productos más robustos al mercado. El éxito del producto recae principalmente en los hombros de un PM, por lo tanto, el trabajo de clasificación técnica no está exactamente fuera de los límites para un PM y, por lo tanto, ser técnico puede ser un gran activo.

No. No. No. No. Y si eso no fue lo suficientemente claro, entonces no .

Estoy totalmente en desacuerdo con aquellos que han dicho que sí. Lo siento amigos, pero no entienden de qué se trata la Gestión de Productos (Software) o no leyeron la pregunta correctamente (o ambas cosas).

La pregunta pregunta explícitamente: “¿Es un REQUISITO ” + “para que un PM sea ​​desarrollador ” + “o sepa cómo escribir un fragmento de código?”

• No, NO es un requisito.
• No, el primer ministro no necesita ser desarrollador.
• No, no necesita saber cómo escribir un código.

¿Qué es la gestión de productos?

La gestión de productos es una función multifuncional, que se centra en definir y gestionar las actividades, condiciones y situaciones para el éxito del producto.

Abarca muchas cosas como:

• Comprensión empresarial y habilidades
• Conocimiento del dominio
• Comprensión de la tecnología y el diseño.
• Pensamiento de procesos y sistemas.
• Habilidades de liderazgo y comunicación.

Puede ser beneficioso …

En algunos casos, PUEDE ser útil o incluso necesario comprender cómo codificar, por ejemplo, si usted es el Gerente de Producto para API que serán utilizados por los desarrolladores.

Pero eso se debe a que la naturaleza del producto (las API) que está administrando está explícitamente diseñada para usarse en un contexto de desarrollo.

Pero en la mayoría de los otros casos, no hay necesidad.

Un buen PM * de software debe * comprender el proceso de desarrollo de software, comprender los aspectos de la arquitectura de software y los * tipos * de tecnologías que utiliza su software que son relevantes para las discusiones sobre los requisitos de software.

Por ejemplo, ¿cómo puede conversar con su equipo de desarrollo sobre las decisiones arquitectónicas que quieren tomar si no comprende la arquitectura del software y las implicaciones de esas decisiones? ¿O simplemente para saber qué preguntas hacer para obtener la información que necesita para tomar decisiones?

Preguntemos esto desde otra perspectiva. ¿El gerente de producto de Quicken (producto de Intuit) necesita saber acerca de la codificación? ¿O deberían saber qué necesitan sus clientes y cómo usan el producto sus clientes?

La regla general es que cuando se trata de Ingeniería, los Gerentes de Producto se enfocan en QUÉ se debe hacer, Ingeniería se enfoca en CÓMO se debe implementar. Saber cómo “escribir un fragmento de código” no te va a ayudar mucho.

No necesariamente La percepción de que los gerentes de productos deben codificar refleja el hecho de que la disciplina de la administración de productos está en pañales: la verdadera naturaleza del oficio apenas comienza a ser reconocida. Requerir que los gerentes de producto codifiquen podría ser un truco razonable para identificar a las personas que tienen un aspecto del conjunto de habilidades del gerente de producto, pero un fondo de codificación no es estrictamente necesario e incluso puede ser una responsabilidad en algunos casos (como explicaré más adelante) .

Si bien un gerente de producto no necesita codificar, debe poder profundizar en el funcionamiento de cualquier sistema, ya sea una plataforma en la que se construye su producto, el marco de cómo se mide el éxito de su producto, el mercado en el que el producto existe, el modelo mental de sus usuarios o la política de su organización. Lo que se requiere no es un fondo de codificación, sino una mente supremamente lógica, rigurosa, filosófica y pragmática. Para obtener más descripciones de lo que se requiere, consulte ¿Cómo puedo aprender a ser un Product Manager efectivo?

Si bien hay muchos gerentes de productos talentosos que codifican, también he visto que un fondo de codificación es una responsabilidad por este tipo de razones:

1. Se centran demasiado en la implementación y no lo suficiente en su verdadero deber, que es poseer la visión del producto y la estrategia detrás de cada iteración.
2. Debido a que visceralmente sienten el dolor de algunos tipos de cambios en el código, pueden estar sesgados en contra de ciertas instrucciones del producto.
3. Chocan con el líder técnico que siente que sus deberes están siendo pisoteados.

Por supuesto, tales trampas se pueden evitar. Pero el punto clave es que la gestión de productos es su propio oficio y hay muchas vías para llegar allí, siendo la codificación popular.

La respuesta es no , con algunas excepciones.

Información general: he sido primer ministro durante más de 5 años, tanto en una gran empresa como en una nueva empresa. Tengo un título de CS adecuado y puedo codificar.

Durante mi carrera, he trabajado con muchos PM exitosos que no pueden codificar. Estudiaron Historia, Inglés, Lingüística, Música … etc. que no tienen nada que ver con la codificación. Aunque algunos de ellos eventualmente adquirieron algunas habilidades de codificación por curiosidad, eso no tiene nada que ver con su habilidad y éxito de PM.

De hecho, realmente aprecio los diversos antecedentes que tienen y las perspectivas que aportan al equipo.

Entonces, la excepción es cuando está trabajando en un producto centrado en el desarrollador. Digamos que si fue un PM en AWS o Visual Studio, entonces no poder codificar es equivalente a no entender a los usuarios, lo cual es una receta para el fracaso.

Esta pregunta se ha convertido en un cliché en los últimos tiempos, y sigo escuchando esto entre los aspirantes a Gerente de Producto no Ingeniero. Entonces, aquí está mi respuesta corta y simple:

• En el lado de la ingeniería, debe ser capaz de

• Comprender algoritmos simples (búsqueda, clasificación, manipulación de cadenas)
• Apreciar lo que hace que el diseño del sistema sea escalable y confiable
• Comprenda cómo funciona Internet: modelo cliente / servidor, API, latencia, etc.
• Tenga en cuenta las compensaciones de una arquitectura sobre la otra y cómo eso impacta sus productos y características
• tenga en cuenta los cuellos de botella típicos en su característica futura: acoplamiento estrecho, abstracción, diseño de base de datos
• sentir cómo piensa un ingeniero y qué le importa

En resumen, si le va bien en los artículos anteriores, debería ser bastante bueno para liderar el Producto en la mayoría de las organizaciones de Internet / software / tecnología. Piénselo de esta manera: ¿necesita ser un chef para administrar un restaurante? No, no lo hace, pero será un terrible propietario de un restaurante si no comprende lo que implica cocinar, cómo funciona el sistema y qué necesita exactamente un chef.

Si puede codificar, solo lo ayudará, pero si no puede, no es un obstáculo. Espero que esto sea útil.

Depende de: a) la definición exacta del rol de un PM, b) la cultura de ingeniería de la organización.

Para más desarrolladores que enfrentan roles de PM, el conocimiento de la codificación es casi siempre una gran ventaja. Le permite traducir los requisitos de campo a un idioma con el que se sientan cómodos, hacerles preguntas difíciles y comprender las compensaciones de ingeniería. Una excepción sería si tiene una contraparte de ingeniería que entienda bien los negocios.

Si la cultura de ingeniería de la organización se basa en la excelencia tecnológica, puede estar razonablemente seguro de que las preguntas tecnológicas difíciles se hacen dentro del grupo de ingeniería. En cuyo caso, uno podría tener éxito con solo un dominio profundo / conocimiento del mercado.

No, no necesita saber cómo codificar.

Sin embargo, incluso si no tiene una formación técnica, todavía hay muchas cosas que puede hacer para “ser técnico” y generar respeto con sus equipos.

Tomar medidas para desarrollar una base técnica.

Como gerente de producto, debe aspirar a poder:

• Ballpark estima cuánto tiempo tomaría completar una función (o tener suficiente conocimiento técnico para tener una conversación adecuada con una parte interesada directa, es decir, un ingeniero o gerente de ingeniería sobre cuánto tiempo tomará)
• Rastree los flujos de productos para comprender los problemas fundamentales del usuario
• Comprender la lógica detrás de las posibles soluciones para cualquier problema técnico que surja
• Planifique las áreas de su producto que se verán afectadas por las soluciones técnicas propuestas (junto con los desafíos asociados)

Estimación de la línea de tiempo: cada vez que un PM no técnico nuevo en la industria pregunta qué deberían hacer con respecto a la estimación de la línea de tiempo, siempre menciono que gran parte se reduce al reconocimiento de patrones a lo largo del tiempo. A medida que trabaje más tiempo con sus equipos de desarrollo / diseño, comenzará a comprender patrones como: quién trabaja rápidamente, quién no, quién tiende a sobreestimar sus propias líneas de tiempo, quién escribe el código rápidamente pero necesita revisiones de código adicionales debido a errores frecuentes , etc.

Al comienzo de cualquier proyecto, siempre debe esforzarse por comunicarse con las partes interesadas directas involucradas para comprender lo que están pensando. No interpretes al héroe que intenta estimar a todo el equipo; Es posible que no tenga el contexto completo sobre las limitaciones técnicas / desafíos que pueden surgir durante el proceso de desarrollo. Al final del proyecto, debe intentar reflexionar sobre la precisión de sus estimaciones. Si estaban completamente fuera de lugar, intente comprender lo que sucedió e incorpore esos datos en sus estimaciones en el futuro.

Lógica: comprender la lógica detrás de los problemas técnicos no significa que deba diagnosticar e implementar las soluciones exactas usted mismo. El primer paso que puede tomar es comprender / mapear todos los flujos de usuarios en su producto para que pueda rastrear más fácilmente cualquier problema del usuario a los problemas subyacentes. El mapeo de estos flujos crea un “laberinto mental” en su cabeza para que también pueda identificar más fácilmente los componentes de su producto que podrían verse afectados cada vez que se propongan nuevas características / soluciones.

Recuerde, como primer ministro, tendrá que ayudar a clasificar muchos posibles problemas. Lo último que quieres hacer es convertirte en un intermediario inútil que solo toma errores y los asigna a un ingeniero sin poder diagnosticar lo que podría estar sucediendo. Esa es una forma garantizada de perder el respeto de sus equipos de ingeniería.

Desea no decir nunca “No lo sé”, sino “Bien, no sabemos la solución exacta aquí, pero sabemos que ocurrió un problema y lógicamente, podemos rastrear esto a B o C”. . ”Desarrollar la lógica para identificar problemas raíz y posibles soluciones ahorrará tiempo a sus equipos y ganará su respeto.

Desarrolle curiosidad técnica: esta última pieza es posiblemente la parte más importante del desarrollo de una base técnica porque requiere un impulso inherente para aprender más sobre temas técnicos. Hablamos de esto en nuestro artículo sobre los 5 pasos principales que debe seguir cuando se convierta en un nuevo gerente de producto, pero cada vez que tenga la oportunidad (sin ser disruptivo), debe intentar sentarse con un ingeniero (o algunos) para comprender la pila de tecnología de su producto.

En el futuro con cualquier proyecto en curso, debe tratar de reservar un tiempo para hablar con sus ingenieros sobre los detalles de implementación para que tenga el contexto sobre las compensaciones que puedan surgir o los casos límite en los que podría no haber pensado.

Una cosa que siempre recomiendo a todos los PM no técnicos y técnicos para recoger es un conocimiento práctico de SQL. Averigüe dónde se almacenan los datos de su producto y tenga una idea de cómo están estructurados los registros del producto. De esta manera, si necesita extraer algunos puntos de datos para ejecutar sus propios análisis, simplemente puede usar comandos SQL para consultar y extraer los datos usted mismo en lugar de perder el tiempo de su ingeniero.

Otra cosa que puede hacer es comenzar a familiarizarse con los bits de la base del código. Por ejemplo, si está verificando la identificación de una prueba dividida que está ejecutando su equipo, simplemente puede acceder a la base de código usted mismo y buscar la prueba. Cualquier cosa que pueda hacer usted mismo para ahorrar tiempo a su equipo de ingeniería y dejar que se concentren en su trabajo definitivamente será apreciada.

La conclusión más importante es que, como primer ministro, su trabajo consiste en encontrar el mejor producto final posible para su usuario al llegar realmente a las necesidades básicas de sus usuarios. Ya sea que eso requiera que esté un poco más involucrado en el proceso de desarrollo o más involucrado en obtener una visión adicional del comportamiento del cliente, el producto debe ser entregado y debe ser sorprendente para sus usuarios.

Fuente: ¿Los gerentes de producto necesitan una formación técnica?

Absolutamente sí.

Como pocos ya han dicho, eso no significa que un PM deba escribir un buen código o contribuir a la base del código de su producto.

Déjame intentar poner las cosas en perspectiva. ¿Debe un gerente de producto de Ford Mustang saber conducir? ¿O un gerente de producto en GlaxoSmithKline tiene experiencia en desarrollo farmacéutico?

PM necesita tener una gran perspicacia técnica para comprender y apreciar el funcionamiento interno de su producto, lo que a su vez ayuda a identificar y evaluar mejor los proyectos y hacer compensaciones. No saber cómo codificar, es decir, no poder entender cómo funcionan las cosas, significaría que el funcionamiento interno de su producto sería una caja negra para usted, y no estoy seguro de que pueda convencerme de que podría dirigir el desarrollo y mantener al equipo orientado y motivado si no puede apreciar realmente su contribución.

Eso puede ayudar.

Su trabajo como PM es tener los conocimientos y habilidades que el equipo de desarrollo de productos necesita para entregar productos exitosos. La codificación podría ser parte de ese conjunto de conocimientos y habilidades.

• Si el equipo de desarrollo de productos es un ingeniero corto, he visto a los principales PMs en Google asumir un papel de codificación.
• Si el equipo de desarrollo de productos necesita comprender cómo funciona una API, he visto a los mejores PM escribir código de prueba de API.
• Si el equipo de desarrollo de productos necesita detallar un algoritmo complicado, he visto a los principales PM especificar esos algoritmos.

El envío de un producto exitoso es el nombre del juego para los mejores PM del 1%. Anotarán puntos, repartirán asistencias, rebotarán la pelota y / o animarán, si es necesario.

Crédito de la foto: Kip-koech

No

En primer lugar, hay gerentes de producto en todos los campos, no solo software. Entonces, la mayoría de los gerentes de producto no saben programar, y de hecho no trabajan en productos de software.

Pero, incluso en el campo del software, la capacidad de programar definitivamente no es un requisito. Es necesario tener empatía por los ingenieros que están haciendo la programación y una buena comprensión de las tecnologías aplicables a sus productos: sus capacidades y límites. Una forma de conseguir eso es haber programado en tu pasado. Pero, no es la única manera. Los grandes gerentes de productos tienen altos niveles de curiosidad, están aprendiendo constantemente y se involucran con cada disciplina que tocan en un nivel lo suficientemente profundo como para ser efectivos: marketing, ingeniería, diseño, ventas, operaciones, fabricación, atención al cliente, etc.

También podría preguntar si un gerente de producto necesita saber cómo vender. O saber cómo comercializar. O saber fabricar. O saber cómo x … Los gerentes de producto necesitan comprender todas estas cosas, pero no tienen que saber cómo hacerlas todas.

No. No duele, pero hay tantas dimensiones en las que necesitas sobresalir como gerente de producto, que está bien en la mayoría de las empresas si no eres un programador también. Tienen gente para eso.

Dicho esto, creo que es importante que un PM entienda cómo funciona su producto en un nivel abstracto. Trate de no dejarse impresionar por mi ilustración aquí (literalmente en el reverso de un sobre):

Esa es la ilustración de un pobre hombre de (1) la interfaz de usuario, (2) la capa de acceso a datos / API y (3) capa de datos. Debe comprender lo que sucede en cada capa de la pila de su producto: dónde viven los diferentes datos, cómo se manipula y se accede a ellos, dónde hay cuellos de botella de rendimiento y deudas tecnológicas, etc.

Tenga en cuenta que estoy hablando de cómo funciona el sistema todavía en un nivel relativamente alto. No necesita saber cómo construirlo o depurarlo, pero será mejor en su trabajo y probablemente tendrá una relación de trabajo más fluida con sus ingenieros cuando comprenda cómo encaja todo su trabajo.

Lo más importante para un gerente de producto es asegurarse de que la compañía esté construyendo el producto correcto. Eso significa validar los problemas que debe resolver para sus clientes objetivo (suponiendo que haya descubierto quiénes son).

También: ¿nuevo gerente de producto? Aquí le mostramos cómo puede agregar valor

Keval Desai, socio de InterWest y ex Director de Producto de Google, dice que un gerente de producto debe saber cómo “hablar el idioma de su audiencia”, que a menudo es código cuando la audiencia está compuesta por ingenieros.

“Si usted es un gerente de producto, su audiencia son sus ingenieros, sus clientes y, a veces, la alta gerencia de la empresa. Creo que ser multilingüe, lo que significa poder hablar código, hablar PowerPoint y ser capaz de hablar beneficios: esos son francamente los idiomas que un gerente de producto necesita saber “.

Vea la conversación completa en nuestra entrevista con Keval como parte de la serie web Confesiones de un gerente de producto.

Si está en la industria del software, cuanto más conocimiento técnico tenga, mejor sería. No es necesario que sea un desarrollador, pero poder ejecutar consultas SQL básicas para obtener los datos que necesita que lo ayudarán a tomar decisiones a nivel de producto, y poder entablar conversaciones técnicas con su equipo de desarrollo solo puede ayudar.

Pero lo más importante, lo que necesita son las siguientes habilidades:

1. Capacidad para empatizar con el cliente, descubrir sus necesidades no satisfechas y luego explicar estas necesidades a su equipo de desarrollo para que puedan resolverlas
2. Ojo agudo para la experiencia del usuario y el diseño de la interfaz de usuario.
3. Capacidad para hablar con diferentes partes interesadas internas (lea el trabajo con personas con diferentes egos, perspectivas, ideas)

Si puede hacerlo bien y desea aprender habilidades técnicas básicas, debería poder tener una excelente carrera en la gestión de productos.

No, desde la perspectiva de un primer ministro que no sabe codificar.

A menudo me pregunto qué haría si supiera codificar. Probablemente perdería el tiempo preocupándome sobre qué tipo de código estaba escribiendo mi equipo de desarrollo en lugar de ser un primer ministro. Hay revisiones internas de código por personas que realmente hacen código (otros desarrolladores). Confío en que revisen su propio trabajo correctamente.

Si está haciendo el trabajo de MP correctamente, debe tener una larga lista de cosas que hacer que son más importantes que cualquier cosa para la que pueda usar la experiencia de codificación.

La única excepción es comprender los sistemas y la arquitectura del software. Familiarícese con eso para que pueda tomar decisiones informadas sobre la priorización de las características de front-end sobre la infraestructura de back-end.

No permita que las personas que piensan que la codificación sea un requisito para la gestión del producto se interpongan en su camino para convertirse en un gerente de producto. Y no lo uses como excusa para rendirte.