- En las discusiones sobre la hoja de ruta del producto, ventas, marketing, I+D y los responsables del negocio hablan del cliente, pero si se pierde de vista el trabajo para el que el cliente contrata el producto (job), los criterios de decisión se vuelven difusos
- Intuit cayó en la persecución de funcionalidades (feature chase) al seguir las 150 solicitudes de funciones surgidas de encuestas, sin una brújula para distinguir cuáles funciones eran realmente importantes
- En el caso de las malteadas, preguntar por sabor, precio o textura no aumentó las ventas, pero al observar la situación de compra se reveló que el job central de los viajeros matutinos era el largo trayecto al trabajo y el hambre
- Incluso la misma malteada compite por la mañana contra bagels, barras de proteína y jugos, y por la tarde contra opciones de snack para un niño, por lo que cambian los criterios de evaluación y los productos competidores
- Para encontrar el Job to be done hay que observar problemas cercanos, la opción de no hacer nada, conductas de rodeo, tareas que la gente intenta evitar y usos anómalos
Por qué las solicitudes de los clientes no pueden ser la brújula de la hoja de ruta
- A las reuniones de hoja de ruta llegan aportes distintos de los clientes según cada área
- Ventas cree conocer las necesidades más urgentes porque habla continuamente con los clientes
- Marketing cree que puede aprovechar la marca existente para crear una nueva versión, un nuevo sabor, un nuevo color o una oferta especial
- I+D se enfoca en las funciones y beneficios derivados de nuevas tecnologías o aplicaciones
- El responsable del negocio quiere lanzamientos que ayuden al P&L antes de fin de año
- Cada enfoque tiene cierta validez, pero puede caer en el sesgo de confirmación, viendo solo la información que respalda su propio punto de vista
- El problema mayor es que ninguno de esos modelos refleja directamente el job del cliente
La persecución de funciones en la que cayó Intuit
- Intuit realizó encuestas amplias para preguntarles a los clientes qué nuevas funciones querían, y los clientes presentaron una larga lista de funciones deseadas
- Según Cook, quien fue CEO de Intuit, los clientes pedían “150 funciones”, y el equipo de desarrollo debatió durante semanas cuáles eran más importantes
- Todos los integrantes del equipo creían que estaban eligiendo lo correcto para el cliente, pero en realidad no tenían criterios de decisión
- Si no se sabe para qué trabajo el cliente quiere “contratar” el producto, es difícil distinguir las funciones correctas, y Cook comparó esa situación con navegar sin brújula
Por qué no aumentaron las ventas de malteadas
- Una cadena de comida rápida convocó a clientes que encajaban con el perfil del consumidor ideal para hacerles preguntas con el fin de vender más malteadas
- Si debían ser más baratas
- Si debían tener más trozos
- Si debían tener más textura para masticar
- Si debían tener un sabor más intenso a chocolate
- Los clientes dijeron qué querían, pero no quedaba claro qué hacer a partir de eso
- La cadena hizo varios intentos siguiendo el feedback de los clientes, pero meses después no hubo cambios en las ventas de la categoría de malteadas
El job de la malteada matutina revelado por la observación
- La pregunta cambió a: “¿Qué trabajo vienen las personas a resolver a este restaurante cuando contratan una malteada?”
- El equipo observó a los clientes en la tienda durante 18 horas al día
- Cuándo compraban malteadas
- Qué ropa llevaban puesta
- Si venían solos
- Si compraban también otra comida
- Si la tomaban en la tienda o se iban en auto
- Antes de las 9 a. m. se vendían muchas malteadas, y los compradores por lo general llegaban solos, compraban solo la malteada y se iban en auto
- El job común de los clientes de la mañana era soportar un trayecto largo y aburrido al trabajo y evitar el hambre a media mañana
- Había alternativas competidoras, pero ninguna era perfecta
- El plátano se come demasiado rápido, y a media mañana vuelve el hambre
- La dona suelta migas y deja los dedos pegajosos, ensuciando la ropa y el volante
- El bagel suele ser seco y poco sabroso, y además implica manejar mientras se le unta queso crema o mermelada
- La malteada, al ser una bebida espesa que se toma durante mucho tiempo con un popote delgado, ayuda a ocupar el tiempo, mantiene la saciedad durante la mañana y entra en el portavasos
Un mismo producto compite de forma distinta según el momento del día
- Las personas contratan una malteada en dos situaciones diferentes del día para jobs distintos
- La malteada de la mañana compite con bagels, barras de proteína y botellas de jugo fresco
- La malteada de la tarde compite con pasar por una tienda de juguetes para el niño o volver temprano a casa para jugar básquetbol
- Aunque sea el mismo producto, si el job cambia, también cambian los productos competidores y los criterios de evaluación
Cinco pistas para encontrar el Job to be done
-
1. Buscar jobs cerca
- Incluso en un mundo centrado en datos, algunas grandes innovaciones parten de una intuición sobre el Job to be done
- Khan Academy empezó cuando Sal Khan quiso ayudar a su prima a aprender matemáticas sin estrés, y había muchas personas que sentían el mismo dolor
-
2. Competir contra la opción de no hacer nada
- Si los consumidores no encuentran una solución que satisfaga su job, pueden elegir no hacer nada
- Las empresas no deberían mirar solo cómo quitarles participación a competidores existentes, sino también dónde está la demanda invisible
- Según Chip Conley, responsable global de hospitalidad y estrategia de Airbnb, el 40% de los “huéspedes” de Airbnb respondió que, si Airbnb no hubiera existido, no habría viajado o se habría quedado con familiares
-
3. Observar conductas de rodeo y conductas compensatorias
- OpenTable surgió de una antigua conducta de rodeo alrededor de las reservas en restaurantes
- Después de coordinar horarios posibles con amigos y llamar al restaurante, si no había lugar, había que volver a contactar a los amigos, buscar otro restaurante y repetir el proceso
- OpenTable resuelve ese job de reserva
-
4. Encontrar lo que la gente no quiere hacer
- Clayton Christensen llamó a esto negative jobs, y los jobs negativos pueden ser buenas oportunidades de innovación
- Rick Krieger, egresado de Harvard Business School, y sus socios fundaron QuickMedx después de esperar horas en urgencias para que le hicieran a su hijo una prueba de faringitis; esto se convirtió en el antecedente de CVS MinuteClinics
- CVS MinuteClinic atiende de inmediato a pacientes sin cita, y enfermeros especializados pueden recetar medicamentos para afecciones comunes como conjuntivitis, infecciones de oído y faringitis
- Como mucha gente no quiere ir al médico si no es estrictamente necesario, MinuteClinic llegó a tener más de 1,000 ubicaciones dentro de farmacias CVS en 33 estados
-
5. Observar usos anómalos
- Si las personas crean por su cuenta conductas de rodeo o compensatorias para terminar un trabajo, puede ser una señal de que ese job es importante y de que la frustración con las soluciones existentes es grande
- Estas situaciones pueden llevar a oportunidades de innovación con alto potencial
Una mejor pregunta
- W. Edwards Deming dijo: “Si no sabes hacer la pregunta correcta, no descubrirás nada”
- La mejor pregunta no es qué quiere el cliente, sino “para qué trabajo contrató ese producto”
1 comentarios
Opiniones de Hacker News
El error clásico en la gestión de producto suele empezar por asumir que los usuarios conocen sus propias necesidades. En realidad eso es poco frecuente, y entender la necesidad real es trabajo del lado de producto.
Hasta que la gente lo use de verdad, no hay evidencia de que lo que estás construyendo sea lo que los usuarios quieren, y tampoco hay que ver lo que el usuario pidió como si fuera automáticamente una necesidad.
Aunque el equipo de ventas diga “si no construimos X, no podremos cerrar el contrato”, puede que después de construir X no haya ninguna diferencia. La causa es que el análisis de ventas estaba equivocado.
En especial con productos nuevos, los usuarios no los piden primero, así que hay que explicarlos y mostrarlos; el ejemplo de “cuando apareció el automóvil, los clientes querían caballos más rápidos” aplica a esto.
Si alguien pide algo, hay que indagar el motivo. Si vas al taller y pides que te cambien el alternador, y simplemente lo cambian, podrías quedar insatisfecho; pero si preguntan “¿por qué hay que cambiarlo?” y resulta que el problema era el solenoide, al arreglarlo se resuelve el objetivo real: poder desplazarte.
Por eso un desarrollador sénior muchas veces muestra mejor criterio de producto que un responsable de producto. Alguien que programó 1 o 2 años, obtuvo una certificación y pasó a un rol de producto difícilmente puede superar la profundidad de un veterano.
Sea cual sea la suposición, si no conversas e investigas, vas a tomar una decisión subóptima.
Estoy totalmente de acuerdo con usar investigación de usuarios para entender el área del problema y el espacio de funcionalidades, pero en la práctica he visto muchas más personas construyendo Segways que inventores de automóviles.
Muchas veces se construye algo con la intuición del fundador o con una investigación de usuarios pésima, y luego se descartan a la ligera las solicitudes de los clientes como si fueran “caballos más rápidos”. No tengo tiempo, energía ni voluntad para adaptarme a flujos de trabajo personalizados agregados bajo la premisa de que yo no conozco mi propio ámbito laboral.
Debe haber una diferencia entre B2C y B2B, pero casi nunca veo esa distinción cuando se aplica este consejo. Sé que no significa ignorar el feedback de los usuarios, pero he visto demasiadas veces que se interpreta así, por lo que hace falta una analogía nueva.
Claro que no hay que tomarlo de forma literal, pero observar el comportamiento suele dar más insights que preguntar a los usuarios qué quieren. Eso sí, hay que diseñar bien el entorno de observación para poder saber qué se quiere aprender.
Por ejemplo: “debería poder caminar dentro de la nave espacial y hacer una caminata espacial para reparar el casco después de un impacto de micrometeoritos”.
Por el contrario, también es común que una empresa o un desarrollador lleve esta lógica demasiado lejos y culpe a los jugadores que no disfrutan su juego, como si ellos estuvieran equivocados.
Como ventas es quien más contacto tiene con los usuarios, el gerente de producto por lo general tiende a seguir lo que dicen.
Cuando das mucho soporte por email, ves con frecuencia casos del problema XY disfrazados de solicitudes de funcionalidades. https://en.m.wikipedia.org/wiki/XY_problem
Alguien pide una funcionalidad y, por lo general, es fácil agregarla, pero primero intento entender el problema de fondo. Muchas veces el cliente no cuenta su problema, sino su solución, y esa solución puede ser un mal enfoque o directamente el enfoque equivocado.
Para agregar una funcionalidad de forma elegante, documentarla y hacer que también sea útil para otros, hay que entender el dolor real que resuelve.
“Encuentra el dolor y elimínalo” también es una técnica de ventas muy poderosa. A veces una funcionalidad se agrega no por el dolor del cliente, sino por el dolor interno del equipo de ventas, y se terminan incorporando cosas que el cliente real no usará solo porque al tomador de decisiones le parecen importantes y se ven bien en una demo.
Esto ocurre especialmente al reemplazar software legacy: siempre hay presión para migrar incluso un montón de cosas inútiles que ya casi seguro no se usan y cuyo costo de construcción supera su valor.
Por ejemplo, hay responsables de negocio que no pueden soltar la generación de reportes que nadie lee realmente.
El artículo es bueno, pero de verdad odio el título. A los clientes hay que preguntarles muchas cosas, pero hay muy pocas que deban aceptarse al pie de la letra.
Implementar tal cual la funcionalidad que pidió el cliente es el camino directo al fracaso; hay que seguir preguntando e investigando más allá de “déjenme hacer X”.
Para ser justos, el artículo en realidad dice básicamente eso, pero estoy cansado de los títulos trillados.
Estoy de acuerdo con las recomendaciones de Christensen y Deming, y también quisiera agregar a Sidney Dekker. En particular, "Field Guide to Human Error" es muy bueno, y creo que sus otros libros también podrían valer la pena.
Una de las mejores formas de validar si una solución es real y si se le puede vender al cliente es preguntar “¿comprarías esto ahora?”. Si la respuesta es “sí, mándame la factura y avancemos con el pedido”, entonces algo quedó validado.
En cambio, si la respuesta es algo como “hmm, quizá, lo hablaré con el comité de compras”, todavía estás tanteando en la oscuridad.
Aunque el producto aún no esté listo y no se pueda llegar a una venta real, como decía Steve Blank, se puede continuar con preguntas como “¿pagarías un millón de dólares ahora?”, “entonces, ¿cuánto pagarías?”, “si te lo damos gratis, ¿lo adoptarías de inmediato?”. Esas respuestas muestran cuál es realmente la posición en la mente del cliente.
https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
Por experiencia, los clientes no saben qué quieren. Por eso hay una razón para que el fundador quiera crear algo que resuelva mejor ese problema
Detesto el consejo de “no construyas antes de validar”. A mí, literalmente, nunca me ha funcionado, y es como hacerse preguntas capciosas mientras uno se dispara en el pie
Hay que tener convicción sobre por qué se hace esto. Si te metes en una industria que no conoces en absoluto, la probabilidad de fracasar es del 99%. Si sabes lo que haces, la probabilidad de éxito debería ser de al menos 60%
Un producto en el que la gente entiende a primera vista que resuelve el problema es fácil de vender. Porque ya pasaste por el mismo problema y decidiste resolverlo
Por eso creo que muchos sitios que priorizan la validación hacen deliberadamente vaga la explicación de la solución
En cierto modo, tú eras el cliente arquetípico
La cita trillada de “si Henry Ford le hubiera preguntado a la gente qué quería, habrían dicho que querían caballos más rápidos” no se volvió trillada por nada. La mayoría de la gente no sabe qué quiere, y por eso a los buenos diseñadores de producto les pagan mucho
Lo que hay que distinguir es la visión de producto de la forma de escuchar feedback
Diseñar un producto nuevo que resuelva problemas de la gente no tiene una fórmula mágica; es una habilidad que mezcla experiencia, intuición, comprensión técnica, observación de alternativas existentes y predicción de cambios técnicos/económicos/sociales
En cambio, escuchar feedback consiste en comprobar si lo diseñado funciona como se pretendía, qué confunde a los usuarios y cuáles son los obstáculos. Aquí son útiles métodos clásicos como la observación de usuarios, las pruebas y las encuestas
Parece fácil, pero no lo es en absoluto. He visto muchos diseñadores que no ceden en sus principios aunque la realidad choque con su ideología, y empresas que inexplicablemente no arreglan bugs que sufren la mayoría de los usuarios y que provocan enojo en foros de soporte y redes sociales
Las dos habilidades son muy distintas, y ya es difícil ser bueno en una; ser bueno en ambas es todavía más difícil. El texto usa a Intuit como ejemplo, pero deja al lector la dinámica de cómo se hace un trabajo realmente excelente en un negocio que mantiene el veneno haciendo lobby ante el gobierno y luego vende el antídoto
Los clientes quieren reducir el dolor de declarar impuestos, pero Intuit hace lobby ante el gobierno para que ese dolor siga siendo intenso
La historia de nuestro producto ha recorrido todo este espectro
Al principio solo nos importaba cómo veían su negocio los bancos que eran nuestros clientes y cómo nuestro producto podía mejorarlo. Acumulábamos ideas rápido sin saber siquiera qué estábamos haciendo y corríamos para satisfacer hasta los caprichos más mínimos de los clientes. Sentíamos que no merecíamos su negocio
A mitad de camino empezaron a aparecer resultados y nos dimos cuenta de que, si construíamos el producto intentando satisfacer a más de 10 clientes, cada uno a su manera, al final no quedaría nada
Ahora nuestro producto se parece más a un paquete de consultoría llave en mano que a un software o una tecnología específicos. Los clientes ahora nos piden guía sobre cómo operar su negocio. Cuando te toca manejar ese autobús, puedes estandarizar la pila de software con mucha más confianza. Últimamente, la palabra “aburrimiento” entró en nuestro vocabulario
Lo interesante de nuestro grupo de clientes es que tienen una fuerte tendencia a moverse en manada. Si logras que unos pocos se muevan en cierta dirección, puedes hacer que el resto los siga casi sin esfuerzo. No creo que sea algo que aplique solo a banqueros aversos al riesgo
Una trampa común que falta en el texto es escuchar a la minoría ruidosa de clientes
Si solo leyeras Hacker News u otras plataformas afines a la tecnología, no sería raro que pensaras que había una enorme demanda por un iPhone de pantalla pequeña y alto rendimiento
En la práctica, las ventas del iPhone mini fueron decepcionantes. Eso significa que la gente que escribe durante mucho tiempo en línea sobre hardware tecnológico no representa a toda la base de clientes del iPhone
Que la proporción haya sido baja no significa que las unidades despachadas hayan sido pocas
Siendo realistas, cualquier empresa que construyas probablemente venderá mucho menos que el iPhone Mini. Entonces, como fueron ventas decepcionantes según los estándares de Apple, ¿deberían despedirte y quebrar? ¿Habría que liquidar a todas las empresas que venden menos de 20 millones de unidades? ¿Las empresas dirigidas a bases de clientes más pequeñas que los envíos del iPhone pequeño no deberían existir y tendrían que ser reemplazadas por productos promedio para personas promedio? ¿También deberían desaparecer el Mac Studio, la pantalla XDR y la MacBook de 15 pulgadas de 4.000 dólares?
Conozco a varias personas muy satisfechas con el iPhone mini, y ahora no tienen a qué actualizarse. Aun así, esto sale más barato
Si la gente supiera resolver sus problemas por sí sola, no pagaría
Para hacer ciertas cosas con una computadora hace falta algo de capacidad técnica, pero la mayoría se puede resolver siguiendo reglas y usando Excel de forma creativa
El valor viene de darles a las personas un framework para resolver problemas, pensar por ellas considerando incluso casos excepcionales que no se les habían ocurrido, y luego compilar ese sistema de reglas en un programa
Curiosamente, preguntarle a los clientes qué no quieren sí funciona en la práctica
Preguntarles qué quieren se parece al diseño por comité. Lo que la gente quiere es una versión a la que se le han quitado algunas cosas de una visión bien ordenada y coherente creada por un solo artista