Cómo empezar, hacer cosas que no escalan y relaciones con la prensa

De qué va esta clase

Esta sesión reúne a tres fundadores en distintas etapas de sus empresas para hablar de los primeros pasos de una startup desde ángulos complementarios. Stanley Tang, cofundador de DoorDash, había sido estudiante de la propia Stanford apenas un año antes de dar esta charla, lo que aporta una perspectiva muy fresca sobre el tránsito de la universidad a levantar una ronda serie A. Walker Williams, fundador de Teespring, una plataforma de comercio electrónico para lanzar productos de merchandising sin riesgo ni inventario propio, había pasado por Y Combinator y en el momento de la charla ya facturaba cientos de millones de dólares con casi 180 empleados. Justin Kan, fundador de Kiko y de Justin.tv (que dio origen a Twitch), cierra la clase con una perspectiva distinta centrada en relaciones públicas y prensa.

La clase aborda tres preguntas prácticas que casi todo fundador se hace al principio: cómo validar una idea sin recursos, por qué está bien (e incluso es deseable) hacer cosas manuales e insostenibles al principio, y cómo conseguir que los medios hablen de tu empresa sin gastar en agencias de comunicación.

El contenido está lleno de anécdotas muy concretas: el origen de DoorDash en una tienda de macarons de Palo Alto, los primeros envíos de camisetas de Teespring a una ONG local, y los mecanismos exactos que usaba Justin Kan para conseguir cobertura en TechCrunch.

Apuntes

Validar la idea con el experimento más simple posible (Stanley Tang, DoorDash)

Tang cuenta que la idea de DoorDash nació de una conversación con Chloe, dueña de una tienda de macarons en Palo Alto, mientras él y su cofundador entrevistaban a pequeños comerciantes para otro proyecto. Chloe les enseñó un grueso cuaderno de pedidos de reparto que tenía que rechazar porque no tenía repartidores propios. Al hablar con entre 150 y 200 comerciantes más, encontraron el mismo problema repetido: la falta de infraestructura de reparto. En vez de construir una solución completa, decidieron probar la hipótesis con el experimento más barato posible: una página web muy simple llamada PaloAltoDelivery.com, con menús en PDF de restaurantes locales encontrados en internet y un número de teléfono personal al final, construida en una tarde.

La validación llegó en forma de una llamada telefónica pidiendo comida tailandesa, que los propios fundadores entregaron en coche sin ningún sistema de reparto detrás. A partir de ahí las llamadas crecieron progresivamente (dos, cinco, siete, diez al día siguiente) sin haber hecho ninguna promoción más allá del boca a boca. Tang subraya que esto ocurrió a pesar de que el usuario tenía que buscar manualmente el menú en PDF y llamar por teléfono, una experiencia de usuario deficiente que, precisamente por soportarse pese a su fricción, demostraba que la necesidad real era muy fuerte.

De esta experiencia extrae tres lecciones que resume al final de su intervención: probar la hipótesis como si fuera un experimento, lanzar rápido (ellos lo hicieron en menos de una hora) y aceptar que está bien hacer cosas que no escalan al principio, porque esa fase es la que permite descubrir si existe de verdad demanda antes de invertir en construir infraestructura tecnológica.

Hacer de todo manualmente para aprender el negocio (Stanley Tang, DoorDash)

Durante los primeros meses, los fundadores de DoorDash hicieron ellos mismos de repartidores (compaginándolo con las clases), de soporte al cliente (atendiendo llamadas durante las conferencias) y de todo el sistema operativo con herramientas improvisadas: Square para cobrar, un Google Doc para llevar los pedidos y Find My Friends de Apple para localizar a los repartidores. Este nivel de artesanía manual llegó a generar un problema inesperado: Square bloqueó temporalmente su cuenta por sospecha de blanqueo de dinero, al detectar muchos cargos pequeños y frecuentes; se resolvió porque uno de los cofundadores, Tony, trabajaba en Square y pudo contactar internamente.

Tang defiende que este trabajo manual no fue solo una solución de emergencia, sino una fuente de aprendizaje directo: conducir les permitió entender el proceso de reparto de primera mano y hablar con clientes y restaurantes; despachar pedidos manualmente les ayudó a diseñar después el algoritmo de asignación de repartidores; y el contacto directo con el soporte al cliente, incluyendo correos personalizados a cada nuevo usuario cada noche, generó un nivel de cercanía que un sistema automatizado no habría dado en esa fase. Cuenta una anécdota que resume bien la mentalidad del equipo: un día tuvieron que elegir entre ir a probar una heladería recién abierta o volver a repartir pedidos porque había un pico de demanda; eligieron repartir, entendiendo que solo si el negocio escalaba podrían permitirse ese tipo de lujos más adelante.

