El 73% de los SaaS No Fracasa por Elegir PLG o Sales-Led: Fracasa por Negarse a Dejar de Serlo

Crees que la decisión PLG vs Sales-Led es estratégica. Que eliges el modelo correcto, compras el marco mental, y te comprometes hasta el final. Que el foco lo es todo.

Te has equivocado de diagnóstico.

El 73% de los SaaS no fracasa por elegir mal el modelo de crecimiento: fracasa por adherirse rígidamente a un único modelo cuando el producto y el mercado evolucionan. La rigidez de identidad — "somos una empresa PLG" — sobrevive a los datos que la justificaron.

Igual que una feature muerta sobrevive en tu roadmap por haber sido pedida una vez, un modelo de crecimiento caducado sobrevive porque cambiar de identidad da miedo.

No es una guerra entre dos filosofías. Es un problema de enrutamiento.

---

El 73%: Desambiguemos la Cifra Antes de que la Uses Mal

El número aparece en el hilo de dos formas que conviene separar.

Por un lado, el 73% de los SaaS adopta un modelo puro — PLG o Sales-Led. Por otro, el 73% de los SaaS fracasa. Los dos usos se cruzan en un sitio incómodo: el modelo puro es, en sí mismo, el modo de fallo.

No digo que el dato sea una causalidad probada con ensayo controlado. Es correlación. Pero el mecanismo detrás del número tiene más peso que el titular: las empresas se casan con una etiqueta, y la etiqueta sobrevive a la evidencia.

Piénsalo desde la práctica. Cuando hablas con fundadores que han vivido el ciclo completo — del Product-Led start-up al enterprise con ciclo comercial de meses — casi todos te cuentan la misma historia en dos actos. En el acto uno, montan un funnel self-serve impecable, con onboarding que se activa solo, y celebran que nadie necesita tocar a un vendedor. En el acto dos, el ACV sube, aparecen los security reviews, los procurement cycles, los múltiples stakeholders... y de repente la motion self-serve deja de servir para los deals que pagan la nómina.

La mayoría no reacciona cambiando la motion. Reacciona defendiendo la etiqueta. "Somos PLG, vendemos al desarrollo, el enterprise llegará solo." Y el enterprise llega... a la competencia.

❌ El enfoque débil: elegir PLG porque es moda, o porque un inversor lo pide, o porque "todo el mundo lo hace". Basar la identidad en la etiqueta, no en el uso.

✅ El enfoque fuerte: mirar los datos de uso de tu producto hoy. Ver qué motion activa y retiene usuarios de verdad. Y diseñar el sistema para que la motion cambie cuando los datos lo señalen.

La pregunta correcta no es "¿PLG o Sales-Led?". Es "¿qué motion usa cada segmento en cada fase, y qué trigger me dice cuándo cambiar?"

Hay un matiz adicional que conviene capturar: muchos equipos confunden "PLG" con "no hacer sales". Y no es lo mismo. PLG puro significa que el producto es el canal de conversión y expansión, no que no exista un equipo comercial. Incluso en las empresas PLG más canónicas, el sales aparece — solo que enroutado al final del embudo, cuando el usuario ya ha visto valor y el deal justifica un ejecutivo. El error no es tener sales. El error es no tener un trigger que decida cuándo su aparición es productiva y cuándo es ruido.

---

La Lección del 90%: las Peticiones Son Síntomas, en Features Y en Growth Models

Tenemos un aprendizaje previo que se transfiere directo a este problema.

El 90% de los SaaS llena su roadmap con features que un cliente pidió, no con features que los usuarios usan. Las peticiones son síntomas de problemas más profundos, no causas. El resultado son roadmaps llenos de funciones que nadie toca.

