What Is Foundational Research — And Why It's the Most Skipped Step in Product Development
- 6 days ago
- 6 min read
There's a pattern we see constantly.
A team has an idea. They're excited about it. They've talked about it internally, they've looked at what competitors are doing, maybe they've read some industry reports. They feel ready to build.
So they start designing. Or they commission a usability study on an early prototype. Or they run a survey to validate their assumptions.
And somewhere in there, they skip the most important step entirely.
They never actually asked: do we understand the problem well enough to be solving it at all?
That's what foundational research is. And it's the most commonly skipped phase in product development, often by teams who are otherwise doing everything right.
So what actually is it?
Foundational research goes by a few names. Discovery research. Exploratory research. Generative research. The terminology varies, but the purpose is the same.
It's the research you do before you know what you're building. Before there's a prototype to test. Before there's even a clear brief. It's the work of understanding people, contexts, and problems deeply enough to make informed decisions about where to focus.
It's not asking "does this design work?" That's evaluative research and it comes later.
It's not asking "would you use this feature?" That's validation and it also comes later.
Foundational user research asks much earlier, messier questions. What is actually going on in this user’s life? What are they trying to do? What gets in the way? What have they tried before? What has worked for them earlier?
The answers to these questions are what everything should be built on. But because they're slow to get and hard to quantify, they're the first thing that gets skipped when timelines tighten.
Why do teams skip it?
The honest reason is usually speed.
There's pressure to move fast. There are deadlines. There are stakeholders who want to see progress. And foundational research in product development often doesn’t offer immediate, tangible proof of progress in the way execution-focused outputs do. What it builds instead is clarity and understanding — which can be harder to capture in a roadmap update or a presentation.
A usability test produces clear findings. "Users couldn't find the button. We moved the button. Problem solved." That's satisfying. It shows up in a report. It gets acted on.
Exploratory user research produces things like "we think we may have been solving the wrong problem." Which is the most valuable thing a team can discover, and also the hardest thing to present to someone who just approved six months of development.
There's also a confidence problem. Teams that are close to their domain often feel like they already understand their users. They've been in this space for years. They've talked to customers. They have instincts.
And sometimes those instincts are right. But they're often partial. They're based on the customers who spoke up, the feedback that came in, the problems that were visible. Discovery research surfaces the problems that were invisible. The needs that users couldn't articulate because nobody thought to ask about them in the right way.
What does it actually look like?
Foundational research is almost always qualitative. You're not trying to count things. You're trying to understand them.
The core method is usually in-depth user interviews. Long conversations with real users about their lives, their behaviours, their contexts, their workarounds. Not "what do you think of our product?" but "tell me about the last time you needed to do X. What happened? What did you do? How did that go?"
Alongside interviews, there's often contextual inquiry and observation. Going to where users actually are and watching what they do in their real environment, not in a lab, not on a Zoom call. Sitting in someone's home. Watching how they use their phone. Noticing the things they don't mention because they're so normal to them that they don't think to say them.
There are other qualitative research methods too. Diary studies. Ethnographic fieldwork. Participatory design sessions. The right approach depends on what you're trying to understand and who you're trying to understand it about.
What all of these have in common is that they take time and they produce messy data. Transcripts. Notes. Observations. Patterns that emerge slowly across multiple conversations. It's not clean or quick. It's also the closest you can get to understanding what's actually going on.
What does it produce?
The output of foundational research isn't a report that tells you what to build. That's a common misconception.
What it produces is a grounded understanding of the problem space. A clear picture of who your users are, what they actually need, what the context looks like, and where the real friction is. From that understanding, you can make better decisions about what to build, how to prioritise, and where not to waste time.
It often produces things that reshape the brief entirely. We've seen discovery or exploratory research reveal that the problem a team was trying to solve wasn't the problem users were experiencing at all. That the assumed user was only a small part of the actual user base. That a workaround users had developed themselves was actually more useful than the feature the team was planning to build.
These aren't failures. They're exactly the point. Finding out early is always better than finding out after launch.
Why does it matter more in India?
If you're building for India, this is worth thinking about carefully.
India is an enormous, extraordinarily diverse market. The assumptions that seem reasonable when you're sitting in a Bangalore or Mumbai office often don't hold up in Jaipur, Patna, or Coimbatore. Language, context, literacy, trust, aspiration, access to technology, family dynamics, the way decisions get made, what "value" means to someone, what "risk" feels like — all of this varies dramatically across geographies, communities, and generations.
User research in India is how you get a real picture of that complexity rather than a simplified version of it. Not because you need to understand every variation, but because you need to understand enough to know what you don't know.
Foundational research in the Indian market is especially important for products targeting users outside the top metros. The tier 2 and tier 3 user behaves, decides, and experiences products in ways that no amount of internal assumption can accurately predict. The only way to know is to go and find out.
Teams that skip this step and build on assumptions end up with products that work for a narrow slice of the market and miss everyone else. In a market this large, that's a lot of people to miss.
The question that changes everything
There's one question that foundational user research is really designed to answer, and it's one that most teams never formally ask.
Do we understand the problem we're trying to solve well enough to be confident we're solving the right one?
Not "do we have a good solution." Not "have we talked to some customers." Not "are we moving fast."
Do we actually understand this?
In most cases, the honest answer is partial. Teams understand parts of the problem well and other parts not at all. Exploratory research in product development is how you fill in the gaps before they become expensive.
The teams that do this well aren't the ones who slow down for the sake of slowing down. They're the ones who understand that the time spent at this stage pays back later, when they're not rebuilding things, not launching to silence, not wondering why the product that seemed so obvious internally isn't landing with the people it was built for.
A practical note
If you're early in a product cycle and you haven't done foundational research yet, it's not too late. Depending on where you are, it might reshape your approach or it might confirm that you're on the right track. Either outcome is useful.
If you're further along and something isn't working the way you expected, the answer is sometimes to go back to this stage. Not as a failure, but as the thing that should have happened earlier and can still happen now.
The questions foundational user research asks don't expire. Who are our users, really? What are they actually trying to do? What does the context look like?Are we missing anything?
These are worth asking at any stage. And almost always, the answers are worth knowing.
At User Connect Consultancy, foundational research is where most of our engagements begin. If you're building something and want to start from a place of genuine understanding rather than assumption, we'd be glad to talk.
Comments