¿Cómo es convertirse en gerente de producto con experiencia en ingeniería de software?

Era ingeniero de software antes de convertirme en gerente de producto. Al leer los detalles de la pregunta, creo que necesita profundizar en sus motivos para hacer la transición, porque no es obvio para mí que esté considerando pasar a la gestión de productos por las razones correctas.

Básicamente, hice el cambio a la gestión de productos porque me di cuenta de que me gustaba trabajar con clientes (y clientes potenciales) más de lo que me gustaba crear código en una habitación oscura. También disfruté el desafío y la realización de la ingeniería de software, pero también me aburrí con la rueda de la implementación del hámster. Aprendí a codificar por primera vez cuando tenía 11 años, publiqué mi propio software, escribí una columna mensual para una revista de informática y completé una maestría en ingeniería de software. ¡Y luego descubrí que no era realmente lo que más me gustaba hacer!

Para ser gerente de producto, debe gustar y disfrutar estar con clientes y, sí, con personal de ventas y marketing. También debe ser tolerante con la ambigüedad y ser analítico ayuda. Los mejores gerentes de productos son mucho más sólidos en síntesis que en análisis: son capaces de reunir todas las piezas en un todo coherente que satisfaga lo que el cliente realmente necesita al costo correcto en comparación con lo que dijeron que querían.

El trabajo de la gestión de productos es convertirse en un experto en usuarios y poder sintetizar la amplia variedad de requisitos y deseos de los clientes en algo que los clientes comprarán y que la ingeniería pueda ejecutar. Al cliente generalmente no le importa cómo funciona algo, solo que lo hace. Entonces, los buenos gerentes de producto construyen deliberadamente el conocimiento del cliente a expensas de saber cómo funciona todo en el código. De hecho, eso es algo bueno, como sospechabas. Deben evitarse los gerentes de producto que saben mucho sobre el código porque se están centrando en lo incorrecto y nunca lo sabrán tan bien como los ingenieros. Y, de hecho, debe evitarse cualquier gerente de producto que no pase> 50% de su tiempo con los clientes. Deben ser expertos en su producto (o área de producto) y en cómo satisface las necesidades del cliente, pero no en el código en sí.

En general, parece que se siente poco apreciado y agotado, lo que puede resolver si se muda a un grupo diferente o una compañía diferente en lugar de cambiar a una carrera profesional diferente. La ingeniería no tiene que ser como la describe. Tiene que gustarle que los clientes sean un buen gerente de producto; si no lo hace, no entre en la gestión de productos.

Comencé mi viaje como ingeniero pasando más tiempo con los clientes. Me ofrecía como voluntario para visitarlos con personal de ventas o de tecnología de campo (era un beneficio mutuo porque les encantaba contar con un experto en productos), trabajaba en escaladas de clientes y simulacros de incendio, y generalmente trataba de entender cómo pensaban porque me sentía muy desconectado de los usuarios sentados en la oficina (literalmente) oscura, casi silenciosa.

Así es como supe que me gustaba más la interacción con el cliente que la codificación. Y luego, cuando surgió la oportunidad adecuada para dar un paso hacia ser gerente de producto, una oferta de trabajo para mudarme a los EE. UU. Y ser un cruce entre un ingeniero de ventas y un arquitecto técnico, aproveché. Eso me llevó a mi primer título oficial de gestión de productos en Cisco Systems, donde había muchas personas ex-HP extremadamente experimentadas que me enseñaron todo lo que sabían sobre la gestión de productos (que era mucho).

El otro camino bien recorrido para los ingenieros es obtener un MBA para obtener habilidades comerciales y un título comercial, y luego unirse a una empresa como gerente de producto junior cuando se gradúen. Nunca obtuve un MBA por razones que son demasiado aburridas para entrar aquí, pero he contratado a muchos gerentes de producto que han tomado este camino.

Descargo de responsabilidad: no puedo responder exactamente su pregunta tal como me la pidieron, ya que me convertí en Gerente de Producto de un fondo de Servicio al Cliente en lugar de un fondo de ingeniería de software.

Para hacer las cosas más turbias, el término “gerente de producto” significa diferentes cosas en diferentes compañías.

Dicho esto, déjame darte mi definición y algunos antecedentes sobre cómo llegué allí y lo que sucedió desde entonces, y puedes tomarlo por lo que vale para ti.

Mi definición de gerente de producto: la persona encargada de determinar la dirección estratégica de un producto de software determinado, determina las prioridades para mejoras y correcciones de errores, establece (o al menos tiene información sobre) los precios de los productos propuestos y las mejoras para los productos existentes. Dependiendo del tamaño de la organización, el Gerente de Producto también puede realizar trabajos de diseño para productos y mejoras, asistir a reuniones con clientes y clientes potenciales para reunir requisitos para cambios o en un rol de soporte de ventas. El gerente de producto también debe tener la responsabilidad final de decir cuándo el software está listo para su lanzamiento al cliente o clientes.

Como dije, llegué allí desde una larga serie de roles que comenzaron en Servicio al Cliente. La empresa para la que trabajé se comercializaba para empresas con una función bastante específica, por lo que mi tiempo antes de convertirme en gerente de producto me enseñó los entresijos de las empresas que estábamos apoyando. También había demostrado un talento para comprender cómo hacer interfaces de usuario intuitivas para nuestros clientes, básicamente, al ser una molestia para las personas de desarrollo de software al decirles continuamente cómo podían hacer que lo que producían fuera más fácil de usar.