Hacer cosas que no escalan como ventaja competitiva (Walker Williams, Teespring)

Walker Williams retoma el mismo mantra de Y Combinator ("hacer cosas que no escalan") y lo estructura en tres bloques: conseguir los primeros usuarios, convertirlos en embajadores ("champions") y encontrar el ajuste producto-mercado. Sobre los primeros usuarios, insiste en que no existe una bala de plata ni una campaña milagrosa de retorno espectacular; incluso las empresas que desde fuera parecen haber tenido un crecimiento perfecto tuvieron que pelear muchísimo por sus primeros clientes. En Teespring, en 2012, el negocio "no podía tener peor pinta": días de reuniones, diseños gratuitos, revisiones interminables, para vender unas cincuenta camisetas a una ONG local y generar mil dólares de ingresos. Su punto es que en las primeras etapas es normal ser malo vendiendo el producto, porque aún no se conocen los puntos de dolor reales del cliente ni existen casos de éxito que mostrar, y que conseguir esos primeros usuarios exige tiempo personal del fundador, sin esperar ningún retorno económico inmediato por hora invertida.

Sobre convertir usuarios en embajadores, la vía más directa es sorprender con una experiencia memorable, y la manera más sencilla de conseguirlo al principio es simplemente hablar con los usuarios de forma constante. Williams sigue siendo, en el momento de la charla, el destinatario del correo genérico de soporte de Teespring, atiende entre diez y veinte tickets diarios y lee cada mención en redes sociales. Describe tres canales para ese contacto: atender soporte directamente (algo que él y su cofundador Evan hicieron en solitario hasta que la empresa facturaba entre 130.000 y 140.000 dólares al mes), contactar de forma proactiva a los clientes que se dan de baja para entender por qué se van, y vigilar redes sociales y comunidades para intervenir cuando alguien tiene una mala experiencia pública. Su regla es contundente: un solo detractor con una mala experiencia puede anular el efecto positivo de diez embajadores satisfechos, así que siempre conviene "hacerlo bien" aunque cueste más, incluso cuando el instinto inicial es minimizar el error.

Priorizar velocidad sobre escalabilidad técnica (Walker Williams, Teespring)

Sobre el ajuste producto-mercado, Williams defiende que el producto con el que lanzas casi nunca es el producto con el que vas a escalar, así que conviene iterar lo más rápido posible aunque eso implique acumular deuda técnica. Cuenta el caso de un cliente corporativo grande que pedía funciones que su plataforma no tenía: construirlas de forma correcta habría llevado un mes, un plazo inasumible en el ritmo de una startup, así que su cofundador Evan directamente duplicó la base de código y la base de datos para crear un producto paralelo específico para ese cliente en solo tres o cuatro días, integrando después en el producto principal solo las funciones que resultaron ser realmente valiosas. Su regla práctica es preocuparse solo por el siguiente orden de magnitud de usuarios (con diez usuarios, pensar en cómo llegar a cien, no en cómo llegar a un millón), y acepta con naturalidad los costes de esa velocidad: cuenta que hubo meses en los que el servidor de Teespring se caía todas las noches y todo el equipo dormía con el móvil en modo silencioso bajo la almohada para poder reiniciarlo. Su conclusión es que no existe un momento mágico (ni la serie A ni un hito de ingresos) en el que haya que dejar de hacer cosas que no escalan: es una ventaja que hay que aprovechar mientras siga siendo neta positiva, y que los competidores más pequeños seguirán explotando si tú la abandonas antes de tiempo.

Objetivos claros antes de buscar prensa (Justin Kan)

Justin Kan cierra la clase con un tema distinto: cómo conseguir cobertura de prensa. Su primer punto es que aparecer en los medios no es un fin en sí mismo, sino que debe estar subordinado a un objetivo de negocio concreto. Con Socialcam, el objetivo era posicionarse como "el Instagram de vídeo" ante inversores e influenciadores de Silicon Valley, así que buscaron prensa tecnológica especializada; con Exec, un servicio de limpieza local en San Francisco, el objetivo era captar clientes reales, así que la prensa nacional no servía de nada y se centraron en medios locales como el SF Chronicle; con Twitch, el objetivo era ser reconocidos dentro de la industria del videojuego, así que apuntaron a publicaciones especializadas del sector en vez de a medios generalistas.

Kan enumera los tipos de historia que suelen funcionar: lanzamientos de producto, rondas de financiación (que la prensa cubre casi siempre aunque no sean noticias muy interesantes), hitos de métricas, historias de negocio para empresas ya consolidadas, "stunts" o acciones publicitarias llamativas (cita el caso de WePay, que congeló dinero en un bloque de hielo frente a una conferencia de desarrolladores de PayPal en protesta por el bloqueo de cuentas de PayPal), anuncios de contrataciones relevantes y artículos de opinión firmados. Su criterio para valorar si una historia merece pitch es preguntarse honestamente si, sin ser el fundador, uno querría leer esa noticia; y recuerda que la historia no tiene que ser completamente original, solo "suficientemente original" en el contexto de lo que ya se ha publicado antes.

