Curiosidad genuina y prototipado rápido: dos hábitos que transforman equipos
La curiosidad genuina y el prototipado rápido son dos hábitos que comparten una raíz común: requieren soltar el ego y estar dispuesto a descubrir algo que no esperabas. En un fragmento reciente de TED Talks publicado en octubre de 2026, dos conductores de podcast compartieron dos ideas simples pero poderosas que, aplicadas al mundo empresarial y tecnológico, cambian la manera en que tomamos decisiones y nos comunicamos con otros.
El problema que describe el video es cotidiano: cuando hacemos preguntas, solemos pensar en nosotros mismos. ¿Cómo sueno? ¿Qué dice esto de mí? ¿Estoy siendo interesante? Esa trampa mental no solo arruina conversaciones, también arruina proyectos enteros. Y la solución que proponen es sorprendentemente sencilla: cambia el foco. Piensa en el otro. Piensa en lo que realmente necesita saber tu audiencia.
En este artículo vamos a explorar cómo estas dos ideas —escucha centrada en el otro y prototipado antes del compromiso— aplican directamente a equipos de tecnología, gerentes de empresas medianas y líderes que toman decisiones de transformación digital en Perú y América Latina.
¿Por qué las mejores preguntas no son sobre ti?
En el fragmento de TED Talks, uno de los conductores lo dice sin rodeos: "It's not about you." No se trata de sonar inteligente, de hacer una especie de publicidad del invitado, ni de demostrar cuánto sabes del tema. Se trata de preguntarte qué querría saber la persona que está del otro lado.
Esto tiene una aplicación directa en reuniones de negocios. Cuando un gerente de tecnología va a presentar una solución a un directorio, la pregunta que se hace internamente suele ser: ¿cómo explico esto para que entiendan lo sofisticado que es? Esa es la pregunta equivocada. La pregunta correcta es: ¿qué necesita saber este directorio para tomar una buena decisión?
El cambio de perspectiva parece pequeño, pero el resultado es radicalmente distinto. Una presentación centrada en el ego técnico llena de siglas y arquitecturas. Una presentación centrada en la audiencia habla de impacto, de costos, de tiempo, de riesgos. La segunda convence. La primera confunde.
En proyectos de escucha activa en equipos de tecnología, hemos visto que los errores más costosos no vienen de decisiones técnicas equivocadas, sino de conversaciones donde nadie realmente escuchó lo que el cliente necesitaba. El equipo escuchó lo que quería escuchar, confirmó sus propias hipótesis, y avanzó en la dirección equivocada durante semanas.
¿Qué tiene que ver hacer un podcast con lanzar un producto de software?
El segundo consejo del video es igual de directo: "Make three episodes before you decide you actually really want to do this." No te comprometas con nada. No announces nada. No inviertas en equipo caro. Haz tres. Ve cómo te sientes. Quizás lo odias. Quizás descubres que eres bueno. Pero no lo sabrás hasta que lo hagas.
Esto es, en esencia, la filosofía del prototipado rápido en desarrollo de software. Y es una de las ideas más subestimadas en empresas medianas de la región.
El patrón que se repite con frecuencia en proyectos de transformación digital es el siguiente: el equipo pasa tres meses planificando, documentando y debatiendo. Se hacen reuniones sobre las reuniones. Se construye un plan perfecto en papel. Y cuando finalmente se lanza algo al mundo real, resulta que los usuarios no lo usan de la manera que nadie esperaba.
Tres iteraciones pequeñas, con usuarios reales, en las primeras semanas, enseñan más que tres meses de planificación en sala de reuniones. No porque la planificación sea mala, sino porque hay cosas que solo se descubren cuando algo existe y alguien lo toca.
Este principio aplica tanto a un módulo nuevo en un ERP como a una app móvil, a un flujo de automatización o a una política interna de la empresa. La pregunta no es: ¿tenemos todo listo para lanzar? La pregunta es: ¿qué es lo mínimo que podemos probar esta semana para aprender algo que no sabemos?
¿Cómo se aplica esto en empresas peruanas y latinoamericanas?
En el contexto empresarial peruano, hay una tensión muy particular entre dos culturas que coexisten: la cultura del plan perfecto antes de actuar y la cultura del "hazlo y ya". Ninguna de las dos, llevada al extremo, funciona bien.
La primera genera parálisis por análisis. Proyectos que nunca arrancan porque siempre falta un requisito más, una aprobación más, una reunión más. La segunda genera caos: soluciones que se implementan sin entender el problema, y que generan más trabajo manual del que resolvieron.
El punto de equilibrio está exactamente donde el video lo plantea: prueba antes de comprometerte. Haz tres episodios. Lanza un piloto con un área antes de desplegar a toda la empresa. Automatiza un proceso pequeño antes de rediseñar toda la operación.
En implementaciones de transformación digital en empresas PYME en Perú, los proyectos que mejor funcionan son los que empiezan con un alcance pequeño, bien definido, con un equipo reducido, y que miden resultados concretos en las primeras semanas. Ese primer resultado —por pequeño que sea— genera confianza interna, demuestra valor real, y abre la puerta para escalar.
La curiosidad también juega un rol aquí. Los líderes que hacen mejores preguntas a sus equipos —no para demostrar que saben, sino para entender de verdad lo que está pasando— toman mejores decisiones. Un gerente que pregunta "¿por qué el equipo tardó más de lo esperado?" con genuina curiosidad obtiene información útil. Uno que pregunta lo mismo para señalar culpables obtiene silencio o respuestas defensivas.
¿Cómo aplica esto en tu empresa?
Si eres gerente general, director de operaciones o líder de un área tecnológica, hay tres preguntas concretas que vale la pena hacerte esta semana:
Primera: ¿Las reuniones que tienes con tu equipo o con clientes están centradas en lo que ellos necesitan saber, o en lo que tú quieres mostrar? Si la respuesta honesta es la segunda, hay una oportunidad inmediata de mejorar la calidad de esas conversaciones.
Segunda: ¿Hay algún proyecto que lleva más de un mes en fase de planificación sin haber probado nada en el mundo real? Si la respuesta es sí, considera qué es lo más pequeño que podrías lanzar esta semana para obtener feedback real.
Tercera: ¿Tu equipo tiene espacio para probar cosas que podrían no funcionar? La cultura de prototipado rápido solo existe cuando el error en fase temprana no tiene consecuencias graves. Si tu equipo tiene miedo de proponer algo que no sea perfecto, el problema no es de metodología sino de cultura.
Estas no son preguntas técnicas. Son preguntas de liderazgo. Y tienen un impacto directo en la velocidad con la que tu empresa aprende, se adapta y mejora.
Preguntas Frecuentes
¿Qué es el prototipado rápido y cómo se aplica en una empresa mediana en Perú?
El prototipado rápido es una metodología que consiste en construir versiones mínimas y funcionales de una solución para probarla con usuarios reales antes de invertir en un desarrollo completo. En una empresa mediana peruana, esto puede significar lanzar un módulo piloto de ERP con un solo departamento, automatizar un proceso pequeño con herramientas como n8n antes de escalar, o crear un formulario digital básico antes de construir una app completa. El objetivo es aprender rápido con el menor costo posible.
¿Cómo mejorar la escucha activa en equipos de tecnología que trabajan con clientes no técnicos?
La clave está en cambiar la pregunta interna que se hace el equipo técnico. En lugar de "¿cómo explico esto?", la pregunta debe ser "¿qué necesita entender esta persona para tomar una buena decisión?". En la práctica, esto implica usar analogías del negocio en lugar de términos técnicos, preguntar antes de presentar, y validar con el cliente que lo que se entendió es lo que realmente se necesita. Las reuniones de levantamiento de requerimientos con preguntas abiertas y sin asumir nada de antemano son el primer paso.
¿Cuánto tiempo debería durar la fase piloto de un proyecto de transformación digital antes de escalar?
No existe una respuesta única, pero una referencia práctica para empresas en América Latina es entre cuatro y ocho semanas para un piloto bien delimitado. Lo importante no es el tiempo sino los criterios de éxito definidos antes de empezar: ¿qué tiene que ser verdad al final del piloto para decidir que vale la pena escalar? Si esos criterios están claros desde el inicio, el piloto tiene un propósito concreto y la decisión de escalar o no se toma con datos reales, no con intuición.
Conclusión: ¿qué cambiarías si pusieras el foco en el otro?
Dos ideas simples de una conversación de podcast pueden sonar a poco. Pero la curiosidad genuina —esa que no es sobre ti sino sobre el otro— y la disposición a probar antes de comprometerte son dos de los hábitos más escasos y más valiosos en organizaciones que quieren crecer de manera inteligente.
No se necesita una metodología nueva ni una certificación. Se necesita cambiar la pregunta que te haces antes de hablar, y tener la disciplina de lanzar algo pequeño esta semana en lugar de planificar algo perfecto para el próximo trimestre.
En Consultoría-Ti trabajamos con empresas en Perú y América Latina que quieren implementar cambios reales sin perderse en la teoría. Si tienes un proyecto en mente y no sabes por dónde empezar, o si llevas meses planificando sin avanzar, conversemos. A veces lo único que falta es dar el primer paso pequeño con alguien que ya lo ha hecho antes.
👉 Contáctanos aquí y cuéntanos en qué etapa está tu proyecto.
Fuentes y Referencias
TED Talks — Lean into your curiosity (YouTube Shorts)
✨ Contenido generado con ContentFlow — Consultoría-Ti