Una de las cosas que más me llamó la atención al volver a construir productos propios es la diferencia entre desarrollar software y construir un producto.

Durante muchos años trabajé en grandes organizaciones donde el foco principal estaba puesto en entregar soluciones para usuarios internos o para necesidades ya identificadas por el negocio. Había desafíos técnicos complejos, restricciones organizacionales, procesos, integraciones y prioridades cambiantes. Pero había algo que casi siempre estaba resuelto: los usuarios ya existían.

Cuando uno desarrolla una aplicación propia, descubre rápidamente que escribir código es solo una pequeña parte del trabajo. El producto no termina cuando la funcionalidad funciona correctamente. En realidad, ahí empieza una etapa completamente diferente.

De repente aparecen preguntas que rara vez ocupaban espacio en proyectos internos. ¿Cómo encuentra la gente la aplicación? ¿Por qué alguien debería elegirla en lugar de las alternativas existentes? ¿Cuál es el precio adecuado? ¿Cómo se responde a una consulta de soporte? ¿Qué sucede cuando un usuario abandona el proceso de registro? ¿Cómo se consigue el primer cliente?

Nada de eso suele formar parte del trabajo cotidiano de un equipo de desarrollo dentro de una gran compañía. Allí el éxito generalmente se mide por la entrega, la adopción interna o el impacto en procesos del negocio. En un producto propio, el éxito depende de que alguien descubra el producto, lo pruebe, le encuentre valor y decida seguir utilizándolo.

También cambia la forma de priorizar. En proyectos corporativos es común dedicar semanas a mejorar arquitectura, procesos o aspectos técnicos que generan valor a largo plazo. En un producto pequeño, muchas veces una mejora en la página principal, una explicación más clara de una funcionalidad o una simplificación del proceso de registro generan más impacto que una refactorización impecable.

Esto no significa que una disciplina sea más difícil que la otra. Son problemas diferentes. Construir software requiere capacidades técnicas. Construir productos exige combinar esas capacidades con comprensión de usuarios, comunicación, distribución, soporte, posicionamiento y sostenibilidad económica.

Quizás por eso tantos desarrolladores descubren que lanzar una aplicación propia es una experiencia tan formativa. Obliga a salir de la zona donde el código es el centro de todo y a entender que el software solo tiene valor cuando forma parte de una solución que las personas encuentran, entienden y utilizan.

En los proyectos que estoy construyendo actualmente, incluyendo Founder y otras iniciativas bajo SparkIO, estoy aprendiendo que la parte técnica suele ser la más predecible. Lo verdaderamente desafiante es todo lo que ocurre alrededor del producto una vez que el código ya está funcionando. Ese es el momento en que uno deja de pensar solamente como desarrollador y empieza a pensar como constructor de productos.