En el artículo anterior hablamos sobre cómo medir la experiencia real del usuario a través de los Web Vitals y la performance percibida. Hoy toca una verdad algo incómoda: podés tener la app más rápida del mundo, pero si no mueve las métricas de negocio, solo estás gastando tiempo, recursos y plata.

Una historia de terror

Todos pasamos por esto. Recibís un ticket en Jira, cumplís los criterios de aceptación al pie de la letra, el código es hermoso y los tests pasan sin problemas. Hacés el deploy y atacás inmediatamente la siguiente tarea. Tu burndown chart se ve perfecto.

Llega la reunión trimestral y el equipo de liderazgo muestra preocupación por la adquisición o el churn. Sentís que hablan un idioma totalmente diferente.

Ese es el síntoma principal de un problema común: estás atrapado en el ciclo de resolver tickets y desconectado de la realidad de tu producto.

Como ingenieros de producto, tenemos que entender que un release exitoso no es el que no rompe nada en producción; es el que aporta valor. Si desarrollamos una funcionalidad perfecta que nadie usa, el costo de oportunidad es inmenso.

Pirate Metrics (AARRR) para Devs

Para dejar de ser un “code monkey”, necesitás un mapa. Las Pirate Metrics son el framework que nos permite entender dónde nuestro código está impactando realmente:

• Acquisition (Adquisición): ¿Cómo llegan los usuarios? Si tu sitio pesa 5 MB de puro JS, Google te penalizará el ranking. Tu bundle es una métrica de adquisición.
• Activation (Activación): Si el registro tiene 15 pasos y la carga es lenta, los usuarios se van antes de conocer el valor de tu producto.
• Retention (Retención): El alma del Product Engineer. Si la app es inestable o confusa, el usuario no vuelve. Sin retención, no hay negocio.
• Referral (Referencia): ¿Qué tan fácil es invitar a un amigo? ¿Los usuarios recomiendan tu producto?
• Revenue (Ingresos): Cualquier problema en un flujo de pago puede convertirse en pérdidas de miles de dólares. Si tenemos un checkout de pago, tiene que ser impecable.

Bajemos esto a tierra con tres ejemplos donde una decisión de código impacta directamente en el negocio:

1. Deep Linking (Mobile)

Imagina lo siguiente: enviamos un email con un 20% de descuento. El usuario hace click, se abre la app… y cae en la Home (o peor, en el App Store). Perdiste. Implementar un sistema robusto de Universal Links (iOS) o App Links (Android) no es una mejora técnica, es una optimización directa de Conversión.

2. JS Payload y SEO

Cada KB que agregás al bundle afecta el Crawl Budget de Google. Si tu SEO es malo porque el sitio es pesado o difícil de indexar, marketing se ve obligado a gastar más en Ads para compensar la falta de tráfico orgánico. Optimizar el bundle le ahorra dinero a la empresa.

3. Observabilidad de Negocio

Loguear solo cuando algo explota (catch (e) { log(e) }) es poco, muy poco. El nivel avanzado es loguear intenciones. No solo quiero saber si el botón se clickeó; necesito saber el contexto: ¿el usuario venía de un A/B test? ¿cuánta metadata podemos asociar para entender por qué abandonó el carrito? Ver un usuario frustrado en un session replay vale más que mil logs de servidor.

¿Todo esto hace un Product Engineer?

Bueno, esto va a depender de cada empresa. El tamaño de la compañía, la cantidad de ingenieros que haya en el equipo, los problemas principales que tenga el producto.

Idealmente, estos problemas se pueden dividir entre dos perfiles: uno es el Product Engineer y el otro es el Growth Engineer. A menudo estos roles se confunden, pero son como dos hermanos con habilidades complementarias:

• El Product Engineer se enfoca en el “Core Value”: es el responsable de que el producto resuelva el problema de fondo. Busca soluciones robustas, entiende las necesidades del usuario y se preocupa por la calidad. Persigue la métrica de Retención.
• El Growth Engineer se enfoca en la “Distribución”: es un perfil de experimentación pura. Trabaja sobre el funnel (AARRR) para eliminar fricciones. No tiene una métrica por defecto, pero va a trabajar mucho sobre Adquisición, Activación y Revenue (Conversión).

En una startup, es muy probable que vos seas ambos. Un día estás implementando soporte offline o una arquitectura local-first para que la app sea resiliente y confiable (Product) y al día siguiente estás testeando si un onboarding de 3 pasos convierte mejor que uno de 5 (Growth).

Conclusión

Entender el negocio no te quita tiempo para programar; te da el criterio para saber qué vale la pena programar. No alcanza con cerrar tickets. El verdadero valor de nuestro trabajo está en entender cómo cada línea de código soluciona un problema real.

¿Cómo se ve esto en la práctica cuando las papas queman?

En el próximo artículo, vamos a analizar un caso desde tres lentes distintos: el del Dev 100% técnico, el del Product Engineer y el del Growth Engineer.