Cómo hacer entrevistas de usuario

De qué va esta clase

Emmett Shear fue cofundador de Justin.tv, la plataforma que evolucionó hasta convertirse en Twitch, adquirida por Amazon, donde continuó trabajando como consejero delegado en el momento de dar esta clase. Su trayectoria incluye un primer fracaso relevante -Kiko Calendar- seguido de un pivote decisivo dentro de Justin.tv hacia el streaming de videojuegos, que se transformó en Twitch.

Shear estructura la clase alrededor de una tesis autobiográfica: su primera startup falló, en parte, porque nunca hablaron con nadie que usara calendarios de verdad; su segunda startup, Justin.tv, sobrevivió gracias a que ellos mismos eran el usuario, pero ese atajo tiene un límite claro, porque no permite escalar más allá de la propia experiencia personal; y fue solo al construir Twitch, cuando empezaron a entrevistar de forma sistemática a emisores de contenido de videojuegos, cuando encontraron un motor de decisiones de producto sostenido durante años.

El objetivo de la clase es enseñar, con ejercicios prácticos en directo con el público, cómo elegir a quién entrevistar, cómo formular preguntas que no contaminen la respuesta con tus propias ideas, y cómo convertir esas conversaciones en decisiones de producto reales, en lugar de en una lista de funcionalidades pedidas por los usuarios más ruidosos.

Apuntes

El atajo de ser tu propio usuario, y sus límites

Shear cuenta que en Kiko Calendar -su primera startup con Justin Kan- ni él ni su socio usaban calendarios de forma intensiva, y no hablaron con nadie que sí lo hiciera; el resultado fue que construyeron bien la tecnología pero terminaron vendiendo la empresa en eBay. En su segunda startup, Justin.tv, aplicaron un atajo distinto: construyeron el producto para sí mismos, retransmitiendo la vida de Justin Kan las veinticuatro horas del día. Ser tu propio usuario funciona, pero solo si resulta que representas a un colectivo amplio con las mismas necesidades; la mayoría de las veces, advierte Shear, ese enfoque se queda en un proyecto personal que no escala. Justin.tv encontró cierto éxito porque, en efecto, existía gente que quería retransmitir su vida, pero se quedó atascado porque nadie en el equipo sabía identificar hacia dónde crecer más allá de ese caso de uso inicial, precisamente porque ellos mismos no eran representativos del público más amplio al que querían llegar.

El pivote hacia gaming: la primera vez que entrevistaron en serio

El giro decisivo llegó cuando Shear lideró la iniciativa de gaming dentro de Justin.tv. A diferencia de los proyectos anteriores, ni él ni el equipo sabían nada sobre retransmisión de vídeojuegos, aunque a Shear le entusiasmaba ese contenido como espectador. Esa combinación -pasión por el problema, ignorancia sobre el mercado- los obligó a hacer un número muy alto de entrevistas de usuario, cuyos resultados terminaron formando el núcleo de las decisiones de producto durante los siguientes tres años. Twitch llegó a construir una división entera dedicada a hablar con usuarios, algo que no existía en Justin.tv.

Un hallazgo clave de ese proceso fue identificar que los emisores de contenido, no los espectadores, eran el segmento más importante: la gente sigue el contenido, y el emisor se lleva a su audiencia con él a donde vaya. Shear insiste en que no existe una fórmula única para decidir a quién hay que entrevistar: es una cuestión de criterio y de pensar con rigor a quién estás construyendo el producto realmente.

Elegir a quién entrevistar: el ejercicio de la app de apuntes

Para ilustrar el proceso, Shear plantea al público un ejercicio en directo con una idea ficticia: una aplicación de toma de apuntes en clase. Pide a los asistentes que, antes de pensar en preguntas o funcionalidades, decidan a quién entrevistarían primero. Un voluntario propone estudiantes universitarios, segmentados por carrera, porque la forma de tomar apuntes varía según la disciplina.

Shear valida esa respuesta pero introduce un matiz importante: los estudiantes universitarios apenas gastan dinero, por lo que aunque sean los usuarios directos del producto, quizá no sean quienes realmente decidan pagar por él. Propone ampliar el mapa de personas a entrevistar a los departamentos de informática de las universidades, que son quienes de verdad compran software educativo, y también a los padres de estudiantes de primer año, que sí están dispuestos a invertir en la productividad académica de sus hijos. La lección es que, al principio de una startup, conviene entrevistar al abanico más amplio posible de perfiles relacionados con el problema, no limitarse al usuario final más obvio.

Cómo NO preguntar: evitar el efecto del carruaje sin caballos

