Módulo 3: Target And Positioning

El job, no la demografía

Siguiente →

Descripción

Hasta ahora definiste segmentos por sus pesos de importancia —explorers valora curatedDiscovery, exactSkuShoppers valora price y deliverySpeed— sin preguntar de dónde salen esos pesos. Esta lección responde esa pregunta con el marco de Clayton Christensen: un segmento no se define por quién es la persona (edad, ingreso, ciudad), sino por el job que está tratando de resolver en el momento de comprar. La frase que Christensen hizo célebre es literal: la gente no compra productos, contrata productos para que le hagan un trabajo. Si el producto hace bien el trabajo, lo "vuelve a contratar" la próxima vez. Si no, lo "despide" y contrata a otro.

Esto no es un cambio cosmético de vocabulario — cambia por completo qué preguntas tienen sentido hacer. "¿Quién es nuestro cliente?" invita a describir edad, género, ingreso, ciudad. "¿Qué job están tratando de resolver?" invita a describir una situación y una intención — y, como vas a ver ejecutado en esta lección, la misma persona, exactamente la misma persona, puede tener jobs completamente distintos según el momento, con pesos de importancia opuestos entre sí.

Conexión con el módulo. Las lecciones 2 y 3 te dieron la mecánica de positionFit con segmentos ya definidos. Esta lección explica de dónde deberían salir esos pesos: no de una ficha demográfica, sino del job específico que la persona trae en ese momento de compra. Vas a correr positionFit con dos jobs —no dos tipos de persona— y vas a ver que el mismo comprador, con el job equivocado en la cabeza del equipo de producto, produce el mismo tipo de derrota estructural que ya viste con exactSkuShoppers.

Una analogía cotidiana: el batido de Christensen

Christensen cuenta un caso real que se volvió el ejemplo más citado de todo el marco de JTBD: una cadena de comida rápida quería vender más batidos (milkshakes) y contrató investigadores para perfilar a "el comprador típico de batidos" — edad, ingreso, si tenía hijos. Con ese perfil, probaron variaciones del producto (más espeso, menos dulce, con trocitos de fruta) y ninguna movió las ventas de forma consistente.

Entonces cambiaron la pregunta: en vez de preguntar quién compraba batidos, se sentaron a observar cuándo los compraban y qué job estaban resolviendo en ese momento. Encontraron dos jobs completamente distintos, comprados por el mismo tipo de persona en momentos distintos del día. En la mañana, alguien manejando solo hacia el trabajo "contrataba" un batido para un job muy específico: algo que llenara, que se pudiera tomar con una mano en un trayecto largo y aburrido, sin ensuciar el auto — el batido competía contra un bagel, un plátano, o nada. Por la tarde, un padre con sus hijos "contrataba" el mismo batido para un job distinto: un premio rápido y sin culpa que consintiera al niño sin comerse la tarde entera — ahí el batido competía contra un helado o un juguete de la caja feliz. La misma persona, la misma tienda, el mismo producto — pero dos jobs, con prioridades opuestas, en dos momentos del mismo día. Ninguna variación de "más espeso" o "con fruta" iba a mover las dos ocasiones a la vez, porque no eran el mismo comprador resolviendo el mismo problema — eran dos problemas distintos que casualmente compartían el mismo empaque.

Ejemplo trabajado: dos jobs, el mismo tipo de comprador, veredictos opuestos

Definimos dos jobs para Mercado, no dos perfiles demográficos: giftDiscoveryJob ("necesito encontrar algo especial para alguien, sin saber exactamente qué") y restockJob ("necesito reponer algo específico que ya sé que uso, lo más rápido y barato posible"). La misma persona —imagina a alguien preparando un cumpleaños esta semana— podría traer cualquiera de los dos jobs a Mercado en momentos distintos del mismo mes.

