El proceso te protege de la mala ingeniería

Una reflexión sobre como un proceso estructurado de desarrollo de producto puede proteger tu roadmap frente a influencias externas.

Siempre me he considerado un PM muy libre. Quizás porque no tuve una carrera convencional, sino que aprendí el oficio levantando dos startups como fundador.

Recuerdo lanzar la primera recién salido de la carrera de ingeniería informática, con la cabeza muy estructurada, el típico plan de negocio debajo del brazo, y peleando con mi socio que se reía de mí cuando le sentaba a hablar sobre cómo íbamos a crecer al tercer año.

Mi socio, mucho más inteligente que yo, me decía, ¿pero cómo vamos a saber lo que vamos a facturar al tercer año? Lo mismo lanzamos y facturamos cero, o 10x. No lo podemos saber.

Al final lanzamos y terminamos facturando 10x. Tiré mi plan de negocio a la basura, y me puse a gestionar el día a día de una empresa, algo para lo que desde luego no estaba preparado.

Esa experiencia y muchas otras a lo largo de más de 20 años de carrera me han hecho ver “el proceso” con recelo. Y es que rara vez algo ha pasado porque teníamos un proceso bien definido buscando un resultado concreto. Generalmente, casi todos los éxitos que he observado se han dado por casualidades que eran casi siempre imposibles de pronosticar.

Bajo este prisma, podríamos decir que lo importante bajo mi punto de vista es estar preparado para apostar fuerte cuando detectas una de estas oportunidades. Y el proceso, visto como la construcción de roadmaps donde fantaseamos con la ilusión de que sabemos lo que queremos construir el próximo año, me resulta incómodo. ¿Para qué invertir tiempo y esfuerzo en algo que sé que no va a tener la menor validez en cuanto lo presente? De hecho, lo peor que podría pasar es que por haber hecho un roadmap, dejara pasar las verdaderas oportunidades cuando se presentan.

Podría decirse que soy bastante freestyle. Mis equipos no esperan de mí grandiosos documentos de especificaciones, sino que trabajan casi con one-pagers que definen muy claramente el objetivo que perseguimos con cada iniciativa. Y quizás por experiencia, quizás por carácter, nunca he tenido problemas con esta forma de trabajar. De hecho, podría decir que he tenido bastante éxito allá donde he aplicado la fórmula.

Ahora bien, hace unos días vi un tweet de Aakash Gupta, un prolífico creador de contenido de producto. En este, enlazaba una conversación de Reddit donde un PM narraba la historia de cómo la llegada de un nuevo Engineering Manager le había hecho dejar la empresa, y perder gran parte del equity generado durante años.

Os la dejo traducida a continuación, porque de verdad me parece muy interesante.

Un nuevo EM se unió a la startup que yo había levantado desde cero (en los siete años que estuve ahí, pasé de ser el primer PM a Director de producto, la empresa pasó de ~500k de ARR a más de 30M, y el headcount de 5 a 60). Era un tipo bastante agradable, pero constantemente se extralimitaba: hablaba con clientes, desarrollaba cosas sin mi participación, me excluía de reuniones, incluso prohibía a personas no ingenieras asistir al daily standup, se quejaba de nuestro roadmap, etc.

Con el tiempo, convenció al CTO/fundador (mi jefe) de que la empresa necesitaba estar más liderada por ingeniería (mi trasfondo es de analista). Poco a poco, fui perdiendo influencia dentro de la organización mientras él ganaba cada vez más. Cualquier intento de “arreglar” el problema se percibía como que yo era territorial o resistente al cambio.

Los únicos esfuerzos que impulsaba eran de escalabilidad o infraestructura. Bajo su liderazgo, nos atascábamos durante meses migrando de un stack tecnológico a otro, limpiando código o construyendo algún nuevo pipeline. Era agotador. La evidencia que usaba para justificarlo eran caídas ocasionales del servicio (unas pocas al año), rollbacks puntuales o algún edge case aislado. Todos ellos problemas importantes en una organización enterprise, pero irrelevantes para una startup creciendo un 200% al año desde mi punto de vista.

En retrospectiva, lo gestioné mal. Finalmente me apartaron y él asumió el rol de producto. Un año después, tras una fuerte caída de ingresos, fue despedido. La startup en la que pasé mis 20 construyendo equity (una participación que llegó a valer más de 10M$), que una vez tuvo una oferta formal de adquisición de 150M$, ahora factura menos de 10M$ de ARR y probablemente tenga una valoración de 10–20M$, con un headcount de un tercio del que tenía cuando me fui.

Mi consejo después de haber pasado por esa experiencia:

Puedes adaptarte creando procesos de producto más formales. Si documentas todo, creas mejores artefactos de producto, mantienes un roadmap transparente y haces una planificación trimestral más precisa, habrá poco margen para que tu EM ejerza influencia. Cualquier fallo en la entrega será evidente para el liderazgo y será menos probable que parezca tu responsabilidad.

Yo no hice esas cosas. Era un PM muy libre, que solo se preocupaba por los resultados y el espíritu de equipo. Pasaba tiempo con mis ingenieros, siempre buscaba quick wins y limitaba mis artefactos a lo mínimo necesario para mantener a los no técnicos fuera de nuestro camino.

Luego me di cuenta de que los procesos no solo te protegen de stakeholders no técnicos molestos (ejecutivos, ventas, marketing), sino que también pueden aislarte de la mala ingeniería.

Me quedé pensando mucho en esa última frase, porque sin duda es algo que he visto: Product Managers arrollados por equipos de ingeniería que, quizás por desconfianza, imponían su propio roadmap por encima del del responsable de producto.

Y es natural también. Si un equipo de ingeniería, con sus propios problemas y responsabilidades, y en muchos casos con más conocimiento del negocio que el PM que entra, percibe inseguridad, no tardará en encontrar cosas que hacer mejores que las que le propone este.

Este tipo de PMs suelen estar vendidísimos y duran bien poco. Pero quizás el consejo del usuario de Reddit pueda salvarlos. Si se trabajan bien las iniciativas, las alinean con los objetivos de la empresa, y consensúan un roadmap con Leadership, ingeniería tiene mucho menos margen de maniobra para desviarse del camino.

Si se equivoca o no cumple los objetivos, el PM morirá igual (nadie dijo que esto fuera fácil), pero al menos morirá habiendo podido probar sus ideas.