How 500+ User Conversations Changed the Way I Take Product Decisions
- Tushar
- Dec 12
- 5 min read
When people hear “500+ user conversations,” they imagine a massive research project. In reality, these conversations were spread across five years, across multiple product contexts, and across different motivations - discovery, validation, feedback, UAT, rejection, and diagnosis.
These conversations ultimately changed how I judge problems, how I evaluate user claims, and how I decide whether a feature deserves even a single hour of engineering bandwidth or not.
Table of Contents
It's not necessary that Good Decisions Come from “Clear Requirements”
When I started as a founder at Sangeeta Enterprises, I assumed you build a good product or business by:
understanding your users,
designing a solution,
executing well,
improving over time.
But when I started speaking to real users (customers, merchants, staff, sales teams, delivery agents, operators) over the last 5+ years, I observed this:
People rarely tell you the truth directly but when you dig deeper in the conversations, their behaviour always does.
That discovery completely rewired how I make product decisions.
Behaviour Reveals What Words Hide
The shift began with a simple anomaly, after the first COVID wave, I noticed something unusual in my e-commerce business:
There was a sudden decline of orders that were spread across 24 hours of a day
85% of orders were coming between 4 PM and 11 PM
Ads were exhausting their daily budget before 4 PM, yet did not convert
This pattern continued for months and started right after couple of months of market reopening
Something wasn’t adding up and it made me curious that why is this happening in a very set pattern. So I decided let's start calling recent customers and try to understand "their buying behaviour". I spoke to 30+ customers and those conversations literally blown away my mind, as the insight that came out was something no-tool would have told me. Most of my buyers (predominantly married women with children) said:
During the day, their phones are now with their kids for school and education purposes
The kids would study on phones until 4-5 PM and only after that, mothers would get time to access their phones.
Once they used to get their phones back, they would browse, search, evaluate and purchased homeware products
This single behavioural insight led to one of the simplest but highest-ROI decisions I ever made:
I scheduled ads from 3 PM to 12 AM
Result: 25% increase in orders without increasing ad spend.
No amount of analytics could have revealed this. Only conversation could.
Real Problems Hide Behind Operational Pain
When I worked on a social commerce application, the discovery conversations kept revealing the same pain:
Small businesses selling through Instagram or WhatsApp were wasting hours every day in:
recording orders manually
tracking payments in different apps
booking shipments
sharing tracking updates
collecting feedback through screenshots
Individually, these steps looked manageable. But when you saw the full workflow, the real problem became obvious: They were running an entire business without a system. This led to three core product decisions:
1. Build a simple Sales Recorder
Not a CRM. Not a dashboard, a single sitting place for orders, customer details, notes, and catalogues.
2. Build India Post Shipping
Users repeatedly said, “We prefer India Post because we don’t have printers.”Once I investigated further, the insight became clear:
Merchants with <30 orders/month didn’t want to invest in printers
Without shipping labels, they were ineligible for private courier aggregators
India Post was their only viable option
This shaped the entire shipping architecture - what to build, what not to build, and why.
3. Fix account creation friction
Thousands downloaded the app. but very few created accounts. Analytics showed the drop-off point but only conversations explained why:
They were unsure whether the product was even meant for them.
They saw the AD about our app while playing some games, and they downloaded the app purely to earn some points in the game.
These valuable insights could have That insight helped redesign onboarding to clarify value in the first few seconds.
Stakeholders Are Also “Users”
During my time working on a complex enterprise onboarding system, I faced a completely different challenge:
One onboarding request passed through five teams, each with its own tools, processes, grievances, and interpretations. Speaking to every stakeholder - sales, risk, bizops, operations, setup — revealed:
hidden manual steps no one had documented
data mismatches that caused silent failures
unspoken dependencies between teams
contradictory definitions of “done”
Only after hundreds of conversations could we break the entire onboarding flow into layers, identify true bottlenecks, and redesign the system to achieve a 7-day turnaround instead of 21. This taught me something important:
A product is not only used by end-users.
It is also used by the teams who operate it.
Ignore them, and the product fails quietly.
The Value of Rejecting Ideas Early
Multiple times, research saved months of waste.
Case: The Home Management App
The assumption: Homeowners needed a way to delegate tasks and track progress digitally.
Reality from conversations:
In metro cities, most staff didn’t own smartphones
Families preferred simple communication — calls, sticky notes, direct instructions
The “problem” wasn’t painful enough for behaviour change
These conversations helped the founder refine the target audience and adjust expectations before spending more money.
And this reinforced another principle: User conversations are not just for finding what to build. They are for finding what not to build.
The Real Skill Is Recognising Patterns Early
By this stage, I noticed something consistently: across different products, industries, and users, insights developed a predictable structure. I now look for 4 signals:
1. Frequency
If a pain shows up in 30% of conversations, it’s noise. If it shows up in 70%, it demands attention.
2. Intensity
Are users just mentioning the problem? Or are they actively taking painful steps to solve it? If the user isn't solving it themselves, it is rarely a real problem.
3. Action
What is the user doing today — even if it’s a workaround? Actions reveal priorities.
4. Effort
If a user is willing to take a 5-minute action to solve a pain, it is meaningful. If not, the problem is not big enough — yet.
This is why 25–30 strong interviews, done properly, are enough to validate or reject your hypothesis.
My Biggest Shift After 500 Conversations
If I summarise everything into one sentence, it is this:
Product decisions become simpler when you stop chasing answers and start studying behaviour.
Conversations are not for validation. They are for understanding the lived reality of a user. Once you see their world clearly —the right problem, the right solution, and the right sequencing become obvious.
If You’re Working on an Idea, This Is the Hard Truth
You cannot validate a problem from your desk. You cannot judge an idea by how “exciting” it sounds. And you absolutely cannot rely on assumptions, even your own.
Talk to your users. But more importantly, learn to interpret what their behaviour is signalling.
Comments