Diseño de tiers: arquitectura de planes que convierte
El número de tiers, las features de cada uno, los nombres, los precios y la forma en que se presentan son decisiones de arquitectura — no de estética. Un tier mal diseñado pierde clientes que habrías convertido con la misma oferta mejor estructurada.
Las 5 preguntas que definen tu estructura de tiers
Ramanujam, en Monetizing Innovation (cap. 4), argumenta que la estructura de tiers no debería diseñarse desde el producto sino desde el mercado: ¿cuántos segmentos diferentes servís? ¿Qué necesita cada uno? ¿Cuánto está dispuesto a pagar? Las respuestas definen la cantidad de tiers, su contenido y su precio — el producto solo provee los materiales.
Cada tier debería tener un segmento claro. Si no podés nombrar quién elige cada uno, tenés tiers de más o tiers sin propósito.
El tier más bajo resuelve el job básico. El medio resuelve el job completo. El alto resuelve el job + necesidades avanzadas. Si los jobs no escalan, los tiers no tienen razón.
Core va en todos. Progresivas van en tier medio+. Avanzadas solo en el alto. La clasificación viene del uso real — no de la intuición del equipo de producto.
Usuarios, proyectos, almacenamiento, transacciones — la unidad que crece cuando el cliente crece. Los límites de cada tier se definen en esta unidad.
El momento en que el cliente siente que necesita más. Los mejores tiers se diseñan para que ese trigger sea consecuencia del éxito — "crecí, necesito más" — no de la restricción artificial.
Simon, en Confessions of the Pricing Man (cap. 6), complementa con un principio operativo: "cada tier adicional incrementa la complejidad operativa — soporte, onboarding, billing, comunicación — por lo que el valor incremental de revenue de cada tier debe justificar esa complejidad." Un cuarto tier que solo captura el 3% de los clientes probablemente no justifica el costo de mantenerlo. La priorización de trade-offs entre granularidad de segmentación y simplicidad operativa es la decisión más práctica del diseño de tiers.
02Clasificar features: core, progresivas y avanzadas
La clasificación de features es la base del packaging. Ramanujam propone hacerla con datos de uso real, no con la intuición del equipo de producto — porque los equipos tienden a sobrevaluar las features que les costaron más construir, no las que el cliente más valora.
Features core: van en todos los tiers
Lo que resuelve el job básico. Sin estas features, el producto no funciona — y un tier sin funcionalidad core se siente roto, no limitado. La prueba: si un usuario nuevo no puede experimentar el valor del producto en 10 minutos sin esta feature, es core. La jerarquía de features debería empezar por definir qué es core — porque todo lo que es core va en el tier más bajo.
Features progresivas: van en tiers medio y alto
Se necesitan a medida que el uso crece: más automatización, más integraciones, más capacidad de reporting. El trigger de upgrade es natural — "necesito más porque crecí" — no artificial. La gestión del lifecycle debería incluir nudges cuando el usuario se acerca a los límites del tier: "ya usaste el 80% de tus proyectos activos" es un trigger de upgrade honesto que conecta la restricción con el éxito del usuario.
Features avanzadas: solo tier alto
SSO, SLA, API avanzada, soporte dedicado, compliance, custom integrations. Solo las necesita el segmento enterprise o power user. Si las ponés en tiers más bajos, diluís la diferenciación del tier alto. Si las cobrás como add-ons en lugar de incluirlas en el tier, generás complejidad de billing pero ganás flexibilidad — cada empresa enterprise tiene necesidades avanzadas diferentes, y los add-ons permiten personalizar sin crear un tier custom para cada una.
Trabajé con un SaaS de analytics que tenía 12 features distribuidas en 3 tiers sin criterio claro. Cuando analizamos los datos de uso, descubrimos que 4 features avanzadas tenían menos del 5% de adopción pero estaban en el tier medio — ocupando espacio visual y confundiendo la decisión. Las movimos al tier alto como exclusivas, simplificamos el medio a 5 features de uso diario y la conversión de pricing page subió un 22%. No cambiamos ni una feature ni un precio — solo reordenamos dónde vivía cada una.
Lisandro IserteProgresión de precio entre tiers
Simon recomienda que el valor percibido incremental de cada tier crezca más rápido que el precio. Si el tier 1 cuesta $29 y el tier 2 cuesta $59 (2x), el tier 2 debería ofrecer al menos 2.5x-3x el valor percibido — más features, más límites, más soporte. Esto hace que el upgrade se sienta como un buen deal — "pago el doble pero recibo el triple". Si el valor crece linealmente con el precio, no hay incentivo para subir de tier porque la "eficiencia" de cada peso es la misma.
Ariely, en Predictably Irrational (cap. 1), demuestra que esta percepción de "buen deal" se refuerza con el efecto señuelo: si el tier medio se diseña como la opción que tiene el mejor ratio valor/precio, el cliente naturalmente gravita hacia ahí — y ese es exactamente el comportamiento que querés. La psicología del precio no se aplica solo al número sino a la relación entre números — y la relación entre tiers es donde el anclaje y el señuelo operan con más fuerza.
Nagle, en The Strategy and Tactics of Pricing (cap. 7), formaliza esto como "price-value mapping": cada tier debería ocupar una posición en el mapa precio/valor que sea atractiva para su segmento y que no canibalice al tier adyacente. Si el tier medio es tan bueno y tan barato que nadie compra el alto, el medio está subpreciado o el alto está sobrevaluado. La elasticidad por tier te dice cuánto margen tenés para mover cada precio sin perder el balance. La experimentación con pricing de tiers — no de todo el GBB sino de un tier específico — produce datos sobre la sensibilidad de cada segmento dentro de la estructura.
04Naming y presentación visual
Los nombres de los tiers comunican posición antes de que el cliente lea las features. "Starter / Growth / Scale" dice más que "Plan 1 / Plan 2 / Plan 3" porque cada nombre contiene una identidad: Starter es para el que empieza, Growth para el que crece, Scale para el que necesita infraestructura. La identidad verbal de los planes debería ser coherente con la marca — si tu marca es técnica, los nombres pueden ser técnicos; si es accesible, los nombres deberían ser simples.
La presentación visual en la pricing page guía la decisión tanto como el contenido. Iyengar demostró que la posición del producto en el estante influye en la elección: el producto del medio se elige más. En pricing pages, el tier recomendado debe estar en el centro, con un badge de "más popular" o "recomendado" y quizás un tamaño o color diferente. La optimización de CRO de pricing pages muestra que estos elementos visuales mejoran la conversión entre un 8% y un 15%. La identidad visual de la pricing page debería reflejar la jerarquía: el tier recomendado visualmente prominente, los otros dos como contexto.
Un error frecuente es mostrar demasiadas features en la tabla comparativa. Iyengar y Schwartz coinciden: más dimensiones de comparación no mejoran la decisión — la dificultan. Las pricing pages más efectivas muestran 5-7 features diferenciadoras entre tiers, no la lista completa de 30. Las features comunes a todos los tiers no necesitan estar en la comparación — son ruido visual que no ayuda a decidir. La simplificación opera en la presentación tanto como en la estructura.
05Errores frecuentes
Diseñar tiers desde el producto en lugar de desde el segmento
"Tenemos 20 features, repartimos 7 en el básico, 15 en el medio y 20 en el premium." Eso es distribución arbitraria, no diseño de tiers. Cada tier debería resolver el job de un segmento específico — y las features que incluye deberían ser las que ese segmento necesita, no un subconjunto aleatorio. La definición de ICP por tier es prerrequisito del diseño, no un paso posterior.
Tier bajo que se siente roto
Si el tier más barato no resuelve el job básico, el cliente no siente "necesito más" sino "esto no sirve" — y se va. El churn alto en el tier bajo es la señal más clara de que el gating es demasiado agresivo. La retención por tier debería monitorearse por separado — un tier con churn del 15% mensual está roto, sin importar qué digan las métricas agregadas.
Saltos de precio sin saltos de valor
El tier medio cuesta 3x más que el bajo pero solo agrega 2 features menores. El cliente no percibe que el delta de precio se justifica con el delta de valor — y se queda en el bajo. La lógica de value-based pricing aplica por tier: el precio de cada uno debería reflejar el valor que entrega a su segmento, no un porcentaje arbitrario sobre el anterior.
No testear la estructura antes de lanzar
La estructura de tiers se definió en una reunión y se lanzó al mercado sin validación. La investigación previa — Van Westendorp para rangos de precio, conjoint para evaluar combinaciones de features/precio — reduce el riesgo de lanzar una estructura que no refleja cómo el cliente percibe el valor. El diagnóstico post-lanzamiento con A/B testing de la pricing page cierra el loop.
Cómo usar la distribución por tier para diagnosticar
Si el 70%+ está en el tier más bajo: el tier medio no ofrece suficiente valor incremental para justificar el salto de precio. Revisá qué features del medio serían un upgrade natural para los usuarios activos del bajo — y si esas features están en el medio o si las gateaste demasiado arriba. La analítica de uso por feature te dice cuáles son las más valoradas y dónde debería estar la línea. La comunicación del valor del tier medio también merece revisión — quizás el valor existe pero no se percibe.
Si el 30%+ está en el tier más alto: probablemente el alto está subpreciado o el medio no tiene suficientes features para retener a los que crecieron. Simon recomienda crear un tier adicional o subir el precio del alto — porque el segmento que elige el tier premium suele tener elasticidad baja y puede absorber una suba sin migrar. La estructura de unit economics del tier alto debería tener el mejor margen de toda la línea — si no lo tiene, algo está mal.
Si la distribución es pareja (33/33/33): puede parecer ideal pero suele indicar que los tiers no están suficientemente diferenciados — cada uno captura un tercio por defecto, no por diseño. La estructura GBB debería producir una distribución asimétrica (15-25% bajo, 50-65% medio, 10-20% alto) porque el tier medio está diseñado para ser la opción preferida. Una distribución pareja sugiere que ningún tier se siente como la opción obvia — y el NPS por tier probablemente confirme la confusión.
La estrategia de go-to-market también depende de la distribución: si el tier alto concentra la mayor parte del revenue, las ventas consultivas merecen más inversión. Si el tier bajo genera volumen pero poco margen, la adquisición orgánica y el growth automatizado son más eficientes que el equipo de ventas. El modelo de negocio se adapta a la estructura de tiers — no al revés.
Preguntas frecuentes sobre diseño de tiers
¿Cuántos tiers necesito?
Tantos como segmentos genuinamente diferentes servís. 1-2 si es homogéneo, 3 si tenés tres perfiles claros. Más de 4 genera parálisis en la mayoría de las categorías.
¿Cómo decido qué features van en qué tier?
Core (resuelve el job básico) va en todos. Progresivas (se necesitan al crecer) van en medio+. Avanzadas (enterprise/power user) van solo arriba. La clasificación viene de datos de uso real.
¿La progresión de precio debe ser lineal?
No. El valor percibido debería crecer más rápido que el precio. Si el tier 2 cuesta 2x, debería ofrecer 2.5-3x el valor. Eso hace que el upgrade se sienta como un buen deal.