Un representante de ventas cerro $240K el ultimo trimestre y se llevo $36K en comision
Nadie pestanho. Asi funciona ventas. La persona mas cerca del revenue se lleva una porcion. Ahora imagina esto: una ingeniera lanza un rediseno de la pagina de precios que aumenta la conversion en 18%, generando $1.2M en ARR incremental. Ella recibe su salario. Tal vez una palmada en la espalda. Quiza un bono spot de $5K tres meses despues, tras dos niveles de aprobacion.
Algo esta roto aqui. Segun la investigacion de product.engineer sobre modelos de compensacion, la compensacion de ingenieros con ownership, la idea de que los constructores deberian participar directamente en el valor que crean, esta ganando traccion en empresas que se han dado cuenta de que sus empleados de mayor impacto no estan en la organizacion de ventas. Estan en el codebase. Son los product engineers que son duenos del ciclo completo desde el problema del cliente hasta la solucion lanzada y el outcome medido.
El modelo de compensacion con ownership hace una pregunta simple: si un ingeniero puede demostrar impacto directo en revenue, ¿por que su estructura de pago no se parece en nada a la de las personas en ventas que tambien demuestran impacto directo en revenue? Esto no se trata de reemplazar el salario base con cheques de comision. Se trata de alinear incentivos para que los ingenieros mas cercanos a los outcomes de negocio tengan skin in the game que iguale su alcance.
Únete a 2.000+ ingenieros que definen, construyen y entregan.
Un correo por semana. Frameworks prácticos para ingenieros de producto. Sin spam.
En 2025, Tenex (la plataforma de AI engineering) compartio publicamente su modelo de compensacion donde los ingenieros ganan bonos basados en revenue vinculados a los productos que construyen. El video alcanzo 6.6K vistas en YouTube y genero un debate genuino. No porque la idea fuera radical, sino porque le puso nombre a algo que muchos equipos ya estaban haciendo informalmente. Ahora empresas desde PostHog hasta startups en etapa temprana estan experimentando con variaciones de este modelo. Permitan que les explique como funciona, donde se rompe y si tiene sentido para su equipo.
Por que la compensacion de ingenieros con ownership rompe el pago tradicional
El paquete estandar de compensacion de SWE tiene tres componentes: salario base, equity (RSUs u opciones) y un bono anual vinculado a evaluaciones de desempeno. Esta estructura fue disenada para un mundo donde los ingenieros recibian especificaciones, escribian codigo y entregaban el output a alguien mas que decidia si funcionaba.
Ese mundo esta desapareciendo. La trayectoria de carrera de product engineer ahora demanda ingenieros que identifiquen que construir, lo construyan, lo lancen, lo midan e iteren. No estan ejecutando el plan de alguien mas. Estan haciendo apuestas. Y las estructuras de compensacion tradicionales no logran contabilizar la varianza en outcomes que estas apuestas producen.
Considera la matematica. Dos senior engineers en la misma empresa, mismo nivel, mismo salario base de $220K:
| Ingeniero | Trabajo lanzado | Impacto en revenue | Compensacion |
|---|---|---|---|
| Ingeniero A | Reconstruyo el flujo de onboarding | +$3.2M ARR por mejora en tasa de activacion | $220K base + $30K bono |
| Ingeniero B | Migro capa de base de datos | $0 directo (necesario pero sin revenue) | $220K base + $28K bono |
El Ingeniero A genero 14x su compensacion en valor de negocio medible. El Ingeniero B hizo trabajo de infraestructura critico que habilito features futuras. Ambos son valiosos. Pero el modelo de compensacion los trata identicamente. En ventas, el equivalente seria pagarle al rep que cerro $3M lo mismo que al rep que organizo el CRM. Nadie disenaria ese sistema.
Los ingenieros del cuartil superior en startups en etapa de crecimiento generan muchos multiplos de su compensacion total en impacto de revenue atribuible. La proporcion es incluso mayor en empresas de product-led growth donde la ingenieria toca directamente conversion, activacion y expansion.
En product.engineer, identificamos tres problemas centrales que esta desconexion crea:
- Incentivos desalineados. Los ingenieros optimizan para lo que se mide y recompensa. Si la velocidad de lanzamiento y la calidad del codigo son las unicas metricas que afectan la comp, los ingenieros lanzaran rapido y escribiran codigo limpio para features que tal vez no importen.
- Riesgo de retencion. Tus ingenieros de mayor impacto son exactamente los que se dan cuenta de la asimetria primero. Saben que generaron $5M en impacto y recibieron un aumento estandar del 4%. Se van.
- Desgaste del modo founder. Los ingenieros que piensan como founders, que naturalmente persiguen impacto en revenue y outcomes de clientes, eventualmente concluyen que simplemente deberian convertirse en founders. Porque solo los founders reciben compensacion proporcional al valor creado.
Como funciona en la practica la compensacion de ingenieros con ownership
La compensacion de ingenieros con ownership es una estructura de pago que vincula una porcion significativa de la compensacion total de un ingeniero a outcomes de negocio medibles que influyen directamente. No es comision en el sentido tradicional. Es un modelo hibrido que preserva la estabilidad del salario base mientras agrega un componente basado en outcomes que recompensa el impacto desproporcionado.
Aqui esta el framework que llamo el Modelo de Comp con Ownership para PE, estructurado en tres niveles:
Nivel 1: Estabilidad base (60-70% de la comp objetivo)
Salario base estandar, competitivo con el mercado. Esto proporciona el piso. Nadie deberia preocuparse por pagar la renta porque un lanzamiento de feature se retraso dos semanas. El base es ligeramente mas bajo que un rol totalmente asalariado al mismo nivel, creando espacio para los componentes de upside.
Nivel 2: Multiplicador de outcomes (20-30% de la comp objetivo)
Esta es la capa de ownership. Los ingenieros definen objetivos de outcomes al inicio de cada trimestre (o ciclo de proyecto). Los objetivos deben ser:
- Medibles: vinculados a una metrica especifica (revenue, tasa de activacion, retencion, NPS)
- Atribuibles: el trabajo del ingeniero debe ser el driver principal, no uno de quince factores contribuyentes
- Limitados en tiempo: medidos durante una ventana definida (tipicamente 30-90 dias post-lanzamiento)
El pago escala con el desempeno contra el objetivo. Alcanza el 100% del objetivo, gana el 100% del multiplicador de outcomes. Supera por 50%, gana 150%. Queda debajo por 50%, gana 50%. El piso tipicamente es 50% (para que los ingenieros aun reciban pago de outcomes significativo incluso en un mal trimestre), y el techo es sin limite o con tope en 200-300%.
Nivel 3: Aceleracion de equity (10-15% de la comp objetivo)
Para desempeno alto sostenido, grants de equity adicionales o vesting acelerado. Esto recompensa el impacto compuesto a lo largo del tiempo y mantiene fuerte la retencion para ingenieros que consistentemente entregan resultados sobresalientes.
La estructura combinada se ve asi para un senior engineer en este modelo:
| Componente | Monto objetivo | Rango |
|---|---|---|
| Salario base | $180K | Fijo |
| Multiplicador de outcomes | $60K objetivo | $30K - $180K |
| Aceleracion de equity | $30K/ano | $0 - $60K |
| Total objetivo | $270K | $210K - $420K |
Compara eso con un paquete tradicional: $220K base + $30K bono + $50K equity = $300K con esencialmente cero varianza basada en impacto. El modelo de ownership tiene un piso mas bajo pero un techo significativamente mas alto para ingenieros que lanzan cosas que importan.
Como las empresas estan implementando esto hoy
Esto no es teorico. Multiples empresas estan ejecutando variaciones de este modelo ahora mismo, y los datos tempranos son prometedores.
PostHog: Revenue sharing a nivel de equipo
PostHog se organiza en equipos pequenos (3-5 personas) que son duenos de areas de producto especificas. Segun su handbook publico, los equipos tienen visibilidad directa de metricas de revenue para su area. Aunque PostHog no ha revelado la mecanica exacta de su modelo de comp publicamente, han hablado sobre alinear incentivos de equipo con revenue de producto y dar a los ingenieros acceso directo a datos de facturacion y metricas de conversion. La cultura esta explicitamente disenada para que los ingenieros sientan ownership sobre revenue, no solo sobre codigo.
Tenex: Comision directa sobre revenue
Tenex, la plataforma de AI engineering, hizo totalmente publico su modelo en 2025. Los ingenieros que construyen productos orientados al cliente ganan un porcentaje del revenue que esos productos generan. El porcentaje exacto varia por rol y seniority, pero el principio es transparente: si construyes algo que genera dinero, compartes ese dinero. Su CEO lo describio como "tratar a los ingenieros como adultos que pueden ver el P&L."
Segun el equipo de Tenex, este modelo llevo a un aumento del 40% en velocidad de lanzamiento para features que generan revenue. Los ingenieros naturalmente priorizaron trabajo que moveria metricas de negocio porque su comp estaba directamente vinculada a esas metricas.
Shopify: Pools de bonos basados en outcomes
Shopify ha estructurado la ingenieria durante mucho tiempo alrededor de "crafters" que son duenos de areas de producto de punta a punta. Su estructura de bonos incluye componentes basados en outcomes donde ingenieros que lanzan features que impulsan el crecimiento de GMV de merchants reciben mayores asignaciones de bonos. Esto no es comision pura, pero es direccionalmente lo mismo: los outcomes de negocio influyen en la compensacion mas alla del ciclo de evaluacion estandar.
Startups en etapa temprana: Equity hibrido + revenue share
Un numero creciente de startups Serie A y B estan ofreciendo a ingenieros una eleccion: mayor equity con base mas bajo, o equity moderado con un componente de revenue share. Esto es particularmente comun en empresas de product-led growth donde ingenieros individuales pueden ser duenos de features que tocan directamente MRR. Un analisis de Levels.fyi de ofertas de startups en 2025 mostro un aumento de 3x en menciones de "compensacion variable" en ofertas de trabajo de ingenieria comparado con 2023.
Donde el modelo se rompe
Seria deshonesto si presentara esto como una victoria pura. Habiendo contratado a mas de 600 ingenieros y guiado a 12,000 mas, he visto experimentos de compensacion salir mal de formas predecibles. El modelo de ownership tiene modos de falla alrededor de los cuales necesitas disenar.
El problema de atribucion
El revenue raramente viene del trabajo de una sola persona. ¿Esa victoria de conversion en la pagina de precios? Requirio al disenador que corrio los experimentos, al data engineer que construyo el pipeline de analytics, al ingeniero de infraestructura que hizo que la pagina cargue en 200ms, y al constructor que lo conecto todo. Atribuir revenue a un solo ingeniero crea dinamicas toxicas.
La solucion: Mide a nivel de equipo, no a nivel individual. Equipos pequenos (2-4 personas) comparten objetivos de outcomes. Esto preserva incentivos de colaboracion mientras sigue creando un feedback loop mas estrecho que bonos a nivel empresa.
La penalizacion de infraestructura
No todo el trabajo de ingenieria tiene atribucion directa de revenue. Migraciones de base de datos, hardening de seguridad, optimizacion de rendimiento y confiabilidad de plataforma son todos criticos. Si solo recompensas trabajo que genera revenue, nadie se ofrece voluntariamente para la fundacion.
La solucion: Crea un track paralelo para impacto de infraestructura. Midelo diferente: mejora de uptime, reduccion de latencia, metricas de velocidad del desarrollador. O rota ingenieros entre trabajo orientado a revenue e infraestructura en ciclos de 6 meses, con objetivos de outcomes ajustados acorde. La cultura de product engineering en empresas como Linear explicitamente valora tanto el trabajo orientado al cliente como el fundacional.
La trampa del corto plazo
Si tu multiplicador de outcomes se mide trimestralmente, los ingenieros optimizaran para victorias trimestrales. Lanzaran el hack rapido de conversion sobre la inversion de plataforma a largo plazo. Este es el mismo problema que afecta a organizaciones de ventas con cuotas puramente trimestrales.
La solucion: Mezcla horizontes temporales. 50% del multiplicador de outcomes en metricas de 90 dias, 50% en metricas de 180 dias. Esto obliga a los ingenieros a balancear victorias inmediatas con impacto sostenido. El nivel de aceleracion de equity tambien ayuda, ya que recompensa valor compuesto a lo largo de anos, no semanas.
El riesgo de gaming
Los ingenieros son inteligentes. Si les dices que su comp depende de una metrica, encontraran formas de mover esa metrica que no necesariamente crean valor real. La Ley de Goodhart aplica con fuerza aqui.
La solucion: Usa metricas compuestas, no numeros individuales. Vincula outcomes a una canasta de 2-3 metricas relacionadas que son mas dificiles de gamear simultaneamente. Por ejemplo: revenue Y retencion Y NPS. Mover una a expensas de las otras no aumenta la comp.
Para quien funciona este modelo (y para quien no)
Basado en los patrones que he observado, el modelo de compensacion con ownership funciona mejor en contextos especificos:
Funciona bien para:
- Empresas de product-led growth donde la ingenieria toca revenue directamente
- Equipos pequenos (menos de 50 ingenieros) donde la atribucion es mas clara
- Empresas donde los ingenieros son duenos del ciclo completo desde problema hasta medicion
- Roles con output claro y medible vinculado a metricas de negocio
- Equipos con infraestructura de analytics madura que puede atribuir impacto
No funciona bien para:
- Equipos de plataforma grandes donde el trabajo esta a muchas capas de distancia del revenue
- Empresas sin metricas de producto claras o modelos de atribucion
- Etapas tempranas de prototipado donde el objetivo es aprender, no generar revenue
- Ingenieros que explicitamente quieren estabilidad y predictibilidad sobre upside
- Organizaciones sin confianza y transparencia alrededor de datos financieros
La perspectiva clave: este modelo funciona cuando los ingenieros ya actuan como duenos. Falla cuando lo usas para intentar que no-duenos se comporten diferente. La estructura de compensacion sigue a la cultura; no la crea. Si tus ingenieros no tienen acceso a datos de clientes, metricas de producto y contexto de negocio, pagarles por outcomes es solo estres sin agencia.
Desde mi experiencia construyendo estos sistemas
Cuando estaba liderando equipos de ingenieria como founder, experimente con una version de este modelo por necesidad. No podiamos competir con Big Tech en salario base. Pero podiamos ofrecer a los ingenieros algo que Big Tech nunca ofreceria: conexion directa, visible e inmediata entre su trabajo y el revenue de la empresa.
Lo estructuramos simplemente. Los ingenieros elegian su proyecto principal cada trimestre. Acordabamos una metrica de exito antes de que escribieran una linea de codigo. Si la metrica se movia, ganaban un multiplicador sobre su bono trimestral que escalaba linealmente con el impacto. Sin topes.
Tres cosas pasaron. Primero, los ingenieros empezaron a hacer mejores preguntas antes de construir. "¿Que metrica mueve esto?" se convirtio en una parte estandar de cada design review. Segundo, la velocidad de features aumento porque los ingenieros estaban intrinsecamente motivados a lanzar y medir, no solo lanzar y seguir adelante. Tercero, y esto me sorprendio, la colaboracion aumento. Los ingenieros que sabian que su comp dependia de un outcome activamente reclutaban ayuda de otras disciplinas porque querian que la cosa tuviera exito, no solo que se completara.
El caso de falla tambien fue instructivo. Dos ingenieros gamearon sus metricas eligiendo objetivos faciles que sabian que podian alcanzar. Lo arreglamos requiriendo calibracion entre pares sobre la dificultad del objetivo, similar a como las organizaciones de ventas establecen cuota basada en potencial del territorio, no forecasts sandbageados.
Como Sr. Product Engineer en AWS, vi una version diferente de esta dinamica. Los Leadership Principles crean presion cultural hacia el ownership, pero el modelo de compensacion es tradicional. Los ingenieros que generan el mayor impacto de negocio a menudo son recompensados con refreshes de RSU ligeramente mayores, pero la conexion es indirecta y retrasada. Los mejores ingenieros ahi conocen su impacto. Solo aceptan que la estructura de recompensa va detras de el.
Implementando el modelo: un blueprint practico
Si estan considerando esto para su equipo, aqui esta la secuencia de implementacion que recomiendo:
Fase 1: Mide antes de compensar (Meses 1-3)
Empieza a rastrear atribucion de revenue por equipo. No cambies la comp todavia. Solo haz el impacto visible. Dale a cada ingeniero un dashboard mostrando metricas de negocio que su area de producto influencia. Deja que los datos se acumulen durante un trimestre completo.
Fase 2: Piloto con voluntarios (Meses 4-6)
Ofrece el modelo como opcion a 3-5 senior engineers que ya son high performers. Deja que elijan entre comp tradicional y el modelo de ownership. La auto-seleccion reduce el riesgo porque los ingenieros que optan creen en su propio impacto.
Fase 3: Calibra e itera (Meses 7-9)
Revisa los datos del piloto. ¿Los ingenieros ganaron mas de lo que hubieran ganado tradicionalmente? (Deberian. Si no, los objetivos son demasiado agresivos.) ¿El comportamiento cambio positivamente? ¿Alguien gameo el sistema? Ajusta la mecanica basandote en datos reales.
Fase 4: Expande con cuidado (Meses 10-12)
Despliega al equipo de ingenieria mas amplio, todavia como opcion. Nunca fuerces a los ingenieros a comp variable. Algunas personas prefieren estabilidad, y esa es una eleccion valida.
Necesitaras infraestructura de soporte:
- Tooling de analytics: Mixpanel, Amplitude o PostHog con event tracking vinculado a eventos de revenue
- Modelo de atribucion: First-touch, last-touch o basado en equipo. Atribucion imperfecta es mejor que cero atribucion.
- Finanzas transparentes: Los ingenieros necesitan ver los numeros. Si no puedes compartir datos de revenue con ingenieria, no estas listo.
- Capacitacion de managers: Los engineering managers deben pasar de evaluar output de codigo a evaluar outcomes de negocio.
Las metricas que importan para la compensacion de ingenieros con ownership
No todas las metricas son iguales para propositos de compensacion. Aqui esta como las categorizo:
Nivel 1: Metricas de revenue directo (mayor claridad de atribucion)
- Mejoras en tasa de conversion (trial a pagado, free a premium)
- Cambios en revenue por usuario vinculados a lanzamientos de features especificos
- Revenue de expansion de features que impulsan upsells
- Reduccion de churn de trabajo enfocado en retencion
Nivel 2: Metricas de indicadores adelantados (fuerte correlacion con revenue)
- Mejoras en tasa de activacion
- Tasas de adopcion de features
- Reduccion de time-to-value
- Mejoras de NPS o CSAT en areas de producto especificas
Nivel 3: Metricas habilitadoras (indirectas pero necesarias)
- Mejoras de tiempo de carga de pagina (correlacion comprobada con conversion)
- Mejoras de uptime y confiabilidad
- Metricas de velocidad del desarrollador (para equipos de plataforma)
- Mejoras de postura de seguridad (reduccion de riesgo = preservacion de valor)
El modelo de compensacion con ownership deberia ponderar las metricas de Nivel 1 mas fuertemente para el multiplicador de outcomes, usar metricas de Nivel 2 como evidencia de soporte, y manejar el Nivel 3 a traves del track paralelo de infraestructura mencionado anteriormente.
Comparacion: modelos de comp tradicional vs. ownership
| Dimension | Modelo tradicional | Modelo de ownership |
|---|---|---|
| Varianza de comp | Baja (rango de bono 5-10%) | Alta (rango de outcomes 50-200%) |
| Velocidad de feedback | Anual (ciclo de evaluacion) | Trimestral o por proyecto |
| Incentivo de comportamiento | Lanzar codigo, cumplir expectativas | Lanzar outcomes, mover metricas |
| Retencion de top performers | Moderada (top earners tocan techo) | Alta (upside sin tope) |
| Retencion de performers estables | Alta (predecible) | Moderada (pueden preferir tradicional) |
| Carga de atribucion | Baja (managers evaluan por vibes) | Alta (necesita medicion real) |
| Riesgo de gaming | Bajo stake, baja recompensa | Mayor stake, necesita safeguards |
| Requerimiento cultural | Cultura de ingenieria estandar | Alta confianza, alta transparencia |
La pregunta filosofica debajo de todo
Esto es lo que este debate realmente plantea. ¿Crees que los ingenieros son profesionales creativos cuyo trabajo tiene valor variable, mas como vendedores o portfolio managers? ¿O crees que la ingenieria es una practica de estado estable donde la calidad del output es relativamente uniforme entre practicantes competentes?
Si crees lo primero, la comp tradicional esta dejando valor sobre la mesa para tu mejor gente. Si crees lo segundo, la comp tradicional es justa y eficiente.
Yo creo que este rol especificamente selecciona personas que operan en el primer modo. Estan haciendo apuestas. Estan eligiendo que construir. Estan mas cerca de emprendedores que de trabajadores de linea de ensamblaje. Y el modelo de compensacion deberia reflejar eso.
Esto no significa que todo ingeniero deberia estar en un modelo de comision. No todo rol demanda este nivel de ownership. La industria necesita ambos arquetipos, y ambos merecen estructuras de compensacion que emparejen sus patrones de trabajo.
Pero para los ingenieros que eligen ownership, que eligen ser responsables de outcomes y no solo de output, el modelo de comp actual es un impuesto de friccion sobre la ambicion. Las empresas que eliminen esa friccion atraeran a los constructores mas capaces del mercado.
El cambio esta sucediendo. Si tu organizacion participa o pierde talento ante las que si lo hacen es la pregunta que queda.
Puntos clave
- La compensacion de ingenieros basada en outcomes vincula 30-40% del pago a impacto de producto medible como adopcion, revenue o retencion.
- El modelo mantiene 60-70% de salario base fijo para que el riesgo sea mayormente varianza de upside, no exposicion a la baja.
- Los ingenieros con altos multiplicadores de outcomes ganan significativamente mas de lo que las estructuras de compensacion tradicional permiten.
- Este modelo solo funciona cuando los ingenieros son duenos del ciclo completo desde la identificacion del problema hasta la medicion.
- Las empresas que adoptan pago basado en outcomes reportan mayor retencion de top performers y adopcion de features mas rapida.
FAQ
¿La compensacion de ingenieros con ownership significa que los ingenieros asumen mas riesgo financiero?
Algo, pero menos de lo que piensas. La implementacion tipica mantiene 60-70% de la compensacion como salario base fijo, que sigue siendo una tasa competitiva del mercado. El componente variable reemplaza lo que de otra forma seria un bono estandar, no el base. Los ingenieros con altos multiplicadores de outcomes en realidad ganan significativamente mas que la comp tradicional, asi que el "riesgo" es mayormente varianza de upside. Un modelo bien disenado tiene un piso de 50% en el componente variable, lo que significa que las ganancias en el peor caso son ligeramente inferiores a un paquete tradicional mientras que en el mejor caso son sustancialmente superiores.
¿Como manejas a ingenieros que trabajan en features que toman seis meses o mas en mostrar impacto en revenue?
Mezcla horizontes temporales. Para proyectos de largo plazo, establece milestones intermedios (lanzado a beta, alcanzo uso objetivo, mostro movimiento de indicadores adelantados) que liberen pagos parciales de outcomes en el camino. Reserva el multiplicador completo para la medicion final de revenue, pero no hagas que los ingenieros esperen seis meses con cero compensacion variable. Tenex aborda esto permitiendo a los ingenieros carry forward creditos de outcomes de trimestre a trimestre para iniciativas multi-trimestre.
¿Este modelo creara competencia toxica entre ingenieros o equipos?
Solo si lo implementas a nivel individual sin guardrails. Objetivos de outcomes basados en equipo (compartidos entre squads de 2-4 personas) preservan incentivos de colaboracion mientras siguen creando feedback loops mas estrechos que bonos a nivel empresa. Las mejores implementaciones incluyen un componente de "asistencia de equipo" donde ayudar a otro squad a alcanzar su objetivo de outcomes contribuye a tu propio score. El modelo de equipos pequenos de PostHog maneja esto naturalmente porque nadie puede tener exito solo en un equipo de 3 personas.
¿Es este modelo legal y cumple con regulaciones de empleo?
Si, en la mayoria de jurisdicciones. La compensacion variable vinculada a metricas de desempeno es practica estandar en ventas, compensacion ejecutiva y finanzas. Los requisitos clave incluyen documentacion clara del establecimiento de objetivos, aplicacion no discriminatoria y asegurar que el salario base cumpla umbrales salariales de estatus exento. Consulta con abogados laborales, pero la estructura esta bien establecida.
¿Que pasa cuando el feature de un ingeniero tiene exito debido a factores fuera de su control (como un momento viral o cambio de mercado)?
Lo mismo que pasa en ventas cuando el territorio de un rep explota debido a dinamicas de mercado: se benefician. Esto es una feature, no un bug. Quieres que los ingenieros elijan trabajar en cosas con viento de cola del mercado. Dicho esto, el establecimiento de objetivos deberia considerar el crecimiento baseline. Si la empresa crece 30% organicamente, los objetivos de outcomes deberian establecerse por encima de ese baseline. Estas midiendo impacto incremental, no surfeando la ola.