Con otro voluntario, Shear simula una entrevista real sobre hábitos de toma de notas. Deliberadamente evita preguntar sobre funcionalidades concretas de las herramientas que la entrevistada usa (Google Docs, Evernote); en su lugar, pregunta cómo toma notas, si las revisa después, por qué usa dos herramientas distintas y qué significa para ella "colaborar" en ese contexto. Cuando la entrevistada menciona que echa en falta más integración entre herramientas, Shear profundiza con "cuéntame más sobre eso" en lugar de preguntar directamente si querría una función concreta de integración.

La razón de este enfoque es lo que Shear llama el efecto del "carruaje sin caballos": si le preguntas a la gente qué quiere, normalmente pedirá una versión mejorada de lo que ya conoce -un caballo más rápido- en lugar de la solución real al problema de fondo -el automóvil-. Por eso el objetivo de la primera ronda de entrevistas no es validar funcionalidades, sino entender problemas y comportamientos reales; las peticiones de funcionalidades concretas, señala, resultan difíciles de ignorar precisamente porque suenan muy reales y convincentes viniendo de una persona real, pero eso no las convierte en la prioridad correcta.

Cuándo detener las entrevistas y cómo generar hipótesis de producto

Shear ofrece una cifra orientativa: tras hablar con unas seis a ocho personas dentro del mismo segmento, es poco probable que sigas descubriendo información sustancialmente nueva. Por eso es clave hablar con extremos distintos de perfiles -no solo estudiantes de Stanford, también estudiantes de instituto o padres-, porque cada segmento revela patrones distintos.

A partir de los patrones detectados en la entrevista simulada, Shear plantea al público generar una posible funcionalidad concreta, y un tercer voluntario propone una especie de "Google Drive" ligero, orientado a notas pequeñas en vez de documentos largos, con una versión móvil menos pesada. Shear valora la propuesta, pero advierte del segundo error habitual: no se debe preguntar directamente a los usuarios si esa funcionalidad concreta les entusiasma, porque casi siempre responderán que sí de forma educada aunque después no cambien de comportamiento cuando el producto exista de verdad.

Validar sin construir el producto completo

Ante la pregunta de Sam Altman sobre cuál es el mínimo esfuerzo necesario para validar una idea sin construir el producto entero, Shear ofrece varias vías según el contexto. La más directa, cuando la funcionalidad es sencilla de programar, es simplemente construirla y lanzarla para ver qué pasa. Cuando construir la versión mínima llevaría meses, recomienda buscar formas de "hacer trampa": por ejemplo, una extensión de navegador que añada la funcionalidad encima de un producto existente como Google Docs, en lugar de reconstruir todo el producto desde cero.

La validación más contundente, según Shear, es el dinero: pedir a la gente que pague por adelantado con su tarjeta de crédito es la prueba definitiva de interés real, mucho más fiable que cualquier respuesta verbal. Resume la idea con una fórmula directa: si alguien no está dispuesto a poner cinco dólares por tu producto, probablemente no está tan entusiasmado como parece.

El caso Twitch: comparar tres grupos de usuarios distintos

Shear repasa con detalle el proceso real que siguieron al lanzar Twitch. Primero entrevistaron a entre doce y catorce emisores existentes de la plataforma de videojuegos de Justin.tv. Estos usuarios pedían funcionalidades muy específicas -poder limpiar la lista de usuarios bloqueados del chat, editar títulos de highlights- que, según Shear, en realidad indicaban problemas menores: si la gente seguía usando el servicio a pesar de esas limitaciones, no eran los problemas que impedían el crecimiento.

El segundo grupo fueron emisores que usaban plataformas de la competencia. Este grupo pedía cosas distintas y de mayor calado: programas de reparto de ingresos, estabilidad de vídeo -el servicio funcionaba mal en Europa- y la posibilidad de emitir desde varias personas a la vez. Shear señala que comparar ambos grupos reveló que lo que preocupaba a quien no usaba el servicio era radicalmente distinto de lo que preocupaba a quien ya lo usaba, y que las quejas del segundo grupo apuntaban a problemas mucho más graves.

El tercer y, según Shear, más importante grupo fueron los no usuarios: personas que nunca habían emitido en ninguna plataforma. Este segmento mencionaba razones estructurales -ordenadores no suficientemente potentes, jugadores profesionales que temían revelar sus estrategias de entrenamiento a rivales, falta de infraestructura en países como Corea-. Atender a este grupo llevó a Twitch a integrar la retransmisión directamente en consolas como Xbox y PlayStation 4, y a trabajar con fabricantes de software de emisión, ampliando el mercado total en lugar de solo pelear cuota con la competencia existente.