function positionFit(target, product, alternatives) {
  const dims = Object.keys(target.weights).filter((d) => target.weights[d] > 0);
  const weightedScore = (c) => dims.reduce((sum, d) => sum + target.weights[d] * c.scores[d], 0);
  const productScore = weightedScore(product);
  const rivals = alternatives.map((a) => ({ name: a.name, score: weightedScore(a) }));
  const bestRival = rivals.reduce((a, b) => (b.score > a.score ? b : a));
  const byDimension = dims.map((d) => {
    const rivalBest = alternatives.reduce(
      (best, a) => (a.scores[d] > best.score ? { name: a.name, score: a.scores[d] } : best),
      { name: alternatives[0].name, score: -Infinity }
    );
    return { dimension: d, weight: target.weights[d], productScore: product.scores[d], bestRivalScore: rivalBest.score, bestRivalName: rivalBest.name, wins: product.scores[d] > rivalBest.score };
  });
  return { segment: target.name, productWeightedScore: Number(productScore.toFixed(2)), bestRival: bestRival.name, bestRivalWeightedScore: Number(bestRival.score.toFixed(2)), fitsSegment: productScore > bestRival.score, byDimension };
}

const mercado = { name: 'Mercado', scores: { curatedDiscovery: 9, sellerTrust: 8, catalogBreadth: 6, price: 5, deliverySpeed: 5, convenience: 6 } };
const genericMegastore = { name: 'genericMegastore', scores: { curatedDiscovery: 3, sellerTrust: 4, catalogBreadth: 9, price: 8, deliverySpeed: 9, convenience: 8 } };
const localShop = { name: 'localShop', scores: { curatedDiscovery: 6, sellerTrust: 9, catalogBreadth: 2, price: 4, deliverySpeed: 3, convenience: 3 } };
const alternatives = [genericMegastore, localShop];

// El job, no la persona: "necesito encontrar algo especial, sin saber que exactamente".
const giftDiscoveryJob = { name: 'giftDiscoveryJob', weights: { curatedDiscovery: 0.45, sellerTrust: 0.35, catalogBreadth: 0.05, price: 0.05, deliverySpeed: 0.05, convenience: 0.05 } };
// El mismo tipo de comprador, un job distinto: "necesito reponer ESTO, ya, barato".
const restockJob = { name: 'restockJob', weights: { curatedDiscovery: 0, sellerTrust: 0.05, catalogBreadth: 0.1, price: 0.3, deliverySpeed: 0.4, convenience: 0.15 } };

console.log('=== positionFit: giftDiscoveryJob ===\n');
const r1 = positionFit(giftDiscoveryJob, mercado, alternatives);
console.log(`segment: ${r1.segment} | productWeightedScore: ${r1.productWeightedScore} | bestRival: ${r1.bestRival} (${r1.bestRivalWeightedScore}) | fitsSegment: ${r1.fitsSegment}\n`);
console.table(r1.byDimension.map((d) => ({ dimension: d.dimension, weight: d.weight, product: d.productScore, bestRival: `${d.bestRivalName}:${d.bestRivalScore}`, wins: d.wins })));

console.log('\n=== positionFit: restockJob ===\n');
const r2 = positionFit(restockJob, mercado, alternatives);
console.log(`segment: ${r2.segment} | productWeightedScore: ${r2.productWeightedScore} | bestRival: ${r2.bestRival} (${r2.bestRivalWeightedScore}) | fitsSegment: ${r2.fitsSegment}\n`);
console.table(r2.byDimension.map((d) => ({ dimension: d.dimension, weight: d.weight, product: d.productScore, bestRival: `${d.bestRivalName}:${d.bestRivalScore}`, wins: d.wins })));

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

=== positionFit: giftDiscoveryJob ===

segment: giftDiscoveryJob | productWeightedScore: 7.95 | bestRival: localShop (6.45) | fitsSegment: true

┌─────────┬────────────────────┬────────┬─────────┬──────────────────────┬───────┐
│ (index) │     dimension      │ weight │ product │      bestRival       │ wins  │
├─────────┼────────────────────┼────────┼─────────┼──────────────────────┼───────┤
│    0    │ 'curatedDiscovery' │  0.45  │    9    │    'localShop:6'     │ true  │
│    1    │   'sellerTrust'    │  0.35  │    8    │    'localShop:9'     │ false │
│    2    │  'catalogBreadth'  │  0.05  │    6    │ 'genericMegastore:9' │ false │
│    3    │      'price'       │  0.05  │    5    │ 'genericMegastore:8' │ false │
│    4    │  'deliverySpeed'   │  0.05  │    5    │ 'genericMegastore:9' │ false │
│    5    │   'convenience'    │  0.05  │    6    │ 'genericMegastore:8' │ false │
└─────────┴────────────────────┴────────┴─────────┴──────────────────────┴───────┘

