Tu producto es una función
Describir el producto como sustantivo invita a hacer catálogos. Describirlo como función obliga a decir qué entra, qué sale y para quién sirve.

Successful design is not the achievement of perfection but the minimization and accommodation of imperfection.
H. Petroski — «To Engineer Is Human»
Casi siempre describimos los productos con sustantivos. Un panel de control, un CRM, un marketplace, una app de gestión de gastos. Y describimos las funcionalidades con más sustantivos: un filtro, una exportación, un aviso, un buscador.
Los sustantivos tienen una propiedad peligrosa: invitan a hacer catálogos. Se pueden acumular sin límite porque añadir un sustantivo a una lista no rompe la lista. De ahí sale ese género literario tan característico de nuestra industria que es la comparativa de funcionalidades por columnas, donde el producto gana si tiene más cruces.
Hay otra manera de decirlo, que cambia bastante. Un producto es una función: recibe una situación y devuelve un resultado. Lo interesante no está en la lista de lo que contiene, sino en la transformación que hace y en el conjunto de situaciones para las que está definida.
El dominio es lo que casi nadie declara
Cuando piensas en una función, aparece inmediatamente una pregunta que el catálogo no obliga a hacerse: ¿para qué entradas está definida?
Ahí es donde se rompen la mayoría de los productos. No en la transformación, que suele estar bien hecha, sino en el dominio. La función funciona; simplemente no está definida para las situaciones en las que está la gente. Se construyó pensando en el caso limpio —el usuario que tiene todos los datos, los permisos correctos, el proceso completo y una sola cosa que hacer— y se comporta de forma arbitraria en cuanto aparece cualquiera de las circunstancias que constituyen la vida laboral real: el archivo a medias, el cliente que no encaja en ninguna categoría, la persona que hace el trabajo de otra durante unas vacaciones.
Esos bordes no son excepciones. Son la mayor parte del volumen. Un producto puede pasar todas sus pruebas y resultar inservible porque cada prueba se escribió dentro del dominio en el que ya se sabía que funcionaba.
Declarar el dominio tiene además una virtud política. Un producto que dice en voz alta para qué situaciones sirve puede decir también para cuáles no, y eso es lo único que hace posible negarse a algo sin dar la impresión de estar siendo perezoso. Sin función declarada, cualquier petición es igual de legítima, y el backlog se convierte en un depósito.
Petroski y la imperfección administrada
La cita de Petroski dice algo que en ingeniería civil es evidente y en software seguimos negando: el diseño no consiste en alcanzar la perfección, sino en minimizar y acomodar la imperfección.
Acomodar es la palabra importante. No dice eliminar. Dice construir el sitio donde la imperfección va a vivir sin destruir el resto. Un puente se diseña sabiendo que se va a deformar, y se diseña la junta que permite esa deformación. La imperfección no se combate: se le asigna un lugar.
La ingeniería aprendió esto porque los puentes se caen y las caídas se investigan. El software tiene una plasticidad que le permite escapar de ese ajuste de cuentas: siempre puedes desplegar un parche esa misma tarde. La consecuencia no es que tengamos menos imperfección, sino que nunca llegamos a construirle el alojamiento. Vamos poniendo parches donde debería haber una junta, y a los tres años lo que hay es una capa geológica de excepciones que ya nadie puede leer.
Aplicado a la función: no se trata de que el dominio sea infinito. Se trata de decidir qué ocurre cuando la entrada está fuera. Un producto bien hecho no es el que nunca recibe una situación imprevista; es el que, cuando la recibe, hace algo comprensible con ella.
Las funciones se componen
Hay una última ventaja, que es la que más aprecio y la que peor tratamos.
Las funciones se combinan. Es el principio sobre el que se construyó la tradición Unix: haz una cosa y hazla bien, y déjala en condiciones de que otro la encadene con algo que tú no habías previsto. Un programa definido por lo que transforma puede formar parte de una cadena. Un programa definido por lo que contiene solo puede crecer.
Los productos siguen la misma regla. Los que se definen por su catálogo únicamente se pueden ampliar, y su forma de responder al mercado es añadir. Los que se definen por su función pueden entrar en composiciones que no habían imaginado, y esa capacidad es hoy más valiosa que nunca, cuando cualquier producto va a acabar siendo invocado por un agente que no leyó su documentación de marketing.
Merece la pena hacer el ejercicio con lo que tengas entre manos. Escribe en una frase qué transforma tu producto, sin nombrar ninguna pantalla. Si no puedes, tienes un catálogo. Y la naturaleza de los productos digitales no perdona los catálogos: crecen hasta que nadie recuerda de qué iba todo esto.