Irónicamente, la forma en que finalmente me encontré en la función de Gestión de productos es que me encargaron producir documentación para un nuevo sistema que la compañía estaba desarrollando. Encontré el sistema tan mal diseñado desde el punto de vista de los usuarios que escribí un memorando a toda la alta gerencia describiendo algunos de los muchos problemas que encontré y di una evaluación sin restricciones que, desde el punto de vista de la usabilidad, era terrible. Sinceramente, no sabía si me despedirían por el memorando, era tan duro.

Para mi sorpresa, no escuché nada, absolutamente nada hasta después de que el proyecto falló, casi llevándose a la compañía. Tuve una breve reunión con uno de los altos funcionarios de la compañía y dijo que estaba de acuerdo con lo que había dicho, pero que habían avanzado demasiado en el ciclo de desarrollo para hacer los cambios que sugerí.

Después del fracaso de ese proyecto, tuve algunas conversaciones con el resto del personal de desarrollo de software y tuvieron una idea para un proyecto mucho más pequeño que podría completarse en mucho menos tiempo y esfuerzo que el proyecto que había fallado. Tenía sentido para mí, así que lo escribí y envié un memorando a la gerencia sugiriéndolo. Para mi sorpresa, la propuesta fue aceptada y me pusieron a cargo de ella como Gerente de Producto.

Entonces, volviendo a tu pregunta. Las diferencias son: probablemente pasará más tiempo: en reuniones, viajes, documentando propuestas, justificando buenas ideas y explicando por qué las ideas realmente malas son malas sin molestar a nadie.

Descubrirá que la política tiene mucho más que ver con las decisiones corporativas de lo que creía posible.

Tendrá la oportunidad de evitar muchos problemas que probablemente vio como desarrollador.

Tus buenas y malas decisiones serán mucho más visibles de lo que son ahora.

Se sentirá frustrado por la forma en que las personas que exageran el tiempo necesario para hacer cambios o, por el contrario, ven que las ideas malas son aceptadas debido a la subestimación del esfuerzo requerido.

Su éxito dependerá de la entrega de trabajo de otras personas de lo que es ahora.

Serás uno de los que “hace que las cosas sucedan”. Hay mucha satisfacción en ser parte de un cambio positivo.

En primer lugar, debe tener la personalidad para ser propietario de un producto, que a menudo es gerente de producto, pero no siempre.

El propietario de un producto (desde la perspectiva de un gerente de producto) debe ser un comunicador claro, un jugador de equipo, un recolector de personas y alguien que crea que él / ella posee y es responsable del negocio.

Una vez que confirme que es quien es, entonces solo hay un paso lógico: dígale que quiere ser propietario de un producto y solicite oportunidades.

Cuando deja en claro cuál es su intención, y la gerencia siente que es un buen candidato, tendrá la oportunidad de actuar como propietario de un producto para proyectos específicos. Cuando se le brinde esa oportunidad, recuerde ser un comunicador claro, un jugador de equipo, un recolector de personas y recomiende decisiones prácticas como persona propietaria y responsable del negocio.

Cuando finalice el proyecto y haga un buen trabajo, tarde o temprano probablemente obtendrá un puesto en el que es el propietario del producto.

Provenir de un fondo de ingeniero de software es una gran ventaja como propietario del producto. Le permite establecer requisitos razonables y poder conversar con el equipo de I + D a un nivel más profundo. Simplemente no deje que esa sea su prioridad # 1 o punto de partida para tomar decisiones. Su prioridad # 1 / punto de partida es el negocio.

More Interesting

¿Cómo es un día típico para un desarrollador full-stack?

Sin un B.Tech. o BE grado, ¿cómo debo construir mi carrera en la industria del software?

Disfruto la emoción de resolver un problema en la programación de computadoras, pero encuentro que la búsqueda no es tan satisfactoria en un nivel profundo que beneficie positivamente a la sociedad. ¿Qué puedo hacer para experimentar proyectos que beneficien a la sociedad?

Además de conocer los idiomas de codificación, ¿qué habilidades se necesitan para obtener un trabajo como ingeniero / desarrollador de software en empresas de alto nivel como Google?

¿Necesitamos hacer un BCA para la ingeniería de software?

Soy un junior estudiando ingeniería de software. He tomado varias clases de programación, pero aún no he creado ninguna aplicación. ¿Cómo / por dónde empiezo?

Me despidieron después de 2 meses en mi primer trabajo de desarrollo de software. Tuve que aprender marcos en una semana y completar el proyecto. No recibí una buena capacitación, y los desarrolladores senior no tuvieron tiempo de capacitarme. Estoy perdido ¿Qué puedo hacer a continuación?

Cómo obtener una carrera en pruebas de software

¿Qué habilidades de ingeniería de software se pagan más?

¿Cuál es la diferencia entre programar como ingeniero de software y como científico de datos?

¿Se requieren ingenieros de software en todas las empresas?

Cómo cambiar mi carrera de ingeniero de sistemas a programador

Como desarrollador de software, ¿cuáles son los pros y los contras de su trabajo / carrera hasta ahora, y alguna vez desearía haber ingresado a la atención médica?

¿Cómo sería un día típico para un ingeniero de DevOps?

¿Cómo suena esto para una oferta de trabajo de ingeniería de software de Google o Facebook?