Construir el producto era la parte fácil

A los desarrolladores nos encanta creer que construir el producto es la parte difícil. Pensamos que, si hacemos algo robusto, con linda UI, buena UX y escalable, los usuarios van a venir solos. Pero no funciona así.

Construir Onpadel iba a ser complicado pero sabía cómo hacerlo. Lo que no sabía era cómo hacer para que un organizador de torneo lo usara, qué le tenía que decir? cómo se lo tenía que presentar? por qué elegiría usarlo en lugar de seguir haciendo lo mismo de siempre?

Ninguna arquitectura limpia ni código robusto hace que un usuario abandone una herramienta que viene usando hace años. Eso no es un problema técnico: es un problema de confianza.

Así que cuando lancé el producto me puse manos a la obra. Contacté directamente a organizadores y clubes por WhatsApp, Instagram, Facebook y email. Fui a torneos, me presenté en persona y hasta les ofrecí el primer torneo gratis, con soporte 24/7.

Ahí entendí que convencerlos no era simplemente mostrarles un software mejor. Muchos preferían seguir con las herramientas que ya conocían, aunque fueran más incómodas! También había desconfianza: por qué iban a confiar en una plataforma nueva? por qué pagar por algo que hasta ese momento resolvían gratis con papel, Excel o WhatsApp?

Entendí que no alcanzaba con mostrar funcionalidades. Tenía que demostrarles qué ganaban con el cambio, cuánto tiempo podían ahorrar y por qué valía la pena mi producto. Antes de venderles software, tenía que venderles la idea de que trabajar de otra manera realmente les convenía.

Esta fue una de las lecciones más importantes que me dejó el proyecto: hay una parte de la ingeniería de producto que va mucho más allá del código y de las tecnologías utilizadas. El marketing y la distribución no vienen después de construir el producto: son parte del trabajo desde el principio.

Sigo disfrutando de construir productos, pero hoy veo el proceso de otra manera. Con la IA haciendo cada vez más fácil desarrollar software, creo que el marketing, la distribución y la capacidad de entender al usuario van a cobrar cada vez más relevancia.

En un mundo donde construir software es cada vez más accesible, aparece otra pregunta: por qué alguien pagaría por tu producto si puede construir algo similar por su cuenta y tener el control total?

Lograr que la gente lo conozca, confíe en él y encuentre valor en usarlo sigue siendo otro desafío… pero esa es una historia para otro post.