Por qué esto es trabajo tuyo, no solo de la fundadora o el VP de Producto

Descripción

Llegaste hasta aquí con el vocabulario completo: táctica, estrategia, y las cuatro capas que las ordenan. La objeción que probablemente ya se te cruzó, sobre todo después de la lección 5 —donde la estrategia quedó ubicada dos capas por encima de tu trabajo diario de ejecución—, es razonable: "esto suena a trabajo de founder, de VP de Producto, de alguien con ese título específico. Yo escribo código." Esta lección existe para desarmar esa objeción con argumentos concretos, no con un eslogan motivacional sobre "pensar como dueño".

La razón corta: eres, casi siempre, la persona con más contexto técnico sobre si una apuesta estratégica es siquiera viable de construir bien — y también eres quien toma, todos los días, decisiones de arquitectura y de build-vs-buy que o bien sirven la estrategia, o bien la desperdician en un problema técnicamente hermoso pero irrelevante. No se trata de que reemplaces a quien define la estrategia formal. Se trata de que la pregunta "¿esto que estoy a punto de construir sirve al juego que elegimos jugar?" deje de sentirse ajena a tu trabajo, porque tú eres, muchas veces, la única persona en la sala capaz de notar a tiempo cuando no es así.

Conexión con el módulo. Las lecciones 2 a 5 te dieron el vocabulario completo y la evidencia numérica (outcomeOf) de por qué la estrategia importa más que la ejecución brillante mal apuntada. Esta lección conecta ese vocabulario con tu rol específico como ingeniero, con un ejemplo ejecutado sobre decisiones de build-vs-buy y arquitectura — el tipo exacto de decisión que tomas tú, no la fundadora ni el VP de Producto.

Una analogía: el ingeniero de puentes y el trazado de la ruta

Un ingeniero civil no decide, normalmente, por dónde va a pasar una carretera nueva — esa decisión, sobre qué ciudades conectar y por qué, la toma alguien más arriba en la cadena, con información sobre tráfico, economía regional, política. Pero cuando el trazado propuesto llega a su escritorio, el ingeniero de puentes es la única persona capaz de decir: "ese río, en ese punto exacto, tiene una geología que hace que un puente ahí cueste diez veces más de lo presupuestado — o que sea, directamente, imposible con la tecnología disponible". Esa información no vive en la cabeza de quien trazó la ruta. Vive, exclusivamente, en la cabeza de quien entiende de puentes.

Si el ingeniero se calla —porque "a mí no me toca decidir la ruta, solo construir lo que me piden"—, el proyecto entero avanza kilómetros sobre un plan que, técnicamente, no se puede ejecutar como está pensado, y el error se descubre tarde, cuando ya es carísimo corregirlo. Si el ingeniero habla a tiempo, la ruta se ajusta con la mejor información disponible, y todos ganan: quien trazó la ruta original, y el proyecto completo. Ese es, con toda precisión, tu lugar frente a la estrategia de Mercado: no decides tú solo dónde va la carretera, pero eres quien puede ver, antes que nadie, si el puente que la estrategia necesita es viable, carísimo, o directamente imposible — y esa información, si te la guardas, no la tiene nadie más.

Ejemplo trabajado: el radar de una apuesta técnica propia

Antes de proponer una migración, una reescritura, o una decisión de build-vs-buy, un ingeniero puede pasarla por un radar de dos preguntas simples: ¿es un problema técnicamente interesante? y, la que casi nunca se hace, ¿sirve a la estrategia? Vamos a modelar ese radar con engineeringBetReport. Ten en cuenta algo importante: esto no es todavía el filtro formal sobre el backlog completo del producto —eso es strategicFilter, que vas a construir en el módulo 7—; esto es tu propio chequeo personal, antes de proponer una idea técnica propia.

// engineeringBetReport({ name, technicallyInteresting, servesStrategy }): el radar
// personal de un ingeniero frente a CUALQUIER idea tecnica propia -- migrar algo,
// reescribir algo, construir en vez de comprar. No es el filtro formal sobre el
// backlog completo del producto (eso es strategicFilter, modulo 7); es la pregunta
// que te haces ANTES de proponer nada.
function engineeringBetReport({ name, technicallyInteresting, servesStrategy }) {
  let verdict;
  if (servesStrategy && technicallyInteresting) verdict = 'construyelo -- sirve la estrategia y ademas es un buen problema';
  else if (servesStrategy && !technicallyInteresting) verdict = 'construyelo igual -- aburrido, pero sirve la estrategia';
  else if (!servesStrategy && technicallyInteresting) verdict = 'cuidado -- tentador, pero no sirve la estrategia; probablemente NO';
  else verdict = 'no lo construyas -- ni interesante ni estrategico';
  return name + ': ' + verdict;
}

