RIN: definiendo la estrategia de un nuevo CRM de cobranzas

Participo como Product Manager en la construcción de RIN, un nuevo CRM de cobranzas, trabajando en discovery, análisis del AS IS, identificación de pain points, definición del TO BE, priorización y validación con usuarios. Como parte de mi aporte, desarrollé integralmente una propuesta de estrategia de producto que abarca mercado, competencia, posicionamiento, propuesta de valor, KPIs y evolución del MVP.

Mi rol: Product Manager, RECSA

El problema

RECSA inició la construcción de RIN con el desafío de evolucionar desde una operación soportada por sistemas existentes, procesos distribuidos y conocimiento operativo acumulado hacia un nuevo CRM especializado en cobranzas. El reto no consiste solamente en reemplazar tecnología: implica entender qué funciona hoy, qué problemas enfrentan los usuarios, qué capacidades deben preservarse y cuáles deben rediseñarse para construir un producto que mejore la gestión y pueda evolucionar de forma escalable.

Discovery

El discovery parte del relevamiento del AS IS de los sistemas y procesos actuales y de la participación de usuarios expertos de distintas áreas. Trabajamos con un programa de Embajadores para identificar pain points, funcionalidades necesarias y capacidades que deben preservarse. Estos insumos se complementan con benchmark de soluciones del mercado antes de construir propuestas TO BE. El objetivo es evitar trasladar automáticamente el funcionamiento de los sistemas existentes al nuevo CRM y fundamentar las decisiones de producto en evidencia, necesidades de usuarios y referencias de industria.

Decisiones y trade-offs

Construir una estrategia de producto antes de definir únicamente funcionalidades
Desarrollé una propuesta integral de estrategia para RIN que incluye definición del problema, mercado objetivo, segmentación, análisis competitivo, posicionamiento, FODA, propuesta de valor, KPIs y una visión de evolución del MVP. El objetivo fue aportar un marco para discutir no solamente qué funcionalidades construir, sino para quién estamos construyendo, qué problema buscamos resolver y cómo medir si el producto genera valor.
Descartado: Definir el producto principalmente como una lista de funcionalidades solicitadas. Este enfoque podía acelerar decisiones iniciales, pero dificultaba conectar el roadmap con una propuesta de valor y resultados de negocio.
Partir del AS IS sin limitar el producto al sistema actual
El relevamiento de los sistemas actuales se utiliza para entender procesos, pantallas, datos, usuarios y capacidades existentes. Sin embargo, separamos deliberadamente ese relevamiento de la identificación de problemas y necesidades para evitar que el nuevo CRM termine siendo únicamente una reproducción tecnológica de lo que ya existe.
Descartado: Migrar las funcionalidades existentes de forma directa al nuevo CRM. Aunque sería un camino más simple para definir alcance, también trasladaría problemas y decisiones históricas sin cuestionar si siguen aportando valor.
Incorporar usuarios expertos al proceso de definición
La metodología incorpora Embajadores de distintas áreas para aportar conocimiento operativo, identificar pain points, señalar qué debe preservarse y expresar necesidades antes de construir. Producto consolida esos insumos y los utiliza para diseñar las propuestas TO BE, reduciendo el riesgo de definir el CRM únicamente desde una perspectiva técnica o gerencial.
Validar el TO BE antes de avanzar a construcción
Las propuestas TO BE se presentan y validan con los Embajadores mediante un scoring estructurado. La metodología establece un promedio mínimo de 7 sobre 10 para avanzar; si la propuesta no alcanza ese nivel, Producto analiza los comentarios, realiza ajustes y vuelve a proponer. De esta forma, la validación se convierte en un criterio explícito de avance y no en una revisión posterior al desarrollo.
Descartado: Construir primero y validar después. Aunque puede reducir el tiempo inicial de análisis, aumenta el riesgo de invertir desarrollo en soluciones que no resuelvan adecuadamente las necesidades detectadas.
Priorizar el MVP a partir de problemas y evidencia
Los insumos del AS IS, los pain points identificados por los Embajadores y el benchmark se utilizan para construir el TO BE y determinar qué funcionalidades deben formar parte del MVP y cuáles pueden permanecer en el backlog. La factibilidad técnica se contrasta con Desarrollo antes de cerrar la propuesta.

Resultados

RIN se encuentra actualmente en construcción, por lo que todavía no corresponde atribuirle resultados finales de adopción o impacto operativo. Hasta el momento se avanzó en la definición de una estrategia de producto, el relevamiento estructurado del AS IS y una metodología iterativa para descubrir, proponer, validar y probar cada módulo antes de su evolución. La propuesta estratégica aporta además un marco para discutir posicionamiento, mercado objetivo, propuesta de valor, KPIs y evolución del MVP a medida que el producto avance.

Aprendizajes clave

Trabajar en RIN reforzó la importancia de separar requerimientos de problemas reales. Conocer profundamente el sistema actual es necesario, pero no significa que el nuevo producto deba reproducirlo. Combinar conocimiento operativo de los usuarios, benchmark, estrategia de producto y validación temprana permite tomar decisiones con mayor contexto y reducir el riesgo de construir funcionalidades sin una hipótesis clara de valor.