El mecanismo es siempre el mismo y conviene desmontarlo con calma. Un cliente importante envía un correo pidiendo una feature. El equipo de Customer Success lo eleva porque "un enterprise lo ha pedido". El product manager lo mete en el roadmap porque tiene presión de revenue. Se construye, se lanza, y un trimestre después nadie lo usa. Pero nadie lo elimina tampoco, porque eliminarlo implicaría admitir que el proceso de priorización funciona mal.

La señal fiable no es la petición. Es el uso. En features y en growth models.

Ahora aplica el mismo sesgo a los modelos de crecimiento. Las empresas no eligen PLG porque los datos de uso lo respalden. Lo eligen porque un stakeholder lo pidió. Porque un board member viene de una empresa PLG y "sabe cómo funciona". Porque un gurú de LinkedIn lo predica. Porque un competidor lanzó un self-serve y "nos estamos quedando atrás".

Es exactamente el mismo error, un nivel más arriba.

Y el error se agrava porque la petición no solo influye en la elección inicial: también congela la evolución. Una vez que la empresa se declara PLG, cada petición posterior de intervención comercial (un demo, un call de discovery, un playbook de venta) se rechaza con el mismo argumento: "eso no es PLG". La identidad se convierte en un escudo contra los datos.

Mira tu producto hoy. ¿Quiénes se activan solos? ¿Quiénes necesitan una demo para entender el valor? ¿Qué segmento llega al time-to-value sin tocarte, y cuál se pierde en el onboarding?

Eso es lo único que importa. No lo que pide tu mayor cliente. No lo que hizo un SaaS famoso. Lo que tus datos de uso dicen.

---

El Valor No Está en la Etiqueta: la Lección Transferida del SKILL.md

Hay un segundo aprendizaje que se transfiere perfecto.

En los sistemas de agentes, el valor durable de una skill vive en dos sitios: en la descripción (que funciona como query de un sistema de recuperación) y en los assets empaquetados (que convierten instrucciones en capacidad ejecutable). El fichero de etiqueta — el SKILL.md — es la parte menos importante del sistema.

Esto merece un poco más de desarrollo, porque la analogía es más profunda de lo que parece a primera vista. En un sistema de agentes bien construido, la descripción de una skill no es un titular bonito: es un índice de recuperación. Cuando un agente recibe una tarea, consulta las descripciones para decidir qué skill ejecutar. Si la descripción no refleja con precisión qué puede hacer esa skill, el sistema enrouta mal: elige la skill equivocada, o no encuentra la que tenía capacidad de resolver el problema.

Un modelo de crecimiento funciona igual. La etiqueta "PLG" o "Sales-Led" es tu descripción de recuperación. Si es demasiado vaga o demasiado rígida, el sistema enrouta mal: aplica una motion self-serve a un deal que necesitaba venta asistida, o mete un playbook comercial en un segmento que se activaba perfectamente solo.

Un modelo vale por su mecánica: el loop self-serve, los playbooks de handoff, el packaging de la oferta, el tiempo hasta el valor. No vale por llamarse "PLG" o "Sales-Led".

La etiqueta es, literalmente, la parte menos importante del sistema.

Cuando dices "somos una empresa PLG", estás describiendo la etiqueta, no la mecánica. Cuando dices "enroutamos el self-serve a la larga cola y la venta asistida a los deals complejos", estás describiendo un sistema que funciona.

Uno es identidad congelada. El otro es ingeniería de crecimiento.

Fíjate en el tipo de conversaciones que generan ambas frases. Con la primera, la discusión es filosófica: "¿podemos llamarnos PLG si tenemos un sales team?" Con la segunda, la discusión es operativa: "¿cuál es el trigger exacto que separa un deal complejo de uno self-serve?" Una te lleva a debates de branding interno. La otra te lleva a métricas, playbooks y decisiones ejecutables.

---

El Híbrido No Es Hacer las Dos Cosas en Todas Partes: Es una Decisión de Enrutamiento

Aqui es donde la mayoría se pierde.