=== positionFit: restockJob ===

segment: restockJob | productWeightedScore: 5.4 | bestRival: genericMegastore (8.3) | fitsSegment: false

┌─────────┬──────────────────┬────────┬─────────┬──────────────────────┬───────┐
│ (index) │    dimension     │ weight │ product │      bestRival       │ wins  │
├─────────┼──────────────────┼────────┼─────────┼──────────────────────┼───────┤
│    0    │  'sellerTrust'   │  0.05  │    8    │    'localShop:9'     │ false │
│    1    │ 'catalogBreadth' │  0.1   │    6    │ 'genericMegastore:9' │ false │
│    2    │     'price'      │  0.3   │    5    │ 'genericMegastore:8' │ false │
│    3    │ 'deliverySpeed'  │  0.4   │    5    │ 'genericMegastore:9' │ false │
│    4    │  'convenience'   │  0.15  │    6    │ 'genericMegastore:8' │ false │
└─────────┴──────────────────┴────────┴─────────┴──────────────────────┴───────┘

Fíjate en algo que la lección 2 no podía mostrarte todavía: giftDiscoveryJob gana con un margen todavía mayor que explorers (7.95 contra 6.45, margen de 1.5) — es, en los hechos, casi el mismo segmento que explorers, solo que ahora nombrado por el job en vez de por una etiqueta genérica. Eso no es coincidencia: explorers siempre fue, sin decirlo con esas palabras, gente con el job "ayúdame a descubrir algo que no sabía que quería" — nombrarlo como job en vez de como tipo de persona no cambia el resultado, lo hace más preciso y más fácil de defender frente a alguien que pregunte "¿por qué esos pesos y no otros?".

Y restockJob reproduce, casi número por número, la derrota de exactSkuShoppers: 5.4 contra 8.3 del megastore genérico, perdiendo las cinco dimensiones que le importan. La diferencia crucial con la lección 2 es esta: restockJob no es necesariamente "otro tipo de persona" — podría ser la misma persona que trajo giftDiscoveryJob la semana pasada, ahora con un job distinto en la cabeza (se le acabó el detergente, necesita reponerlo ya). Si el equipo de Mercado piensa "ya conquistamos a este usuario, siempre nos va a preferir", se equivoca de la misma forma que la cadena de batidos se equivocaba preguntando "¿quién compra batidos?" en vez de "¿qué job trae esta persona ahora mismo?".

Profundización: un job tiene tres dimensiones, no una

Christensen y sus colegas describen un job completo como algo más que una tarea funcional — tiene tres capas, y las tres importan para definir los pesos de un segmento con precisión:

  1. Funcional: qué tarea concreta se necesita resolver. Para giftDiscoveryJob: "encontrar un objeto específico que le guste a alguien más".
  2. Emocional: cómo quiere sentirse la persona mientras lo resuelve, o después de resolverlo. Para giftDiscoveryJob: quiere sentirse ingeniosa, no apurada — parte de por qué deliverySpeed pesa tan poco (0.05) en este job: la velocidad no es el punto, la sorpresa lo es.
  3. Social: cómo quiere ser percibida por otros al resolverlo. Para giftDiscoveryJob: quiere que el regalo diga "pensé en ti específicamente", no "compré lo primero que apareció" — otra razón por la que sellerTrust (la curaduría humana detrás del vendedor) pesa tanto (0.35).

restockJob casi no tiene componente emocional o social — es, casi puramente, funcional: reponer algo lo más rápido y barato posible, sin ninguna narrativa alrededor. Esa diferencia de composición —no solo la urgencia— es lo que separa un job de otro, y es la razón por la que sus pesos terminan tan distintos entre sí.

Errores comunes

