Consejos para fundadores técnicos de startups | Startup School
Los fundadores técnicos pueden confundir fácilmente la excelencia técnica con el progreso de una startup. Una arquitectura refinada, una base de código pulida o un ambicioso plan de infraestructura pueden parecer productivos, pero ninguno demuestra que los clientes necesiten el producto. En esta charla de Startup School, Diana Hu recurre a su trayectoria, desde CTO de una startup de realidad aumentada hasta Directora de Ingeniería en Niantic, junto con lecciones de otros fundadores de Y Combinator, para explicar qué exige realmente el rol.
Su argumento central es que los fundadores técnicos deben optimizar para aprender. Durante la fase de ideación, eso significa crear algo ante lo que los usuarios puedan reaccionar. En la etapa del MVP, significa ofrecer un producto acotado pero funcional y buscar un compromiso real. Tras el lanzamiento, significa combinar analítica con conversaciones directas, mejorar el producto rápidamente y aceptar concesiones técnicas cuando ayuden a la empresa a descubrir un mercado viable.
Un fundador técnico construye la empresa
El cofundador técnico no es simplemente la persona encargada de implementar los planes de otro fundador. Hu describe el rol como una asociación profundamente comprometida en la que el fundador técnico comparte la responsabilidad por el producto, los clientes y la supervivencia de la empresa.
Esa responsabilidad genera una carga de trabajo inusualmente amplia. En una startup temprana, un fundador técnico podría escribir código de aplicación, configurar servicios en la nube, responder mensajes de soporte, solucionar la conectividad de la oficina, entrevistar a usuarios y tomar decisiones de producto en la misma semana. Las descripciones de puestos acotadas pertenecen a organizaciones más grandes; los fundadores trabajan donde se encuentre la incertidumbre más urgente de la empresa.
Por eso, el objetivo adecuado de ingeniería al principio no es la máxima sofisticación técnica. Es la cantidad mínima de tecnología necesaria para generar avance. Los fundadores necesitan suficiente producto para probar la siguiente suposición importante, no un sistema idealizado preparado para cada futuro hipotético.
Crea un prototipo de la idea antes de construir la empresa
En la etapa de ideación, el objetivo inmediato es hacer concreta una propuesta abstracta. Un prototipo da a los usuarios potenciales algo que pueden ver, probar o comentar, y genera comentarios más fiables que una presentación verbal por sí sola.
El prototipo no necesariamente necesita código de producción funcional. Un equipo de software podría usar Figma u otra herramienta de diseño para simular la experiencia. Una startup de hardware podría presentar un renderizado en 3D. Cuando la viabilidad técnica en sí es incierta, una demostración enfocada de la tecnología subyacente puede ser el artefacto más útil.
Hu señala el trabajo inicial de empresas como Optimizely y Azure Reality para ilustrar distintas formas de validación. Un prototipo puede revelar una interacción visual que comunique el valor del producto, o puede demostrar que es posible una técnica difícil de realidad aumentada. Lo importante es que aborde un riesgo significativo.
El fallo habitual es seguir construyendo después de que el prototipo sea lo suficientemente bueno para iniciar una conversación. Los fundadores añaden pantallas, casos límite e infraestructura porque implementar resulta más controlable que mostrar trabajo inacabado a los usuarios. Ese retraso es costoso: aumenta la inversión antes de que el equipo haya aprendido si está resolviendo el problema correcto.
Construye un MVP en torno al compromiso, no a la completitud
Un prototipo ayuda a evaluar una idea; un MVP es un producto utilizable destinado a su lanzamiento. Hu sostiene que, al avanzar hacia esta etapa, los fundadores normalmente deberían pensar en semanas, no en ciclos de desarrollo prolongados.
El propósito del MVP es obtener evidencia más sólida que el interés o los elogios. Idealmente, los usuarios demuestran compromiso al pagar. Según el mercado, otra acción costosa —como invertir tiempo, proporcionar datos operativos o integrar el producto en un flujo de trabajo— también puede ser significativa. La distinción esencial está entre alguien que dice que un concepto suena atractivo y alguien que acepta una concesión real para usarlo.
Los fundadores deben mantenerse cerca de este proceso. Contratar demasiado pronto a un gran equipo de ingeniería puede crear distancia entre quienes toman decisiones y los usuarios, al tiempo que aumenta los costos de coordinación. El equipo inicial de Justin.tv, que finalmente dio origen a Twitch, dividió partes importantes del sistema inicial entre los propios fundadores. Trabajar directamente en el producto les permitió comprender sus limitaciones mientras el negocio aún tomaba forma.
La participación práctica inicial no consiste en demostrar que los fundadores pueden hacerlo todo para siempre. Consiste en conservar un camino corto entre la evidencia de los clientes y las decisiones de producto, cuando cada nueva idea puede alterar la dirección de la empresa.
Acota el producto de forma agresiva
Uno de los principios más útiles de Startup School es hacer cosas que no escalan. A los fundadores técnicos a menudo se les enseña a eliminar el trabajo manual, pero los procesos manuales temporales pueden ser exactamente lo que necesita un producto inicial. Incorporar personalmente a los clientes o realizar una operación entre bastidores puede permitir al equipo lanzar antes de que la automatización esté justificada.
Hu también presenta la idea de una «solución 90/10»: ofrecer una implementación restringida que cubra el caso de uso principal en vez de intentar abarcar todo el espacio del problema. El alcance puede reducirse en varias dimensiones:
Dar soporte a un tipo principal de usuario.
Aceptar únicamente el formato de datos más importante.
Atender una sola ubicación o mercado.
Gestionar el flujo de trabajo dominante mientras se posponen los casos límite.
Sustituir la automatización prematura por un proceso manual.
El producto inicial de DoorDash es un ejemplo memorable. Comenzó con un sitio web básico, herramientas operativas ligeras y un servicio limitado a una pequeña zona geográfica. No se parecía a la plataforma logística madura en la que la empresa se convertiría después, pero era suficiente para probar si los clientes querían el servicio.
Las grandes empresas suelen estar limitadas por sistemas existentes, procesos de revisión y amplias expectativas de los clientes. La ventaja de una startup es su capacidad de definir un problema más pequeño y avanzar rápido. Los fundadores técnicos renuncian a esa ventaja cuando construyen como si ya operaran a escala empresarial.
Elige tecnología para iterar rápido
La selección de la pila tecnológica puede convertirse en un debate de identidad que distrae. Hu recomienda equilibrar los requisitos reales del producto con las habilidades existentes del equipo y, después, elegir la combinación más sencilla que pueda lanzarse y modificarse rápidamente.
La familiaridad tiene valor práctico. Un fundador que utiliza herramientas que conoce bien puede diagnosticar problemas más rápido y dedicar más atención a los usuarios. La tecnología novedosa puede ser apropiada cuando crea una ventaja real para el producto, pero la novedad por sí sola no ayuda a una startup a aprender.
El mismo criterio pragmático se aplica a los servicios de terceros. La autenticación, los pagos, el alojamiento, las comunicaciones y otras capacidades habituales a menudo pueden adquirirse mediante API o frameworks consolidados. Reconstruirlos desde cero consume tiempo sin diferenciar necesariamente el producto.
A veces los fundadores se resisten a los servicios externos por temor a futuras tarifas, limitaciones o trabajo de migración. Esas preocupaciones pueden ser reales, pero deben sopesarse frente al riesgo inmediato de avanzar demasiado despacio. Una empresa con un uso sólido puede contratar ingenieros, sustituir componentes y optimizar la infraestructura. Un producto técnicamente puro sin clientes tiene muchas menos opciones.
Lanza para comenzar el verdadero ciclo de aprendizaje
Lanzar un MVP no es el final del desarrollo de producto. Es el momento en que la empresa obtiene acceso a mejor evidencia y puede empezar a avanzar hacia el ajuste producto-mercado.
Hu recomienda utilizar señales tanto cuantitativas como cualitativas. Un sencillo panel de analítica puede revelar adopción, retención, conversión y los puntos en los que los usuarios abandonan un flujo de trabajo. Las conversaciones y las interacciones de soporte explican motivaciones que los números agregados no pueden captar. Ninguna forma de evidencia es suficiente por sí sola.
La evolución de WePay hacia una oferta orientada a API demuestra cómo el comportamiento observado y los comentarios de los clientes pueden redirigir a una empresa. Los lanzamientos repetidos de Segment muestran otro patrón: las publicaciones frecuentes crean más oportunidades para poner a prueba suposiciones, descubrir demanda y ampliar aquello que funciona.
La implicación es que el lanzamiento no debe tratarse como un único evento ceremonial. Es un ritmo operativo recurrente. Cada lanzamiento genera evidencia; el equipo interpreta esa evidencia y decide qué mejorar, eliminar o probar a continuación.
Gestiona la deuda técnica al servicio del ajuste producto-mercado
Una vez que los clientes usan el producto, los fundadores se enfrentan a demandas contrapuestas. Deben reparar defectos, ofrecer las capacidades solicitadas, mantener el sistema en funcionamiento y abordar los atajos acumulados durante la construcción inicial.
Hu no sostiene que la deuda técnica sea inofensiva. En cambio, la plantea como una concesión. Asumir deuda puede ser racional cuando acelera sustancialmente el aprendizaje o acerca a la empresa al ajuste producto-mercado. El error es permitir que la limpieza de ingeniería se desvincule de las prioridades del negocio, o ignorar problemas de fiabilidad que impiden a los usuarios recibir valor.
Pokémon Go ofrece una ilustración extrema de una demanda que llegó junto con una tensión técnica considerable. Sus problemas de lanzamiento importaron, pero no eliminaron la fuerza de la respuesta subyacente de los usuarios. Para una startup, por lo general esa es una clase de problema mejor que construir un sistema robusto que nadie quiere con urgencia.
La ingeniería también debe colaborar estrechamente con ventas y crecimiento. Los equipos orientados al cliente suelen detectar primero las necesidades emergentes, mientras que los ingenieros entienden qué se puede probar a bajo costo. La colaboración entre ambos puede convertir observaciones del mercado en experimentos enfocados sin importar los pesados procesos de una corporación madura.
Evoluciona de creador principal a líder de ingeniería
El rol del fundador técnico cambia después del ajuste producto-mercado. Antes, el fundador podía implementar personalmente la mayor parte del producto. A medida que crecen el uso y el equipo de ingeniería, el trabajo se amplía para incluir contratación, comunicación, dirección técnica y cultura.
Esta transición reduce el tiempo ininterrumpido de programación. Más personas generan más dependencias, decisiones y vías de comunicación. El fundador debe asegurarse de que los ingenieros comprendan no solo qué construir, sino también cómo la empresa toma decisiones difíciles y qué estándares importan.
Con el tiempo, los fundadores técnicos pueden necesitar elegir entre dos caminos generales. Uno es mantenerse profundamente involucrados como arquitectos, guiando las decisiones técnicas más importantes del sistema. El otro es concentrarse en gestionar personas y construir la organización. La elección adecuada depende de la empresa y de las fortalezas del fundador, pero evitar la decisión puede dejar ambas responsabilidades desatendidas.
La lección más amplia es que el rol debe evolucionar con la empresa. Al principio, la velocidad surge de escribir código y hablar directamente con los usuarios. Más adelante, la velocidad proviene cada vez más de crear un equipo capaz de tomar decisiones acertadas sin canalizar cada detalle a través de un único fundador.
El principio operativo: construir para aprender
A lo largo de la creación de prototipos, el desarrollo del MVP, el lanzamiento y el escalado, Hu vuelve a una prioridad constante: acortar la distancia entre una suposición y evidencia fiable.
Construye el primer prototipo con suficiente rapidez para exponer la idea a los usuarios. Lanza un MVP estrictamente acotado que pueda obtener un compromiso genuino. Selecciona tecnología que permita una iteración rápida, aunque la primera implementación no sea permanente. Después del lanzamiento, interpreta tanto los datos de comportamiento como los comentarios humanos. Acepta deuda técnica deliberada cuando impulse el descubrimiento y, después, abórdala a medida que la fiabilidad y el crecimiento hagan necesario ese trabajo.
Para los fundadores técnicos, la disciplina más difícil puede ser reconocer que el código no es la empresa. La tecnología es el instrumento mediante el cual el equipo prueba un mercado, atiende a los clientes y acumula lo que aprende. Por lo tanto, el mejor sistema inicial no es el diseñado para todos los futuros posibles. Es el que ayuda a la startup a alcanzar su siguiente verdad importante.
