A research practice, not a research project

The scale

Across a decade and several companies, I’ve run field research as a standing practice, not a string of one-off studies. Hundreds of interviews and contextual visits, often deep in tier-2 and tier-3 markets, strategised and led in-house without external agencies. The count was never the point. The point is that it ran continuously enough to be treated as infrastructure, not a project with a start and end date.

Two findings that changed the product

The clearest way to explain what research is for is to show it changing a decision.

At MoveinSync we set out to build GetToWork, a B2C commute product for people in Bangalore whose offices didn’t provide transport. Our assumption was simple: copy Uber and Ola, but fix the one thing they couldn’t guarantee, a booking secured in advance with a cab you could count on. Guaranteed availability was a real pain, and we were right that it mattered. What the field told us is that it wasn’t enough. People wanted the whole commute to feel like a professional’s morning: a clean car, a driver who didn’t take calls or play loud music, a premium vehicle, arriving on time for work and leaving on time after. Covid killed the product before we could prove it out. But look at what’s thriving now, Uber Black, Shoffr, the premium commute category. The users were right. We just got interrupted.

At Rupifi the trigger was a revenue crunch. The obvious move was to build more products for our existing users, retailers. Research pushed back on the framing itself. The problem wasn’t the retailer in isolation, it was the whole chain around them, distributors, super stockists, brands, each carrying its own broken workflow. Solving for that chain wasn’t a detour from revenue. It was a new revenue line and a pipeline of new retailers for the products we already had. Rupifi Payments came directly out of that finding. The research didn’t answer the question we asked. It corrected the question.

How I actually run it

I run research lean and guerilla, and I’ll defend that against the textbook. I would rather talk to a handful of the right users this week and find the real issue than spend a month assembling a statistically significant sample to confirm something a few conversations would have surfaced. Significance has its place. Speed usually finds the problem first.

The bigger choice is who does the research. I don’t hire a big research team. I train the people we already have, across engineering, data, marketing, and finance, to sit in sessions and run them. It costs less, but that’s not the main reason. When an engineer watches a real user struggle with the thing they built, no research report can compete with that. They stop needing to be convinced a problem is worth fixing, because they’ve seen it. Research stops being a document I circulate and becomes a thing the whole team has witnessed. The people who usually never meet a user turn into the ones arguing hardest to fix their problems.

Why frame it as investment

Research gets cut first when it’s filed as a cost, a nice-to-have before the real work starts. Framed as an investment, it has to return something, and it does. One field programme feeds several roadmaps, not just the team that ran it. That’s the version that stays funded through a lean year, and it’s the honest version too, because it’s true.

The repository

All of it lives in one place, findings tagged by product and theme, so a new question can often be answered by re-reading before anyone commissions a new study. That store is the actual difference between research as an event and research as a practice.