Confundir el segmento demográfico con el job. Qué pasa: el equipo describe el segmento objetivo como "mujeres urbanas de 28 a 40 años con ingreso medio-alto" y usa esa descripción, tal cual, como si fuera suficiente para decidir qué dimensiones priorizar en el producto. Por qué pasa: los datos demográficos son fáciles de conseguir (encuestas, analítica, datos de pago) y se sienten "objetivos" y medibles, mientras que nombrar un job exige una interpretación más difícil de defender con una sola cifra. Cómo detectarlo: pregunta si la descripción del segmento explica qué está tratando de lograr la persona, o solo quién es. "Mujeres de 28 a 40" no distingue entre alguien con giftDiscoveryJob y la misma persona, un día distinto, con restockJob — y sin embargo, como viste ejecutado, esos dos jobs necesitan un producto casi opuesto para ganar. Cómo corregirlo: por cada segmento demográfico que definas, pregunta "¿qué job específico trae esta persona a Mercado en el momento de la compra?" — y define los pesos de positionFit por ese job, no por la ficha demográfica.

Asumir que el mismo comprador siempre trae el mismo job. Qué pasa: el equipo de producto, una vez que "conquista" a un tipo de usuario, asume que ese usuario va a preferir Mercado en cualquier ocasión de compra futura, sin distinguir entre los distintos jobs que esa misma persona podría traer en momentos distintos. Por qué pasa: es más simple pensar en "usuarios ganados" como una categoría fija que en "ocasiones de job" que cambian según el contexto — el batido de Christensen es exactamente este error, corregido. Cómo detectarlo: si tu análisis de retención agrupa todas las compras de un usuario como si fueran el mismo tipo de decisión, sin distinguir el job de cada ocasión, probablemente estás repitiendo el error de "el comprador típico de batidos". Cómo corregirlo: segmenta las ocasiones de compra por job, no solo a los usuarios por perfil — la misma persona con giftDiscoveryJob esta semana y restockJob la próxima necesita, en cada ocasión, que Mercado le sirva bien el job de ese momento, no un perfil fijo calculado una sola vez.

Definir el job tan amplio que cualquier producto lo resolvería igual de bien. Qué pasa: el job se escribe como "quiero comprar cosas buenas" o "quiero una buena experiencia de compra" — sonando específico, pero sin traducirse en pesos que distingan un producto de otro. Por qué pasa: un job vago es más fácil de escribir en una sola frase inspiradora, igual que una visión vacía (módulo 2, lección 6) es más fácil de redactar que una con filo real. Cómo detectarlo: si al traducir el job a pesos de positionFit, terminas con un reparto parejo entre las seis dimensiones (el mismo problema de allShoppersAverage en la lección 3), tu "job" en realidad no distinguía nada — era una aspiración genérica con otro nombre. Cómo corregirlo: un job bien definido siempre deja algunas dimensiones con peso cero o casi cero — como curatedDiscovery en restockJob, que literalmente no le importa a ese comprador en ese momento. Si tu job no descarta ninguna dimensión, todavía no es específico.

Ejercicios

Ejercicio 1 — Nombra el job antes de calcular los pesos. Para cada situación, escribe en una frase el job (siguiendo el patrón "necesito [tarea], para sentirme/ser percibido como [emocional/social]"), y predice si sus pesos se parecerían más a giftDiscoveryJob o a restockJob:

  • (a) Alguien se quedó sin papel higiénico esta mañana.
  • (b) Alguien quiere sorprender a su pareja en su aniversario con algo que nunca hubiera imaginado.
Ver solución
  • (a) Job: "necesito reponer papel higiénico hoy mismo, al precio más razonable, sin pensarlo demasiado." Se parece a restockJob — funcional, urgente, sin componente emocional o social significativo. deliverySpeed y price pesarían más que curatedDiscovery.
  • (b) Job: "necesito encontrar algo que mi pareja nunca esperaría, para sentirme creativo/a y que perciba cuánto la conozco." Se parece a giftDiscoveryJob — el componente emocional (sentirse ingenioso) y social (ser percibido como alguien que presta atención) domina sobre la velocidad o el precio. curatedDiscovery y sellerTrust pesarían más.

Ejercicio 2 — El mismo comprador, dos jobs, misma semana. Explica, en 2-3 frases, por qué sería un error que el equipo de Mercado tratara a la persona del ejercicio 1(b) —alguien que acaba de tener una gran experiencia de descubrimiento de regalo— como "un usuario que ya prefiere Mercado", y le recomendara la plataforma automáticamente la próxima vez que esa misma persona necesite reponer papel higiénico.

Ver solución

