Cuando Michael Gold tenía 15 años, dirigía su propia empresa de eventos, organizando reuniones para 500 personas. Su padre había tenido su propio negocio toda la vida. El emprendimiento no era una aspiración en su familia, sino más bien una suposición.
Y luego, en algún momento, lo dejó.
"A medida que fui creciendo, de alguna manera me asusté y dejé de ser emprendedor", me dijo. En su lugar, construyó una carrera en gestión de proyectos: casi 15 años, comenzando en campos creativos antes de mudarse al sector tecnológico. Hace unos dos años pasó a trabajar de forma fraccional, fundando su propia agencia de gestión de proyectos y trabajando como director fraccional de entregas para startups y clientes empresariales. Por cualquier medida, un camino exitoso. Pero el gusanillo emprendedor nunca se fue del todo. Solo quedó en letargo.
Crecí y me asusté y dejé de ser emprendedor.
Este mes, más de dos décadas después de aquellos primeros eventos, Michael lanzó el producto de software Aria, una herramienta de automatización de servicios profesionales (PSA). La está construyendo con un pequeño equipo fundador que incluye a su esposa Rachael, una ilustradora.
He entrevistado a Michael dos veces en los últimos meses, y en ambas conversaciones la misma pregunta seguía surgiendo: ¿qué cambió? Porque él no es desarrollador. Nunca lo fue. Lo que cambió es que la IA hizo que no serlo fuera un problema mucho menor de lo que solía ser.
Empezó con irritación, no con ambición

El camino de Michael hacia la creación de software no comenzó con un plan de negocios. Comenzó con pequeñas frustraciones familiares.
Rachael había construido el sitio web de su agencia en Wix, y cada cambio tenía que pasar por ella. "Realmente odiaba depender de ella para todo", dijo. Así que conectó el sitio a una herramienta de codificación con IA. "En una hora tenía el mismo sitio web, pero uno que ahora podía controlar yo". Después, programó a su manera su propio CRM para reemplazar una suscripción de $100 al mes que le parecía absurda para una operación de una sola persona. No era mejor que el producto real, y él mismo lo admite, pero hacía lo que necesitaba y lo más importante: "fue realmente divertido construirlo".
Esa experiencia sacó a la luz una pregunta que nunca antes había tenido los recursos para plantearse:
"Algo como HubSpot tiene que tener todas las funciones posibles para atender a todos los clientes posibles. Y por eso cuesta lo que cuesta, porque es una herramienta increíble. Pero si solo necesitas el 0,5% de esa herramienta, surge la pregunta: ¿por qué estoy pagando por el otro 99,5%?"
Cuesta lo que cuesta [Hubspot] porque es una herramienta increíble. Pero si solo necesitas el 0,5% de esa herramienta, surge la pregunta: ¿por qué estoy pagando por el otro 99,5%?
Cada pequeña creación hacía que la siguiente idea fuera más factible. Esto no era alguien decidiendo convertirse en fundador de software. Era un gestor de proyectos resolviendo sus propios problemas y, en el proceso, reconstruyendo en silencio la confianza que había perdido.
Ya había vivido el problema que ahora está resolviendo
La cuestión del software, históricamente, es la siguiente: las personas que lo construían y quienes sufrían por él rara vez eran las mismas personas. Crear un producto requería desarrolladores, diseñadores UX y gestores de producto. El rol del usuario final era enviar una solicitud de función y esperar lo mejor. La distancia entre quien sentía el dolor y quien implementaba la solución era un ticket de soporte, un portal de solicitudes de funciones, un gestor de cuentas y la hoja de ruta del producto de otra persona.
Michael ha pasado años en el lado incorrecto de esa distancia.
Hace ocho o nueve años se unió a una agencia que había implementado una nueva plataforma PSA la semana antes de que él empezara. Su reacción no fue leve. "Casi renuncio durante mi período de prueba porque pensé que era lo peor del mundo. Lo odiaba muchísimo."
Se lo comentó al dueño. Quería que eliminaran la herramienta. Entonces sucedió algo poco común; terminó en la hoja de ruta beta del producto del proveedor. "Les ayudé a mejorar la herramienta", dijo, y a medida que el producto mejoraba con los aportes de los profesionales, también lo hacía su relación con este. "Pasé de ser ese tipo que casi renuncia durante el período de prueba a finalmente adoptarlo y luego convertirme en su promotor interno".
Ese era el antiguo modelo de influencia de los profesionales: tener la suerte de entrar en un programa beta y dar forma al producto de otra persona desde fuera. Si sumamos los años que su agencia ha pasado implementando herramientas PSA para clientes, Michael ha visto esta categoría desde todos los puestos, excepto el del creador. Sabe exactamente en qué puntos fallan estas herramientas: la incorporación torpe, las interfaces frías y sin alegría. "No creo que ninguna herramienta PSA sea especialmente bonita. No creo que sean espacios agradables en los que estar", dijo, y por eso Rachael está en el equipo fundador y por eso "realmente quería que Aria se sintiera como un lugar cálido y acogedor".
No creo que ninguna herramienta PSA sea especialmente bonita. No creo que sean espacios especialmente agradables en los que estar. Por eso quería que Aria se sintiera como un lugar cálido y acogedor.
También sabe, por haber observado equipos de entrega reales y no sólo en LinkedIn, que la mayoría de los PM aún no usan IA, por lo que el asistente de Aria señala los problemas y pregunta antes de actuar, en lugar de operar de forma autónoma. "Para mí, los agentes, sean como sean, dan miedo", comentó. "Creo que es mucho más accesible tener un asistente amigable que simplemente está de tu lado".
Ninguna de estas son conclusiones a las que un equipo de producto llegaría con entrevistas a usuarios. Son cicatrices. Michael no está adivinando qué frustra a un PM a las 4 de la tarde de un jueves. Ha sido ese PM. Lo nuevo no es que los profesionales tengan este conocimiento. Es que por fin pueden actuar en consecuencia de forma directa.
De prototipo a producto