Cómo conseguir la introducción y preparar el pitch (Justin Kan)

Sobre la mecánica concreta, Kan la compara con un embudo de ventas: hay que aceptar que no todos los periodistas contactados van a escribir la historia. El paso más importante es conseguir una introducción personal a un periodista, idealmente a través de otro fundador al que ese periodista ya haya cubierto antes, porque desde la perspectiva del periodista esa introducción llega ya validada por alguien en quien confía. Recomienda dar tiempo de sobra (una semana o más de antelación) y buscar siempre una reunión en persona o, en su defecto, una llamada telefónica, evitando limitarse a un intercambio de correos que es fácil de ignorar.

Para el propio pitch, su método es escribir de antemano, en formato de puntos, la historia ideal que le gustaría ver publicada y memorizarla, de forma que la conversación siga esa estructura mientras el periodista toma notas que después convertirá en artículo. Tras la reunión, recomienda un seguimiento por correo unos días antes de la publicación con toda la información de apoyo (fecha exacta, material gráfico, cómo se escriben los nombres) resaltada para minimizar errores. Sobre las agencias de relaciones públicas, su valoración es escéptica: pueden ayudar con contactos y logística, pero no pueden decirte qué es interesante de tu propia empresa, y su coste (entre 5.000 y 20.000 dólares mensuales según su experiencia) rara vez se justifica en fases tempranas. También advierte de que la cobertura de prensa es una métrica de vanidad: da sensación de éxito, pero no equivale a ingresos, usuarios ni satisfacción real de clientes, y no es una estrategia de adquisición escalable a largo plazo porque los medios se cansan de cubrir a la misma empresa de forma repetida.

Marcos y reglas prácticas

Errores habituales que señala el ponente

• Construir infraestructura tecnológica completa antes de validar si existe demanda real para la idea.
• Dar por hecho que el silencio o la falta de tracción inicial significa que la idea no vale, en vez de probarla con el experimento más simple posible.
• Regalar el producto para conseguir usuarios iniciales, generando una falsa sensación de tracción que no se traduce en clientes de pago.
• Delegar el soporte al cliente demasiado pronto en vez de usarlo como fuente directa de aprendizaje sobre el producto.
• Minimizar los errores graves con el cliente en vez de asumirlos por completo y corregirlos, aunque salga más caro a corto plazo.
• Construir la versión perfecta y escalable de una función cuando la startup no puede permitirse el tiempo que eso exige.
• Buscar cobertura de prensa sin un objetivo de negocio claro, o esperar que una agencia de comunicación defina qué es interesante de tu empresa.
• Contactar a un periodista en frío y sin margen de tiempo, esperando cobertura inmediata sin relación previa.

Preguntas para aplicarlo a tu proyecto

• ¿Cuál es el experimento más barato y rápido que podrías montar hoy para validar tu siguiente hipótesis de negocio?
• ¿Qué tareas manuales e insostenibles estás evitando hacer tú mismo que en realidad te darían el aprendizaje más directo sobre tus usuarios?
• ¿En qué orden de magnitud de usuarios estás ahora mismo, y cuál es el siguiente escalón realista en el que deberías concentrarte?
• ¿Tienes identificado a algún detractor reciente cuya mala experiencia podría estar anulando el efecto de tus mejores usuarios embajadores?
• ¿Qué canales usas hoy para hablar directamente con usuarios que se dan de baja, más allá de una encuesta automática?
• Si buscaras cobertura de prensa mañana, ¿tienes un objetivo de negocio concreto detrás, o solo quieres "salir en las noticias"?
• ¿A qué fundador o periodista conoces que podría hacerte una introducción personal en vez de contactar en frío?

Citas

• "It's okay to do things that don't scale" (está bien hacer cosas que no escalan), resumen de Stanley Tang sobre los primeros meses de DoorDash.
• "Those first users are always going to be the hardest" (esos primeros usuarios siempre van a ser los más difíciles de conseguir), Walker Williams sobre Teespring.
• "One detractor who's had a terrible experience in your platform is enough to reverse the progress of 10 champions" (un detractor con una mala experiencia basta para anular el progreso de diez embajadores).
• "Getting press is like a vanity metric" (conseguir prensa es una métrica de vanidad), Justin Kan advirtiendo de no confundir cobertura mediática con éxito real.

Recursos y lecturas de esta clase

Material original del curso, en inglés.