El híbrido no significa "hacer PLG y Sales-Led a la vez en todos los segmentos". Eso es confusión operativa con nombre bonito. Es la trampa en la que caen los equipos que, hartos del debate binario, deciden hacer "de todo para todos": producto con self-serve perfecto, sales team persiguiendo cada lead, y ningún criterio que diga quién pertenece a cada vía. El resultado es una organización que hace dos cosas mal en lugar de una bien.

El híbrido es una decisión de enrutamiento, como un sistema de recuperación que sirve el asset correcto según la query. Cada segmento se enruta a la motion que le corresponde:

Self-serve para la larga cola: usuarios que se activan solos, bajo ACV, time-to-value corto.
Asistida para los deals complejos: múltiples stakeholders, integraciones profundas, ciclo largo.
Con un handoff definido entre ambas y un trigger medible que decide cuándo saltar.

Hay una analogía directa con el mundo físico que ayuda a entenderlo. Imagina una carretera con dos carriles: uno de peaje y otro gratuito. El peaje no existe para todo el mundo — existe para los conductores cuyo tiempo vale más que el coste del peaje. La carretera no "es de peaje" ni "es gratuita": es un sistema de enrutamiento que decide en cada entrada qué carril sirve a qué conductor.

Tu producto es esa carretera. El sistema de enrutamiento decide en qué carril entra cada usuario según sus datos de uso, su ACV potencial, su comportamiento de activación. Y puede cambiar de carril en mitad del viaje — ahí está el handoff.

El trigger no es opinión. Es un dato.

---

El Sistema de Enrutamiento por Uso: El Framework de 5 Pasos para Dejar de Ser Puro

Te voy a dejar el marco que uso. Lo llamo el Sistema de Enrutamiento por Uso — un método de cinco pasos para que cada segmento reciba la motion que sus datos de uso justifican.

Paso 1: Audita con uso, no con peticiones

Mide qué motion — self-serve o asistida — activa y retiene usuarios hoy. No lo que piden. No lo que hiciste el año pasado.

Métricas que importan: tasa de activación sin tocar a nadie, time-to-value, porcentaje de usuarios que llegan al aha moment solos, comportamiento de expansión (quién paga más y cuándo).

Un ejercicio práctico que funciona bien: segmenta tu base en cuartiles de ACV y calcula la tasa de activación self-serve de cada cuartil. El resultado suele dibujar una curva reveladora. En la mayoría de los SaaS, el cuartil inferior se activa solo con tasa alta, y el cuartil superior apenas se activa sin intervención. Si tu identidad dice "somos PLG" pero tu cuartil de enterprise no se activa jamás sin un demo, tienes tu respuesta: el problema no es el mercado, es el enrutamiento.

Paso 2: Define el trigger de transición explícito

Señales medibles que indiquen cuándo añadir o cambiar de motion. Sin trigger, el cambio es opinión, no decisión.

Ejemplos: usuarios con determinada tasa de activación se quedan en self-serve. Usuarios con señales de expansión y ciclo largo migran a asistida. Puntos de fricción medibles en el onboarding disparan intervención humana.

La tentación aquí es definir triggers vagos ("cuando el deal sea complejo"). Resistela. Un trigger sirve si un humano puede decir hoy, en este momento, por qué este usuario concreto está en self-serve y aquel no. Si la respuesta depende del criterio subjetivo de cada Account Executive, no tienes un sistema: tienes suerte variable.

Paso 3: Diseña el handoff híbrido

Especifica el punto exacto donde termina el self-serve y empieza la motion asistida. No dejes que sea improvisación del equipo de ventas.

Define playbooks de handoff: qué datos ve la persona asistida, qué contexto del producto recibe, qué se le cuenta al usuario en el cambio. Los assets empaquetados que convierten instrucciones en capacidad ejecutable.