const candidates = [
  { name: 'Migrar el buscador a un motor propio con ranking custom', technicallyInteresting: true, servesStrategy: false },
  { name: 'Sistema de reputacion y confianza para vendedores locales', technicallyInteresting: false, servesStrategy: true },
  { name: 'Pipeline de recomendaciones con embeddings + ANN', technicallyInteresting: true, servesStrategy: true },
];

candidates.forEach((c) => console.log(engineeringBetReport(c)));

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

Migrar el buscador a un motor propio con ranking custom: cuidado -- tentador, pero no sirve la estrategia; probablemente NO
Sistema de reputacion y confianza para vendedores locales: construyelo igual -- aburrido, pero sirve la estrategia
Pipeline de recomendaciones con embeddings + ANN: construyelo -- sirve la estrategia y ademas es un buen problema

Fíjate en el primer caso, porque es el más peligroso de los tres, y no por accidente. "Migrar el buscador a un motor propio con ranking custom" es, para casi cualquier ingeniero fuerte, un problema fascinante: hay algoritmos de por medio, hay benchmarks que optimizar, hay una sensación real de estar resolviendo algo difícil. Y sin embargo, si la estrategia de Mercado —la que viste tomar forma en la lección 3— es competir en curaduría humana y no en precisión de búsqueda, esta apuesta es exactamente Ana escalando Cerro Torre con una técnica brillante: un problema hermoso, mal apuntado. El radar marca "cuidado", no "nunca" — porque a veces la respuesta correcta sí es construirlo, si el análisis estratégico completo lo justifica —, pero la señal de alerta existe precisamente para forzar la pregunta antes de empezar a codear, no después.

El segundo caso es igual de importante en la dirección opuesta: "sistema de reputación y confianza para vendedores locales" no es, para la mayoría de los ingenieros, un problema tan seductor como un motor de búsqueda con ranking propio — es, en buena parte, formularios, validaciones, moderación, trabajo que se siente menos "interesante" en el sentido técnico tradicional. Pero sirve directamente a la estrategia de curaduría y confianza local. El radar dice "constrúyelo igual", y esa es, con frecuencia, la apuesta que un ingeniero enamorado de lo técnicamente vistoso pasa por alto — no porque sea mala, sino porque no reluce.

Build-vs-buy: la decisión donde tu criterio importa más que en ninguna otra

Hay un tipo específico de decisión donde tu contexto técnico es, literalmente, insustituible: build-vs-buy — ¿construimos esta pieza nosotros mismos, o compramos/integramos una solución existente? Esta decisión parece, a primera vista, puramente técnica (¿tenemos la capacidad? ¿cuánto cuesta el mantenimiento?), pero en realidad es una decisión que debería estar filtrada por la estrategia, y tú eres quien tiene la información de ambos lados para tomarla bien.

Considera el caso de un sistema de pagos para Mercado. Construirlo desde cero es un problema técnico serio: cumplimiento normativo, seguridad, reconciliación contable, disponibilidad. Un ingeniero podría, con toda razón, encontrarlo fascinante de construir. Pero si el pago no es parte de la estrategia diferenciadora de Mercado —si la elección estratégica de Mercado es competir en curaduría y confianza, no en infraestructura de pagos—, entonces construir un sistema de pagos propio es esfuerzo de ingeniería de primer nivel invertido en un problema donde ganar no mueve ninguna aguja estratégica: cualquier proveedor de pagos existente resuelve el problema igual de bien para el comprador, y el tiempo de ingeniería que se gasta reinventándolo es tiempo que no se gasta en el sistema de reputación de vendedores, que sí es diferenciador. La decisión correcta, casi siempre, es comprar (integrar un proveedor) en las piezas que no son parte del "cómo ganamos", y construir en las piezas que sí lo son. Esa distinción —¿esta pieza es parte de nuestra ventaja estratégica, o es una utilidad que cualquiera puede comprar igual de bien?— es exactamente la pregunta que vas a ver formalizada, a nivel de todo el backlog, en el módulo 7. Aquí, a nivel de una sola decisión técnica, ya la puedes aplicar tú, hoy, sin esperar a ese módulo.

Errores comunes