Sería el mismo error del batido de Christensen: tratar a la persona, y no al job, como la unidad de análisis. Si esa misma persona vuelve con restockJob (reponer algo urgente y barato), positionFit ya mostró que Mercado pierde ese job con claridad frente al megastore genérico (5.4 contra 8.3) — el hecho de que Mercado le haya ganado un job distinto la semana anterior no cambia el resultado de este job nuevo. Recomendar Mercado sin distinguir el job actual del comprador arriesga una mala experiencia (comprar algo urgente en una plataforma optimizada para explorar) que podría dañar la confianza ganada en la ocasión anterior, en vez de reforzarla.

Ejercicio 3 — Traduce un job a pesos, defendiendo cada número. Define los pesos de un nuevo job: "necesito equipar rápido la primera bicicleta de mi hijo antes de su cumpleaños este fin de semana, sin gastar de más, pero confiando en que el vendedor sepa de bicicletas de niños." Para cada una de las seis dimensiones, justifica en una frase por qué le darías un peso alto, medio o bajo.

Ver solución

Un reparto razonable: { curatedDiscovery: 0.05, sellerTrust: 0.25, catalogBreadth: 0.1, price: 0.2, deliverySpeed: 0.35, convenience: 0.05 }. Justificación: deliverySpeed alto (0.35) porque hay una fecha límite dura, el cumpleaños. sellerTrust alto (0.25) porque el job pide confiar en que el vendedor sepa de bicicletas de niños específicamente, no cualquier vendedor. price medio (0.2) porque "sin gastar de más" importa, pero no es lo dominante. curatedDiscovery bajo (0.05) porque no está explorando qué regalar — ya sabe exactamente qué necesita (una bicicleta), solo necesita encontrarla a tiempo. catalogBreadth y convenience bajos, secundarios frente a la urgencia y la confianza. El ejercicio importa porque muestra que un job "urgente" (deliverySpeed alto) no es automáticamente idéntico a restockJob — este todavía conserva un componente de confianza (sellerTrust) que restockJob no tenía, porque el job en sí es distinto, aunque comparta la urgencia.

Resumen y siguiente paso

Un segmento bien definido no describe quién es la persona — describe qué job está tratando de resolver, con sus tres capas (funcional, emocional, social). Viste, ejecutado, que nombrar el segmento por el job (giftDiscoveryJob) no cambia el mecanismo de positionFit, pero sí lo hace más preciso y más defendible que una etiqueta genérica — y que el mismo tipo de comprador, con un job distinto (restockJob), puede perder con la misma claridad estructural que ya viste en la lección 2. La lección del batido de Christensen queda confirmada con números: la unidad correcta de segmentación es la ocasión y el job, no la ficha demográfica de la persona.

Antes de avanzar deberías poder: describir cualquier segmento como un job de tres capas, no como una demografía; y explicar por qué la misma persona puede necesitar productos completamente distintos según el job que trae en un momento específico.

Con el segmento y el job ya definidos con precisión, la lección 5 da el siguiente paso: ¿qué significa, exactamente, "posicionarse" para ese job? No es solo ganar el positionFit — es ocupar, en la mente de ese comprador, una categoría específica y reconocible, en vez de competir en todo a la vez.

Recursos

  • Clayton M. Christensen y Taddy Hall, "Know Your Customers' Jobs to Be Done" — hbr.org/2016/09/know-your-customers-jobs-to-be-done. La fuente del marco completo de esta lección, incluyendo el caso del batido en su forma original. En inglés.
  • Harvard Business School Online, "Clay Christensen's Milkshake Marketing" — library.hbs.edu/working-knowledge/clay-christensens-milkshake-marketing. Una explicación más extendida del caso del batido, con el detalle de las dos ocasiones de compra distintas. En inglés.
  • April Dunford, Obviously Awesome — aprildunford.com/books. Dunford construye su propio proceso de posicionamiento sobre la misma idea: empezar por el problema que el cliente resuelve, no por el perfil del cliente. En inglés.
  • Geoffrey Moore, Crossing the Chasm — geoffreyamoore.com/book/crossing-the-chasm. El beachhead de la lección 3 se elige, en la práctica, por un job compartido dentro de un segmento — no por una lista de atributos demográficos. En inglés.
← AnteriorEl beachhead: angosto antes que amplioSiguiente →Qué ES el posicionamiento