La diferencia entre construir un producto digital y entregar un proyecto de software

Una distinción que no es semántica

Cuando una empresa nos contacta para construir una plataforma, lo primero que intentamos entender es qué tipo de relación están buscando. No por hacer filosofía de producto en la primera llamada, sino porque la respuesta cambia todo lo demás: qué perfil de equipo necesitan, qué proceso tiene sentido, cuál será el resultado probable en doce meses.

Un proyecto de software tiene un principio, un fin y un entregable. Se define con un pliego de requisitos, se ejecuta contra ese pliego, y se cierra cuando lo especificado existe. El proveedor ha cumplido cuando el código funciona según lo acordado. Lo que pase después —si los usuarios lo adoptan, si el negocio mejora, si la tecnología envejece bien— no es su problema. En muchos casos, ni siquiera aparece en el contrato.

Un producto digital, en cambio, no tiene fecha de entrega final. Tiene métricas de negocio, usuarios reales, ciclos de aprendizaje. El trabajo es continuo porque el conocimiento sobre el problema es continuo. Lo que se construye en el mes uno rara vez es lo que se necesitaba: el valor está en la capacidad de aprender rápido y ajustar.

Un ejemplo concreto de mentalidad proyecto vs. mentalidad producto

Hace un par de años entramos en un proyecto de rescate que ilustra bien la diferencia. Una empresa de servicios profesionales había contratado a una agencia para construir una plataforma interna de gestión de casos. El contrato especificaba 37 pantallas, 14 roles de usuario, tres módulos funcionales y cuatro integraciones. La agencia entregó exactamente eso. Técnicamente funcionaba. Nadie en la empresa lo usaba.

Cuando nos pidieron auditar la situación, encontramos algo que veríamos repetidamente en años siguientes. El equipo de producto del cliente había escrito una spec basada en cómo imaginaba que querría trabajar, no en cómo trabajaba realmente. La agencia, fiel al contrato, no había cuestionado ninguna de esas suposiciones. El resultado era una herramienta internamente consistente pero divorciada de la realidad operativa.

Dos de las 37 pantallas concentraban el 90% del trabajo real de los usuarios; las otras 35 eran casos excepcionales o workflows que en la práctica nadie usaba. Una de esas dos pantallas clave tenía una fricción seria —pedía seis campos cuando los usuarios en la realidad solo tenían tres en ese momento del proceso— que invalidaba la herramienta. Pero como la spec pedía seis campos, seis campos había.

Con mentalidad de producto, esa conversación se tiene antes de escribir código. Con mentalidad de proyecto, se tiene después del lanzamiento, cuando nadie adopta la herramienta.

Discovery vs. saltar a código: el coste de construir lo incorrecto

El error más caro que hemos visto en proyectos no es elegir el stack equivocado ni la sobreingeniería. Es empezar a construir demasiado pronto, antes de entender bien el problema.

La fase de discovery, que en nuestra metodología dura entre dos y cuatro semanas dependiendo de la complejidad del dominio, sirve para hacer explícito lo que normalmente permanece implícito. ¿Cuál es el problema de negocio concreto? ¿Quiénes son los usuarios reales y qué hacen hoy sin el producto? ¿Cuáles son las restricciones técnicas existentes —sistemas legados, APIs disponibles, regulación—? ¿Cómo mediremos el éxito?

En un proyecto reciente con una compañía de salud, dos semanas de discovery revelaron que el módulo más complejo del spec —un motor de reglas configurable que habría costado tres meses construir— no era necesario en absoluto. El problema que pretendía resolver se resolvía mejor con un flujo guiado de cinco pasos. Esas dos semanas ahorraron seis meses de desarrollo y una funcionalidad que nadie habría usado.

Las dos semanas más baratas de cualquier producto son las dos semanas de discovery antes del primer sprint.

El output del discovery no es un documento de requisitos exhaustivo. Es un conjunto de decisiones arquitectónicas documentadas, un mapa de riesgos técnicos conocidos, una definición de MVP que el equipo entiende y el cliente puede validar, y un plan de medición del éxito. Con eso encima de la mesa, el primer sprint va en la dirección correcta.

Los clientes que más resistencia ponen al discovery suelen ser los que más lo necesitan. "Ya sé lo que quiero construir" es una frase que casi siempre precede a un cambio de alcance significativo en la semana seis.