Esperar a que alguien "de producto" traiga la pregunta estratégica. Qué pasa: un ingeniero recibe la libertad de proponer una mejora técnica —una migración, una reescritura, una nueva pieza de infraestructura— y la propone basándose solo en criterio técnico, sin preguntar nunca si sirve a la estrategia, asumiendo que si fuera un problema esa pregunta ya se habría hecho por alguien más. Por qué pasa: cuestionar el encaje estratégico de tu propia propuesta se siente, a veces, como salirse del carril técnico asignado. Cómo detectarlo: puedes justificar una propuesta técnica con argumentos de arquitectura, performance o mantenibilidad, pero no puedes decir, con la misma soltura, a qué elección estratégica sirve. Cómo corregirlo: usa el radar de esta lección antes de proponer, no después. La pregunta "¿esto sirve a la estrategia?" es una pregunta técnica legítima sobre el retorno de tu propio esfuerzo, no una intromisión en el trabajo de otra persona.

Enamorarse de lo técnicamente bello e ignorar si importa estratégicamente. Qué pasa: una apuesta técnica avanza con impulso propio —genera entusiasmo en el equipo, atrae a los ingenieros más senior, se convierte en el proyecto "cool" del trimestre— sin que nadie frene a preguntar si mueve algo estratégico. Por qué pasa: los problemas técnicamente elegantes generan su propio momentum social: la gente quiere trabajar en ellos, hablar de ellos, presumirlos. Cómo detectarlo: es, literalmente, el primer caso ejecutado arriba — "cuidado, tentador, pero no sirve la estrategia". Si notas que la razón principal para construir algo es "sería un proyecto interesante" y no "esto sirve a la elección que hicimos de dónde jugar y cómo ganar", la alarma debería sonar. Cómo corregirlo: separa, de forma consciente, las dos preguntas del radar — ¿es interesante? y ¿sirve a la estrategia? — y exige que la segunda tenga una respuesta afirmativa antes de dejar que la primera decida.

Creer que "más features" es, por sí sola, una estrategia. Qué pasa: la respuesta por defecto a "¿cómo competimos mejor?" se convierte en "agreguemos más funcionalidad" — más opciones, más pantallas, más configuraciones —, sin que ninguna de esas adiciones esté conectada a una elección específica de dónde jugar y cómo ganar. Por qué pasa: construir cosas nuevas es lo que un equipo de ingeniería sabe hacer mejor, y "hagamos más" se siente como progreso tangible, mientras que "elijamos mejor qué NO hacer" no produce nada que se pueda demostrar en un demo. Cómo detectarlo: si la respuesta a "¿cuál es nuestra estrategia?" es una lista de features planeadas, sin ninguna frase que nombre a qué se renuncia, estás frente al mismo error de la lección 3 —confundir una lista de aspiraciones con una elección— aplicado esta vez a un roadmap técnico completo, no a una sola frase de offsite. Cómo corregirlo: recuerda el criterio de isRealStrategy — una estrategia real dice tanto qué construir como qué no construir, y por qué. "Más features" nunca es una respuesta completa; siempre hace falta la pregunta que la acompaña: ¿más features de qué tipo, para quién, sacrificando qué?

Ejercicios

Ejercicio 1 — Corre el radar sobre tu propia idea. Piensa en una mejora técnica que hayas propuesto o considerado recientemente —una migración, una refactorización, una nueva herramienta interna—. Complétala en el formato de engineeringBetReport: ¿era técnicamente interesante? ¿Servía a alguna elección estratégica explícita (o, si no había una estrategia explícita, a la dirección general del producto)? ¿Qué verdict te da el radar?

Ver solución

No hay una respuesta única —el ejercicio es personal—, pero el patrón útil de reflexión es este: si tu propuesta cae en el cuadrante "cuidado, tentador pero no sirve la estrategia", vale la pena preguntarte, con honestidad, cuánta de la energía que le dedicaste vino de que era un problema genuinamente estratégico contra cuánta vino de que era, simplemente, un problema divertido de resolver. Ninguna de las dos motivaciones es vergonzosa —a todos nos atraen los problemas elegantes—, pero solo una de ellas debería decidir si el esfuerzo se invierte antes que otras alternativas.

Ejercicio 2 — Build vs. buy con criterio. Mercado necesita un sistema de notificaciones push (avisar a un comprador cuando baja el precio de algo en su lista de deseados). Un ingeniero propone construirlo desde cero, porque "así controlamos completamente la infraestructura". Usando la distinción de build-vs-buy de esta lección, ¿qué preguntas le harías antes de aprobar esa decisión?

Ver solución

