Los trajes a medida

¿Un mal necesario?

A ningún PM le gusta hacer un desarrollo especial para un cliente.

A ninguno.

Para nosotros, es como meterle lentejuelas a un traje recién estrenado. Nos molesta que nuestro equipo de producto tenga que invertir tiempo en algo que solo beneficiará a un cliente de todos los que tenemos. Aun así, hay momentos en los que no hay opción y tenemos que hacerlo. A veces porque el cliente es muy grande, otras porque es estratégico, en otras ocasiones para evitar que se vayan, o simplemente porque no se gestionó bien. No importa cuál sea la razón, hacer desarrollos a medida no nos gusta nada.

Para evitarlo, somos capaces incluso de contarnos una de las mayores mentiras de la industria

Si lo convertimos en parte del producto, ya no es un desarrollo a medida. Ahora es una nueva funcionalidad que podrían usar todos los clientes.

Esta idea tiene algo de verdad. De hecho, es una buena práctica desarrollar funciones con un grupo pequeño de clientes para aprender y, después, lanzar la versión terminada para el resto. Pero, ¿dónde está el límite? Hoy en día, casi todo se puede convertir en parte del producto: un flag por aquí, un “if” por allá, y acabas con una versión del producto distinta para cada cliente y un caos de configuración a la que nadie querrá meter mano. Productizar peticiones a medida de clientes trae varios problemas que debemos tener en cuenta para reducir su impacto.

Problemas de evolucionar el producto con "trajes a medida"

Cuando intentamos productizar desarrollos a medida en nuestro producto principal, es fácil caer en la trampa de hacer el código más complicado de lo necesario. Al principio, agregar una configuración que cambie el comportamiento del producto parece una solución rápida y sin problemas. Pero, con el tiempo, esto genera una deuda técnica importante. Cada excepción o condición especial aumenta el riesgo de que haya errores difíciles de encontrar y solucionar.

Además, cada vez que hay que hacer un cambio, el proceso se vuelve más lento, caro y complicado, porque los desarrolladores deben asegurarse de no romper alguna regla especial que afecte a otro cliente. Esta complejidad extra ralentiza el desarrollo y reduce nuestra capacidad para innovar.

Cuantos más desarrollos a medida hacemos, más difícil es gestionar el producto a nivel operativo. La configuración se vuelve un caos, el soporte al cliente más costoso, y entrenar al equipo se complica.

Imagina que el equipo de atención al cliente tiene que recordar las diferencias entre varias versiones del producto cada vez que ayudan a alguien. Esto no solo hace que el soporte sea más caro, sino que también empeora la experiencia del cliente, ya que cada interacción se vuelve menos eficiente. En lugar de tener una versión clara y fácil de entender, cada cliente puede tener su propio "mini producto" con características únicas que no se aplican a los demás.

A medida que acumulamos personalizaciones, perdemos consistencia en la experiencia del usuario. Si un cliente tiene una función que otros no tienen, empiezan a aparecer preguntas como: “¿Por qué mi competidor tiene esto y yo no?”. Además, el equipo de producto empieza a perder el control sobre la visión general. La fragmentación también dificulta comunicar el valor del producto a nuevos clientes, ya que las funciones que deberían ser generales acaban siendo útiles solo para unos pocos. Esta falta de coherencia puede hacer que el producto sea menos atractivo para nuevos clientes.

Estrategias para minimizar el impacto

En lugar de aceptar cada solicitud de personalización, podemos usar estrategias que reduzcan el impacto negativo de estas decisiones sin perder la oportunidad de satisfacer al cliente.

Crea funcionalidades modulares

Una buena forma de evitar demasiada personalización es diseñar funciones modulares. Esto significa construir partes del producto que se puedan usar en diferentes situaciones sin tener que ser "a medida". La modularidad permite escalar el desarrollo y adaptarse a nuevas necesidades sin comprometer la estructura general del producto.

Por ejemplo, si un cliente quiere que calcules unos datos en función de los suyos provenientes del ERP dentro de la herramienta, en lugar de montar funcionalidades sobre sus datos, podemos crear un módulo que transforme esos datos en el modelo de datos core del producto y luego desarrollar la funcionalidad del cálculo por encima, permitiendo que parte de la funcionalidad sea reutilizable por otros clientes. Aunque esta práctica requiere más tiempo de implantación, te permitirá a largo plazo mantener una visión de producto más unificada.

Utiliza flags temporales

A veces, utilizar flags que activen o desactiven funciones específicas para ciertos clientes puede ser la solución más rápida y sencilla. Aunque pueden ser útiles, hay que gestionarlos bien. Un flag no debería ser una solución permanente. Debemos establecer fechas o metas claras para decidir cuándo un flag debe ser eliminado o incorporado al producto completo.

Para evitar que los flags se acumulen y generen desorden, es útil hacer auditorías de código regularmente. En estas revisiones se analizan todos los flags y se decide cuáles deben eliminarse o unificarse. Esto asegura que la complejidad no crezca sin control y mantiene la calidad del producto a largo plazo. No hay nada más peligroso que un flag que nadie sabe lo que hace dentro del código.

No hay que productizar todo

Aunque convertir desarrollos a medida en funciones del producto puede parecer una buena idea, no siempre es lo mejor. El coste de generalizar una función puede ser mayor que el beneficio, añadiendo complejidad innecesaria. Antes de productizar, debemos evaluar si realmente aporta valor al resto de los clientes.

Aprender a decir 'no' es esencial, especialmente con clientes importantes. Ser honestos sobre las limitaciones del producto puede mejorar la relación a largo plazo y fortalecer la confianza en nuestra dirección. Decir 'no' no es ser inflexible; es proteger la integridad del producto. Justificar el 'no' con razones claras ayuda a que el cliente respete el proceso y valore la transparencia.

Priorizar también implica centrarse en mejoras que beneficien a la mayoría. Así, el producto crece de manera coherente y sostenible.

Nuestro reto como PMs es equilibrar demandas del negocio con la visión a largo plazo del producto. Aunque desarrollos a medida son tentadores, suelen tener un coste oculto que afecta al equipo y a la sostenibilidad. Productizar con criterio, saber cuándo decir 'no' y minimizar la complejidad son habilidades esenciales para mantener un producto sólido.

Nuestro trabajo no es solo cumplir solicitudes, sino construir lo que impulsa el crecimiento y estabilidad del producto. Mantener la integridad garantiza que tengamos un producto que evoluciona con propósito y consistencia.

→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.

→ ¿Quieres venir a hablar al podcast? Contesta a este email.