Mi camino desde la ingeniería de software hasta la gestión de productos

Y algunos consejos sobre cómo hacerlo tú mismo.

A menudo me preguntan cómo realizar el cambio a la gestión de productos. Por ingenieros de software, gerentes de proyectos, gerentes de marketing de productos, científicos de datos, personas en QA… Me pregunto si saben lo que están pidiendo.

Así es como me sucedió.

Amor al primer programa

Mi padre le compró una computadora a la familia cuando yo tenía 12 años. Venía con un manual de programación BÁSICO y me sumergí en el primer programa de todos: ¡Hola mundo! Luego pasó a copiar el código de "¡Lo siento!" juego del manual, encontrando y arreglando un montón de errores.

Cuando era niño, siempre me encantaba hacer rompecabezas, y programar era como resolver rompecabezas para que la computadora hiciera lo que yo quería. Al instante me enganché y decidí que me especializaría en informática. Sí, a las 12.

Miro hacia atrás y me maravillo un poco. Tan decisivo ... Tan genial escuchar mi intuición ... ¿Por qué no puedo hacer eso todo el tiempo? Solo he experimentado ese tipo de claridad algunas veces en mi vida. Otro es el cambio a PM. Pero me adelanto.

Ronda de manzana 1

Después de la universidad, conseguí el trabajo de mis sueños como ingeniero de software en Apple, en los días de John Sculley. Trabajé en el enrutador de Internet de Apple con Alan Oppenheimer, quien literalmente escribió el libro sobre la pila de redes de Apple.

Yo era prácticamente la única ingeniera del equipo. El tipo que estaba configurando mi teléfono me preguntó si estaba "apoyando" a Alan. Me tomó unos minutos darme cuenta de que pensaba que yo era el nuevo administrador de Alan. Pero de nuevo, estoy divagando ...

Trabajé en Apple durante 8.5 años en la ronda 1 (guardaremos la ronda 2 para otro momento). Tenía 4 directores ejecutivos. Después de John Sculley, estaban Michael Spindler, Gil Amelio y luego el regreso de Steve Jobs.

Cuando Steve regresó, despidió a una gran parte de la fuerza laboral y canceló muchos proyectos, incluido el que estaba trabajando. Sin embargo, no logré obtener un paquete de indemnización, que en ese momento todos considerábamos la mejor opción (¿qué sabíamos?).

Continué en Apple por algunos años más, entregando la primera versión del Apple Keychain y la primera suite de API de Internet (Subwoofer). Se lanzó el iMac. Hablé en WWDC 3 veces. Tuve éxito con la mayoría de las definiciones, incluida la mía.

Gestión de calidad total (TQM)

Apple no tenía gestión de productos en ese entonces (o ahora, para el caso). Había un equipo de marketing de productos con muy poco personal que, hipotéticamente, escribió “Documentos de requisitos de mercado” (MRD). Pero si alguna vez vi uno, fue hecho después de haber escrito las especificaciones de ingeniería y agregado el valor ~ 0.

Afortunadamente, nací como un pensador de los primeros principios. Simon Sinek probablemente todavía estaba en la escuela primaria, pero yo estaba empezando con el por qué de todos modos. Mi necesidad de averiguar qué hacer a continuación y no tener a nadie que me guíe, me lleva a algo llamado TQM.

Había un consultor de TQM flotando por Apple trabajando con otros equipos del que me enteré. Y le pedí que viniera a enseñarlo al equipo de enrutamiento.

Como me enseñaron, TQM era básicamente pensamiento de diseño, pero únicamente se enfocaba en la tecnología. Y para ser honesto, hay elementos que van más allá del pensamiento de diseño (lo siento, IDEO). En particular, el enfoque en que todo el equipo desarrolle empatía por el cliente, en lugar de solo por los diseñadores.

Así que me puse en marcha haciendo visitas a los clientes y obteniendo información sobre el producto a través de la empatía. Allá por 1995. Esto me llevó a mi primera idea de producto: el Apple / IP Gateway. Fue un gran éxito hasta que IP se hizo cargo de la mayoría de las redes existentes y AppleTalk quedó en desuso.

Y no habría sido posible sin la empatía del cliente. Sobre todo porque se trataba de un producto B2B. Nuestros clientes no lo “pidieron”. Acabo de ver los problemas que tenían de primera mano y que hacer un túnel IP a través de AppleTalk ayudaría.

Individuo directamente responsable (DRI)

Después de mi tiempo en enrutamiento, pasé al equipo de Cyberdog que estaba desarrollando un conjunto de aplicaciones de Internet. FTP, Telnet, Gopher, SMTP y HTML ... Supongo que muchos de ustedes necesitan buscar algunos de ellos. Hicimos todo esto con un equipo de aproximadamente 25 personas y yo era uno de los gerentes de ingeniería.

Después de nuestro primer lanzamiento, fui ungido "DRI" de Cyberdog. Este concepto es exclusivo de Apple y es por eso que todavía no hay una gestión de productos de la que hablar. El DRI suele ser un gerente de ingeniería e incluye tanto la propiedad del producto como la ejecución del equipo de ingeniería que crea el producto.

Es un gran concierto si el equipo es razonablemente pequeño. Me encantó. Excepto por el pequeño detalle de que todavía tenía que escribir código.