La prueba llegó en un solo fin de semana. Cuando su cofundador James propuso la idea de crear ellos mismos una herramienta PSA, Michael inicialmente dijo que no. Este es un software genuinamente complejo, del tipo que gestiona los datos operativos y financieros más sensibles de una empresa. "No hay manera de que vaya a programar una herramienta PSA dejándome llevar por el momento", recuerda haber pensado.
Luego, sin decirle nada a nadie, se sentó frente al teclado. "Pasé 24 horas programando por sensación. Es tan adictivo. Así que, literalmente en el transcurso de un fin de semana, tenía un prototipo que era una herramienta PSA que hacía todo lo que una herramienta PSA debería hacer. O, al menos, eso parecía en la superficie".
En el transcurso de un fin de semana, tenía un prototipo que era una herramienta PSA que hacía todo lo que una herramienta PSA debería hacer. O, al menos, eso es lo que parecía en la superficie.
Esa última frase es importante, y Michael lo recalca. El prototipo fue sólo el inicio del trabajo, no el final. Los meses siguientes han requerido un desarrollador full-stack encargado de la seguridad, la facturación y toda la arquitectura de fondo. CTOs experimentados han revisado el código y ahora asesoran al equipo. El producto recientemente aprobó CASA Tier 2, una verificación de seguridad realizada por terceros.
"Por supuesto que todavía hay bugs. Así que la idea de que uno simplemente puede programar una herramienta PSA dejándose llevar es puro disparate".
La idea de que simplemente vas a programar una herramienta PSA dejándote llevar es puro disparate.
Entonces, si la IA no construyó su producto, ¿qué hizo? "Jamás podría haber diseñado esto con papel y lápiz".
Esta es la capa de traducción que desaparece. Michael no podría haber escrito una especificación o dibujado un UX en un wireframe. Hace una década, ahí habría terminado todo: la idea se quedaba atrapada en la mente del profesional, como tantas ideas de fundadores que han muerto silenciosamente dentro de los project managers. En cambio, la IA le permitió pensar de manera visual e iterativa, creando un prototipo hasta que quince años de cicatrices acumuladas como usuario final tomaron forma ante sus ojos. Algo con lo que podía reaccionar, refinar y entregar a ingenieros de verdad.
Llama a su flujo de trabajo actual "una versión muy estructurada de programar por sensación", en la que se encarga de correcciones y cambios pequeños de funcionalidad "bajo la supervisión y el gobierno de personas técnicas".
"La idea de que un fundador no técnico en una startup pueda realmente seguir impulsando el producto ha sido increíble. Pero el matiz es que necesitaba asociarme con personas que fueran más alfabetizadas técnicamente que yo."
¿Fueron siempre las habilidades de gestión de proyectos?

Recientemente escribí sobre la gestión de proyectos como una habilidad emprendedora, así que planteé la tesis directamente a Michael: ¿están los gestores de proyectos mejor preparados para ser fundadores que personas de otros perfiles?
Él estuvo de acuerdo con partes de ello. Los gestores de proyectos tienen "mayor propensión a lidiar con el estrés", dijo. Cambian de contexto constantemente y gestionan prioridades simultáneas, mientras que otras disciplinas pueden centrarse en una sola cosa. Y, fundamentalmente, definen su propio trabajo: "Un gestor de proyectos le dará un trabajo específico a un diseñador gráfico para el día, mientras que un gestor de proyectos tiene que definir cuál es ese trabajo. Y eso es espíritu emprendedor."
Pero luego le dio la vuelta por completo a mi planteamiento.
"Creo que, porque fui emprendedor desde el principio, por eso fui bueno en la gestión de proyectos. Más que la gestión de proyectos haya perfeccionado mis habilidades emprendedoras. Creo que siempre fui emprendedor y por eso la gestión de proyectos encajó de manera natural conmigo."
En otras palabras, la causalidad es a la inversa. La gestión de proyectos no lo convirtió en fundador. Ser del tipo fundador lo hizo buen gestor de proyectos, y la profesión se transformó en un lugar cómodo para canalizar esa energía, mientras la barrera real, construir algo, seguía siendo demasiado alta.
Apostaría a que Michael no es un caso aislado. ¿Cuántos profesionales llevan una década acumulando frustraciones con las herramientas que usan cada día, sin poder convertirlas en otra cosa más que en peticiones de mejoras? Personas a las que les gusta apropiarse de los resultados, definir el trabajo, tener todo el sistema en su cabeza. Gente que sabe exactamente qué está mal en su software y que, hasta hace poco, no tenía manera de mostrarle a nadie cómo sería hacerlo bien.
Para ese grupo, los dos últimos años cambiaron la ecuación. Pero no porque la IA haya transformado a los gestores de proyectos en emprendedores, sino porque eliminó la última excusa para quienes ya lo eran.
Si quieres saber más sobre lo que Michael y su equipo han estado haciendo, puedes consultarlo aquí.
—--------
¿Quieres más ideas como estas? Regístrate gratis en DPM para escuchar a más expertos como estos.
