RIN: defining the strategy for a new collections CRM

I contribute as a Product Manager to the development of RIN, a new collections CRM, working across discovery, AS-IS analysis, pain point identification, TO-BE definition, prioritization and user validation. As part of my contribution, I developed a comprehensive product strategy proposal covering market, competition, positioning, value proposition, KPIs and MVP evolution.

My role: Product Manager, RECSA

The problem

RECSA started building RIN with the challenge of evolving from an operation supported by existing systems, distributed processes and accumulated operational knowledge into a new CRM specialized in collections. The challenge is not simply replacing technology: it requires understanding what works today, which problems users face, which capabilities should be preserved and which should be redesigned to build a product that improves operations and can evolve at scale.

Discovery

Discovery starts by mapping the AS-IS of current systems and processes and involving expert users from different areas. We work with an Ambassador program to identify pain points, required capabilities and elements that should be preserved. These inputs are complemented with market benchmarking before developing TO-BE proposals. The goal is to avoid automatically replicating existing systems in the new CRM and instead base product decisions on evidence, user needs and industry references.

Decisions and trade-offs

Build a product strategy instead of focusing only on features
I developed a comprehensive product strategy proposal for RIN covering problem definition, target market, segmentation, competitive analysis, positioning, SWOT, value proposition, KPIs and an MVP evolution vision. The goal was to provide a framework for discussing not only which features to build, but who we are building for, which problem we are solving and how product value should be measured.
Ruled out: Defining the product mainly as a list of requested features. This could accelerate initial decisions, but made it harder to connect the roadmap with a value proposition and business outcomes.
Use the AS-IS as a starting point without limiting the new product to it
Current systems are mapped to understand processes, screens, data, users and existing capabilities. However, we deliberately separate this mapping from problem and needs identification to prevent the new CRM from becoming merely a technological reproduction of the existing systems.
Ruled out: Directly migrating existing functionality into the new CRM. Although simpler for defining scope, it would also carry over historical problems and decisions without questioning whether they still provide value.
Bring expert users into the product definition process
The methodology brings in Ambassadors from different areas to contribute operational knowledge, identify pain points, highlight what should be preserved and express needs before development. Product consolidates these inputs and uses them to design TO-BE proposals, reducing the risk of defining the CRM solely from a technical or management perspective.
Validate the TO-BE before moving into development
TO-BE proposals are presented and validated with Ambassadors through structured scoring. The methodology establishes a minimum average score of 7 out of 10 to move forward; if the proposal does not reach that level, Product analyzes the feedback, makes adjustments and proposes again. Validation therefore becomes an explicit progression criterion rather than a review performed after development.
Ruled out: Build first and validate later. Although this can reduce initial analysis time, it increases the risk of investing development effort in solutions that do not adequately address identified needs.
Prioritize the MVP based on problems and evidence
Inputs from the AS-IS, pain points identified by Ambassadors and benchmarking are used to build the TO-BE and determine which capabilities should be part of the MVP and which can remain in the backlog. Technical feasibility is reviewed with Development before finalizing the proposal.

Results

RIN is currently under development, so it is still too early to attribute final adoption or operational impact results. So far, progress includes a product strategy, structured AS-IS discovery and an iterative methodology to discover, propose, validate and test each module before further evolution. The strategic proposal also provides a framework for discussing positioning, target market, value proposition, KPIs and MVP evolution as the product progresses.

Key learnings

Working on RIN reinforced the importance of separating requirements from real problems. Understanding the current system in depth is necessary, but it does not mean the new product should reproduce it. Combining users' operational knowledge, benchmarking, product strategy and early validation provides better context for decision-making and reduces the risk of building features without a clear value hypothesis.