Composición del equipo: los roles que las agencias saltan

La diferencia más visible entre un proyecto y un producto está en la composición del equipo. Un proyecto necesita ingenieros que ejecuten un spec. Un producto necesita personas que cuestionen el spec.

Cuando construimos producto, el equipo mínimo viable siempre incluye alguien con función de producto —no solo gestión de proyecto— desde el primer día. Esa persona no coordina tareas: hace preguntas incómodas. ¿Por qué los usuarios necesitan esta funcionalidad? ¿Hay una forma más simple de resolver el mismo problema? ¿Podemos medir si funciona antes de construirlo entero? ¿Qué dejamos de hacer al construir esto?

Además incluye diseño UX desde el día uno, no como capa de maquillaje al final. Y, críticamente, incluye acceso a usuarios reales durante todo el proceso, no solo en una fase de validación al final. Cuando construimos Race+ con equipos de neurología, la mayor parte del valor no vino de la implementación técnica, sino de entender el flujo de trabajo real en urgencias: qué información necesita cada rol en cada momento, dónde estaba la fricción que costaba tiempo, qué del proceso existente no había que reemplazar porque funcionaba. Ningún pliego contenía eso. Lo aprendimos en urgencias, observando, iterando.

Las agencias saltan estos roles porque son caros y no aparecen en el entregable físico. Un producto sin product manager tiene features pero no tiene dirección; sin diseño integrado tiene pantallas pero no tiene experiencia; sin contacto con usuarios reales tiene suposiciones pero no tiene validación.

El anti-patrón del "sí, podemos construir lo que pidas"

Hay un tipo de proveedor fácil de contratar y caro de mantener: el que acepta cualquier spec sin cuestionar nada. Entregan exactamente lo que se les pidió. El problema es que lo que se pide rara vez es lo que se necesita.

Hemos entrado en rescates donde el software técnicamente funcionaba pero nadie lo usaba. Los motivos son siempre variantes del mismo patrón. El proceso de diseño no involucró a usuarios reales. Las funcionalidades se definieron por intuición en lugar de evidencia. El alcance creció sin control porque nadie hizo la pregunta "¿para qué sirve esto?".

La promesa de construir exactamente lo que el cliente describe parece más segura. En realidad, desplaza el riesgo: si el product-market fit no llega, la culpa puede atribuirse a la estrategia, no al proveedor que ejecutó fielmente. Para nosotros ese modelo no es aceptable. Levantamos producto, no solo ejecutamos.

La diferencia entre construir features y construir producto está en las preguntas que se hacen antes de cada sprint.

Métricas antes de features

Una práctica que distingue el pensamiento de producto del de proyecto es la relación con las métricas. En un proyecto, el éxito es entregar. En un producto, el éxito es un número que mejora: tiempo puerta-aguja reducido, tasa de conversión aumentada, tiempo hasta resolución de incidencia disminuido, churn contenido.

Definir esas métricas antes de empezar a construir tiene un efecto disciplinador enorme. Cuando el equipo sabe qué número tiene que mover, la priorización se vuelve más fácil. La funcionalidad que no contribuye a la métrica principal es candidata a descartarse, por interesante que sea técnicamente.

En Nexen, la métrica que guiaba las decisiones en los primeros meses era el tiempo medio que un agente tardaba en resolver una conversación. Cada funcionalidad propuesta se evaluaba contra esa variable. Cuando surgió una propuesta de pantalla de análisis histórico detallada, la descartamos: los agentes no la iban a usar en tiempo real, no movía la métrica. Seis meses después, cuando el producto tenía tracción, esa misma pantalla entró en el roadmap con otra justificación. El momento importaba.

Qué significa "ser dueño de un producto"

Ser dueño de un producto significa que cuando algo no funciona, el equipo no se cruza de brazos porque "no estaba en el spec". Significa que la conversación con el cliente no termina cuando se cobra la última factura del hito. Significa que los ciclos de mejora continúan mientras el producto tenga usuarios, y que el equipo técnico es responsable no solo del código sino del resultado de negocio.

Este tipo de razonamiento no emerge naturalmente en un modelo de proyecto. Emerge cuando el equipo entiende que su trabajo no es entregar código, sino resolver un problema de negocio —y que ese problema rara vez se resuelve del todo, solo se resuelve mejor cada trimestre.