La conclusión de Shear es que combinar estos tres grupos no señaló qué funcionalidades construir literalmente, sino qué problemas de fondo resolver: dinero, estabilidad y acceso universal. Cuenta que, al volver más tarde con los mismos entrevistados y mostrarles que Twitch había construido, por ejemplo, un programa de suscripciones para que pudieran monetizar su contenido, esas personas se convirtieron en los primeros usuarios más comprometidos con la plataforma, porque pocas veces habían tenido la experiencia de ver que una empresa realmente escuchaba y actuaba sobre lo que le contaban.

Errores frecuentes al hacer entrevistas, según la ronda de preguntas

En la sesión de preguntas, Shear identifica varios errores comunes. El primero es mostrar el producto propio durante la entrevista, lo que contamina la respuesta del usuario igual que preguntarle directamente por una funcionalidad. El segundo es entrevistar solo a quienes son fáciles de contactar -usuarios ya activos en tu propio foro- en lugar de buscar activamente a quienes de verdad importan, aunque cueste más esfuerzo encontrarlos; cuenta que en Twitch llegaron a pasar semanas identificando y contactando a usuarios objetivo en plataformas sin sistema de mensajería propio.

Sobre el formato, Shear defiende con firmeza las entrevistas por videollamada o en persona frente al correo electrónico, porque solo el formato interactivo permite el "modo detective": cuando alguien menciona algo inesperado, preguntar "cuéntame más" y dejar que el silencio incómodo empuje a la persona a seguir hablando. Recomienda grabar las entrevistas -pidiendo siempre permiso- porque reproducir la grabación ante el resto del equipo convence mucho más que simplemente contarles lo que se escuchó.

Marcos y reglas prácticas

Errores habituales que señala el ponente

• Construir un producto sin hablar nunca con usuarios reales de la categoría, confiando solo en intuición propia.
• Ser tu propio usuario y asumir que representas a un colectivo amplio sin comprobarlo.
• Preguntar directamente si una funcionalidad concreta gusta, en vez de indagar en comportamientos y problemas reales.
• Mostrar el producto o prototipo durante la entrevista, contaminando la respuesta del entrevistado.
• Entrevistar solo a quienes son fáciles de contactar, en lugar de buscar activamente a los segmentos que más importan.
• Hacer entrevistas por correo electrónico en lugar de en formato interactivo, perdiendo la posibilidad de profundizar en tiempo real.
• Dejar de hablar con usuarios nuevos una vez alcanzado cierto éxito inicial, congelando el conocimiento del mercado en el momento del lanzamiento.
• Fijarse solo en usuarios de la competencia y no en los no usuarios, perdiendo de vista cómo ampliar el tamaño total del mercado.

Preguntas para aplicarlo a tu proyecto

• ¿Eres tú mismo el usuario de tu propio producto? Si es así, ¿tienes evidencia de que representas a un colectivo amplio, o es solo tu caso personal?
• ¿Has entrevistado tanto a usuarios de tu competencia como a personas que nunca han probado ningún producto de tu categoría?
• En tus últimas entrevistas de usuario, ¿preguntaste por funcionalidades concretas o por comportamientos y problemas reales?
• ¿Cuántas personas de cada segmento relevante has entrevistado hasta ahora, y has llegado ya al punto de rendimientos decrecientes?
• Si tuvieras que validar tu próxima gran apuesta de producto sin construirla entera, ¿qué versión mínima o "truco" podrías usar para probarla?
• ¿Podrías conseguir que alguien pague por adelantado por tu producto ahora mismo, aunque sea una versión incompleta?
• ¿Sigues entrevistando a usuarios nuevos de forma regular, o dejaste de hacerlo después del primer periodo de éxito?

Citas

• "El error más común es mostrarle a la gente tu producto" (Emmett Shear, sobre los fallos más frecuentes al entrevistar usuarios).
• "Si no estás dispuesto a pagar cinco dólares por algo, probablemente no estás muy entusiasmado con ello" (Emmett Shear, sobre la prueba del dinero como validación).
• "Quien usa tu servicio a pesar de sus problemas te está diciendo que esos no son los problemas más grandes" (paráfrasis del argumento de Shear al comparar usuarios propios y de la competencia).
• "Modo detective es decir: interesante, cuéntame más sobre eso" (Emmett Shear, describiendo la técnica clave de la entrevista en persona).

Recursos y lecturas de esta clase

Material original del curso, en inglés.