Me gustaba escribir código bastante bien, no me malinterpretes. Pero requería que estuviera completamente concentrado, lo que no siempre es posible en un entorno de ritmo rápido. Y preferí mucho el resto de mi trabajo.

A veces me pongo bastante irritable. Recuerdo la sensación cuando mi probador principal llegó a mi puerta cuando estaba tratando de descubrir un error súper difícil. Me tomaría toda mi energía no gritar “déjame solo, ¡estoy trabajando!”. En retrospectiva, ¿se trataba de datos realmente buenos?

Considerándolo todo, era un codificador decente. Es mejor iterar en el código de otra persona que comenzar desde cero. Pero fui un gran DRI. Me encantaba hacer duras llamadas de priorización. Me encantaba la investigación de usuarios. Me encantó hacer avanzar al equipo, superar la ambigüedad. Incluso me encantaba escribir especificaciones.

Gestión de programas de Microsoft

Como DRI de Subwoofer (la primera suite de API de Internet), fui a Microsoft un día para ver si queríamos compartir código con su equipo de Mac Internet Explorer.

Me senté en una de sus salas de conferencias y entra un tipo que se presenta como el director del programa. Estoy pensando “uh ... ¿puedo hablar con alguien técnico, por favor? ¿Dónde está el gerente de desarrollo? "

Pero resultó que era técnico y entendía el negocio. Interesante, pensé ... ¿qué es exactamente este papel?

Nota al margen para aquellos que no han trabajado en Microsoft. La gestión de programas es la gestión de productos. La disciplina comenzó allí cuando otras empresas de tecnología tenían el marketing de productos y la gestión de productos como una sola persona. Microsoft fue el primero en dividirlos. El primero en tener a alguien completamente enfocado en lo que debemos construir, por qué y un poco de cómo. Y lo llaman "gestión de programas".

En 2001, recibí una llamada de un amigo que solía estar en Apple conmigo y cuya compañía (WebTV) había sido comprada por Microsoft. "Sari", dijo, "necesitamos administradores de programas aquí y pensé en ti".

Él sabía, antes que yo, que yo era un PM. A pesar de que ambos habíamos pasado la mayor parte de nuestras carreras en Apple donde no existían.

Me uní al equipo (dejando atrás un montón de acciones de Apple, ¡Ups!). Mi amigo se fue a Google poco después. Pero encontré mi vocación desde una perspectiva disciplinaria y nunca miré hacia atrás.

Pensamientos finales y algunos consejos

Mi historia es la de alguien que es un PM de corazón y encontró su camino de manera orgánica. Así que mi primera pregunta para ti es exactamente esa:

¿Eres un PM de corazón?

Mire detenidamente por qué quiere ser PM. Es difícil entender cuál es el papel si aún no lo está haciendo, entonces, ¿cómo lo sabe? ¿Por qué te atrae? Lea algunos de mis otros blogs. ¿Estás seguro?

¿Ya estás haciendo el trabajo? ¿Sin el título?

Si actualmente está en un puesto de ingeniería, proyecto, programa o diseño y no tiene un PM, ¿quién está haciendo el trabajo del PM? El trabajo (definir el producto, impulsar las cosas, ser el catalizador para que se tomen decisiones difíciles) tiene que hacerse. Por alguien.

Si es usted, y es la parte favorita de su trabajo, entonces es una buena señal de que es el puesto adecuado para usted. También es la forma de presentarse en una entrevista.

Pruébelo donde esté.

Si tiene un PM, pregúntele si puede ayudar de alguna manera. La mayoría de los PM van a aprovechar la oportunidad porque están abrumados por el trabajo. Sí, tendrás que hacerlo además de tu trabajo diario. ¿Disculpa? ‍♀️.

Hacer el cambio en su organización actual es lo que recomiendo, si es posible. Ya conoce el producto y la tecnología y eso es de gran ayuda.

Hágale saber a su líder de PM que está interesado. Descubra lo que buscan. Pida ideas sobre cómo puede practicar las habilidades necesarias o demuestre que las tiene.

Tomar una clase.

Obtenga algo de entrenamiento. Hay un montón de clases de gestión de productos que puede tomar. No voy a recomendar ninguno en particular. Pregunta por ahí. Lo principal en lo que ayudará una clase es exponerlo a cuál es el papel y darle algo de vocabulario. Y demuestre a los gerentes de contratación que se preocupa lo suficiente como para dedicar tiempo y energía. También ampliará su red.

Hablando de redes… Lo que no creo que ayude tanto es el “trabajo en red”. Lo que quiero decir con eso es asistir a eventos de networking, reuniones o conferencias. Las relaciones que comience allí pueden ayudarlo en un par de años si las nutre. Pero no ayudarán pronto.

Utilice su red.

Creo que su red existente puede ayudar. Así fue como obtuve mi primer papel de PM sin ni siquiera intentarlo. Alguien que piense en ti como una gran opción es la mejor manera de conseguir cualquier trabajo, incluido el PM. Por lo tanto, infórmele a su red existente que desea realizar el cambio. Y no, ¿no conozco un atajo para construir una buena red ?.

Espero sinceramente que encuentre la manera de ser un PM y lo ame tanto como a mí. ¡Buena suerte!