La pregunta central: ¿el sistema de notificaciones es, en sí mismo, parte de la ventaja estratégica de Mercado, o es una utilidad que cualquier proveedor externo resuelve igual de bien? Si la estrategia de Mercado —como la que se fue armando en las lecciones anteriores— gira en torno a curaduría y confianza local, un sistema de notificaciones push genérico (bajó el precio de X) no es, por sí mismo, diferenciador: un servicio externo especializado probablemente lo resuelve con la misma calidad, más rápido, y con menos mantenimiento futuro para el equipo de Mercado. Preguntas concretas a hacer: ¿existe ya un proveedor confiable que resuelva esto con buena integración? ¿El "control completo de la infraestructura" que ofrece construirlo propio sirve a alguna elección estratégica específica, o es una preferencia técnica general? ¿El tiempo de ingeniería que costaría construirlo desde cero podría invertirse, en cambio, en algo que sí es parte de la diferenciación de Mercado, como el sistema de reputación de vendedores? Si nadie puede contestar la primera pregunta con un "sí, es estratégico porque...", la decisión por defecto debería inclinarse hacia comprar o integrar, no construir.

Ejercicio 3 — El caso ambiguo. Un compañero argumenta: "la infraestructura de datos y analytics interna de Mercado no es parte de la estrategia de cara al cliente, así que según tu criterio deberíamos comprarla toda". ¿Estás de acuerdo? ¿Qué matiz le agregarías, considerando que en el módulo 6 de esta guía vas a ver que los datos pueden ser, en sí mismos, un moat?

Ver solución

No del todo — el argumento tiene una parte cierta y una parte que se le escapa. Es cierto que la infraestructura de datos y analytics no es, en sí misma, algo que el comprador ve o experimenta directamente — a diferencia del sistema de reputación de vendedores, no es "de cara al cliente" en el sentido de una pantalla o un flujo. Pero el matiz importante, que el módulo 6 va a desarrollar con moatScore, es que hay una diferencia enorme entre infraestructura genérica de analytics (dashboards, reportes estándar, algo que cualquier herramienta comercial resuelve igual de bien — ahí sí, comprar tiene sentido) y los datos propios que Mercado acumula sobre comportamiento de compra, patrones de descubrimiento y confianza entre comprador y vendedor local — esos datos, y lo que se construye encima de ellos (mejores recomendaciones, mejor detección de fraude, mejor curaduría automática), son exactamente el tipo de ventaja que un competidor no puede comprar ni copiar en un fin de semana, porque no existen fuera de la actividad acumulada de la propia plataforma. La distinción correcta no es "de cara al cliente sí, infraestructura no" — es "¿esta pieza es reemplazable por cualquier proveedor externo, o es donde vive una ventaja que solo Mercado puede tener por haber operado el tiempo suficiente?". La primera se compra. La segunda, aunque no la vea nunca el comprador final, bien vale construirla propia — y es, adelantado, el argumento completo del módulo 6.

Resumen y siguiente paso

En esta lección desarmaste la objeción de que la estrategia "no es trabajo tuyo": con el ingeniero de puentes viste que tienes información técnica que nadie más en la sala tiene, y que callarla —no por mala intención, sino por asumir que "no te toca"— deja pasar errores costosos hasta que es tarde para corregirlos barato. Con engineeringBetReport ejecutado sobre tres apuestas técnicas de Mercado, viste el radar de dos preguntas —¿es interesante? ¿sirve a la estrategia?— y notaste el caso más peligroso de los tres: la apuesta técnicamente fascinante que, sin ese radar, se construye igual, aunque no sirva a nada estratégico. Y viste, con el ejemplo de pagos, cómo build-vs-buy es exactamente el tipo de decisión donde tu criterio técnico, cruzado con la estrategia, decide si el esfuerzo de ingeniería se invierte donde de verdad importa.

Antes de avanzar deberías poder: dar al menos dos razones concretas por las que la estrategia también es tu responsabilidad como ingeniero; aplicar el radar de dos preguntas a cualquier propuesta técnica, propia o ajena; y explicar, con el caso de pagos, por qué build-vs-buy debería estar filtrado por la estrategia y no solo por capacidad técnica.

La lección 7 vuelve al modelo isRealStrategy de la lección 3 y lo pone a prueba sobre casos más difíciles: frases que suenan sofisticadas pero no eligen nada (lo que Rumelt llama fluff), listas de objetivos disfrazadas de estrategia, y —lo más importante— un caso donde el propio modelo se deja engañar, para que aprendas a no confiar en él a ciegas.

Recursos

• Richard Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters — penguinrandomhouse.com/books/208668. El libro dedica un capítulo entero a por qué "más features" o "más opciones" no es una estrategia sin una elección real detrás. En inglés.
• Marty Cagan (Silicon Valley Product Group), "Product Strategy" — svpg.com/product-strategy-overview. Cagan argumenta específicamente por qué la estrategia de producto requiere el juicio técnico de quien construye, no solo de quien planea. En inglés.