En la práctica, el handoff se rompe casi siempre en el mismo sitio: el contexto. Un usuario ha estado usando el producto de forma self-serve durante semanas, y cuando salta a venta asistida, el comercial le pide que explique qué estaba haciendo. Ese fricción es evitable: el dato ya existe en tu producto. El playbook de handoff debería empaquetar ese contexto y entregárselo al comercial como punto de partida, no como juego de adivinanzas.

Paso 4: Versiona el modelo

Trata el modelo de crecimiento como un artefacto iterable, no como una decisión de una sola vez. Se revisa trimestralmente, se versiona, se a/b testea.

Igual que tu roadmap debería tener features muertas eliminadas, tu growth model debería tener motions retiradas cuando los datos la contradicen.

Este es quizá el cambio cultural más difícil del framework, porque implica aceptar que tu modelo actual tiene fecha de caducidad. Los equipos que dominan esta práctica funcionan con un calendario de revisión fijo: cada trimestre se auditan los triggers, se comparan tasas de activación por segmento, y se versiona el modelo si los datos lo piden. La versión anterior no se descarta — se archiva, como se archiva una feature que fue relevante y dejó de serlo.

Paso 5: Desacopla identidad de mecánica

Elimina el framing "somos una empresa PLG". Sustitúyelo por "usamos motion X cuando los datos dicen Y".

La etiqueta es la parte menos importante. La mecánica que responde al uso es todo el sistema.

---

Las Objeciones Que Te Van a Poner, y la Respuesta

"El foco lo es todo — un híbrido diluye ambas motions."

El foco debe estar en el trigger y el handoff, no en la etiqueta. La rigidez, no la falta de foco, es el mecanismo del fracaso del 73%. Un híbrido bien diseñado no es falta de foco: es un sistema único con dos carriles y una lógica de enrutamiento clara. La dilución ocurre cuando la lógica de enrutamiento no existe y cada motion se improvisa.

"PLG es para productos y Sales-Led para enterprise — es obvio, no se solapan."

El segmento no decide la motion. El uso sí. Hay productos dev-tool con deals enterprise larguísimos, y hay plataformas enterprise con onboarding self-serve impecable. Mide el uso, no el adjetivo del segmento. La etiqueta de segmento es tan poco fiable como la etiqueta de modelo: sigue siendo una identidad congelada aplicada a un mundo que se mueve.

"El 73% es discutible — correlación no es causalidad."

De acuerdo. No uses el titular como veredicto. Usa el mecanismo: decisiones guiadas por peticiones en lugar de uso, y rigidez de identidad que sobrevive a los datos. Eso es lo que mata, y es observable en cualquier SaaS que hayas tocado. No necesitas el titular para validar el mecanismo — basta con mirar tu propio roadmap y ver cuántas features viven en él sin que nadie las toque.

---

La Etiqueta No Te Salva. El Enrutamiento Sí.

El 73% de los SaaS no fracasa por elegir mal entre PLG y Sales-Led. Fracasa por negarse a dejar de serlo.

La falsa dicotomía es el problema. El modelo puro es el modo de fallo. Y la solución no es un tercer modelo con hype: es un sistema de enrutamiento que responde al uso y un trigger que decide cuándo cambiar.

Cuando construyas tu próxima feature, pregunta qué pide el uso, no qué pide el cliente. Cuando elijas tu próxima motion, pregunta qué dicen tus datos de activación, no qué dice tu identidad.

La ventaja competitiva de un SaaS en 2026 no es elegir bien el modelo. Es no enamorarse de él.

Versiona tu modelo como versionas tu código. Un SaaS que se adapta sobrevive. Un SaaS que se casa con su etiqueta, muere con ella. Y la señal para adaptarse no llega desde el board ni desde el gurú de turno: llega desde tu propio producto, desde la telemetría de uso que ya tienes y que decides si escuchar o ignorar.

El 73% de los SaaS No Fracasa por Elegir PLG o Sales-Led: Fracasa por Negarse a Dejar de Serlo