El producto funciona, ¿pero has llegado a entregarlo? Por qué una demo tibia delata un problema

🕒 Publicado en Zendoric: 11 de noviembre de 2026 · 00:19
✨ Generado con IA · cómo se hace
El artículo, firmado por Hunter Harris (consultor de producto y tecnología para fundadores de SaaS B2B), parte de una escena que muchos equipos reconocen. Haces la demo y la respuesta es «parece interesante», «está bien» o el temido «es correcto».
El artículo, firmado por Hunter Harris (consultor de producto y tecnología para fundadores de SaaS B2B), parte de una escena que muchos equipos reconocen. Haces la demo y la respuesta es «parece interesante», «está bien» o el temido «es correcto». Es una forma de rechazo educado, una «muerte por mil cortes» en la que el elogio tibio hunde el producto. El autor aclara que no va a cubrir todas las causas posibles, sino algunas que ha visto recientemente.
El primer diagnóstico es que el equipo ha construido a partir de ideas, sin contrastar hipótesis pronto. Según el autor, suele ser una combinación de tres fallos: producto equivocado, comprador equivocado o momento equivocado. Es la reacción más plana posible: tienes algo llamativo y el cliente responde «¿y?».
«Producto equivocado» es, según el propio autor, una etiqueta algo imprecisa. Lo que describe es centrarse en la solución y no en el problema. Si resuelves una prioridad secundaria mientras el comprador tiene una urgencia grave, o está entusiasmado con otra cosa, no tendrá espacio para ilusionarse con lo que ofreces.
«Comprador equivocado» es la otra cara. Puedes resolver un problema real, pero la persona que decide la compra no se preocupa por él. Es más habitual en la venta enterprise y la venta por cuentas. La idea central de la mitigación es identificar a tu «champion» (el defensor interno) y hacer que sea él quien venda la solución al comprador. Peor es el caso en que la empresa entera no encaja con tu perfil de cliente ideal (ICP). Entonces el problema se parece más al de producto equivocado para ese cliente. Explorar el mercado es necesario para un movimiento lateral, y quizá descubras algo mejor que construir.
«Momento equivocado» es en el fondo producto equivocado, pero acotado en el tiempo. El cliente puede haber resuelto ya el problema o tener prioridades más urgentes. La recomendación es hablar con ellos y averiguar cuál es su prioridad número uno.
La segunda parte se titula «No me hagas pensar» y se centra en las páginas de producto. El autor ve a menudo que, nada más aterrizar, se le obliga a elegir: «Para administradores» o «Para ingenieros», o un plan de precios. El visitante llega sin saber nada del producto, así que en realidad se le piden dos decisiones: primero, si le interesa lo que tiene delante; segundo, qué nivel o perfil elegir. El resultado es que los clientes potenciales se van. Son gente ocupada y no quieren otra tarea más. Explicar por qué debería importarle al cliente es trabajo tuyo, no del cliente. Hay que decir qué problema resuelve el producto, para quién y con qué resultados, y asumir que quienes llegan lo hacen desde cero, porque hay muchos más clientes potenciales que usuarios, incluso en aplicaciones grandes.
La tercera parte, «Estoy confundido», amplía la anterior con una lista de errores:
- Siglas por todas partes. El autor señala con ironía que «ICP» es en sí una sigla. - Precios confusos. Combinar suscripción, precio por puesto y precio por uso es un error. Pide elegir un modelo y ayudar al cliente a estimar su coste esperado, porque nadie se interesa por una solución que no sabe si puede pagar. - Demasiadas opciones y demasiados clics. Si es difícil moverse o encontrar información, el visitante que aún no está interesado simplemente se va. Aunque la solución fuera de las que «sería raro no comprar», no llega a verla. - La misma cosa en dos sitios. Es el clásico «es fácil perderse» y provoca la pregunta «¿cuál es la diferencia?».
El cierre insiste en que lo construido tiene sentido para quien lo construyó, pero los visitantes están ocupados, cansados y poco dispuestos a leer o a preocuparse. Por eso es responsabilidad del equipo ponérselo fácil: fácil de entender, de usar, de vender y de ampliar.
La tesis final es la distinción entre «lanzar a producción» y «entregar». Subir código a producción es solo un despliegue: el código y la funcionalidad están ahí. El autor recurre a la pregunta «si el código está en producción y nadie lo usa, ¿lo hemos entregado?» y responde que no. Entregar significa que el producto está en manos del cliente, que lo usa y que obtiene valor de él. Si se observan los síntomas descritos, el equipo puede estar lejos de haber entregado. La recomendación es salir de la propia cabeza y del propio negocio, ponerse delante de los clientes, entender qué les interesa, facilitarles las cosas y entregar.
Nota para el lector: el texto es una pieza de opinión breve basada en la experiencia del autor. No aporta datos, estudios ni cifras, y su valor está en el marco de diagnóstico y en la lista práctica de errores de comunicación y de página de producto. Aunque no menciona inteligencia artificial, encaja en el debate actual sobre lo fácil que resulta hoy construir software y lo difícil que sigue siendo que alguien lo necesite.
🔗 Relacionadas en Zendoric
- Por qué los agentes de IA fallan con confianza: no es el modelo ni el contexto, es la ingeniería de datos · 2026-07-24
- Prohibir la IA en la escuela no la detiene: Tiramonti advierte que el problema real es la brecha de conectividad en Argentina · 2026-07-27
- Los mascotas de la IA: por qué la tecnología más avanzada necesita pequeños personajes hechos por humanos · 2026-10-14


