Project NIDAAN Highlights:

496 competing proposals. 15 countries. NIDAAN won a national fintech hackathon by solving a problem most PMs never encounter: how do you build a grievance system for users who cannot read, cannot type, and in some cases cannot hear?

| 1st Place RBI HaRBInger 2025 | 496 Proposals from 15 countries | 0 accessible paths before this product | | --- | --- | --- |

As a Product Manager at F22 Labs, working with Bank of Baroda as the client. I owned NIDAAN end-to-end for the RBI HaRBInger 2025 hackathon: problem framing, product decisions, and cross-functional coordination across design, engineering, and the client team. The project was a quick sprint between Feb’26 to April’26

The Problem Statement:

India has over 70 million divyang (disabled), senior citizen, and low-literacy banking customers. When something goes wrong with their account, the existing digital grievance system asks them to type, navigate, and read confirmation screens. Most of them cannot. The already existing solutions makes the process harder where some of them ask the users to type 1, type 2 on the keyboard. Not all of them can do that - at this point the user is already frustrated, adding more friction points to this will drive them away.

The result however, is not just frustrating, it is a systemic failure. Legitimate complaints go unfiled. Disputed deductions stay unresolved. Pension delays go unaddressed. These users have bank accounts. They just have no way to use the systems that are supposed to protect them.

The question we started with: what does a grievance system look like when you cannot assume the user can read or type in any language?

Research Signal:

When we collaborated with with the research team from Bank of Baroda, we found that:

In one such interviews that got access to - A branch manager said, “they will talk to me, but they will not touch the screen”

That line changed everything about how we approached the product build henceforth. The interface we needed was not a simpler form. It was no form at all.

Decisions, Trade offs & Prioritization:

Decision 1: Voice over forms, even simplified ones

We considered building a highly simplified visual interface - something like a few large buttons, icons, minimal text. We rejected it simply because we realized that this is still based on the assumption that the user understands what a field is and what goes in it. Voice requires nothing except the ability to speak. It is the only interface with zero literacy prerequisites. We chose voice not for novelty, but because it was the only design that actually removed the barrier.

Decision 2: Add ISL recognition, despite the complexity

Indian Sign Language recognition was the hardest technical decision in the build. The available datasets are sparse, inference is expensive, and adding it extended our timeline. We made the call for one reason: hearing-impaired users had exactly zero accessible options before this product. Building for voice only would have solved the problem for 90% of the target segment and abandoned the rest. That felt like a wrong compromise.