The biggest mistake I made while talking to potential customers
When I first started speaking with founders, I thought my job was to explain my product.
I quickly realized that wasn't what people wanted.
The best conversations happened when I spent most of the call asking questions instead of giving answers.
Sometimes a 30-minute call would end without a demo because I learned something that completely changed how I thought about the problem.
One founder even told me:
"Don't solve the problem I describe. Solve the reason the problem exists."
That advice changed how I approach customer interviews.
Now I try to understand:
What process breaks first as a business grows?
What work is still being done manually?
What frustrates people every week that they've simply accepted as "normal"?
Those conversations have been far more valuable than any feature request I've received.
I'm curious how other makers approach this.
What's the single best question you've asked a customer that changed the direction of your product?
Replies
what question gave you the biggest breakthought? @shahroz_siddique
@george_rosevear For me, it was a simple one:
"What's the most repetitive task your team does every single week?"
Almost no one answered with "attendance" or "time tracking." Instead, they talked about chasing updates, fixing spreadsheets, preparing payroll, and following up with managers. That completely changed how I thought about the problem. People don't buy software for features. They buy it to eliminate recurring operational headaches.
WebCurate.co
For me, it was simply asking, "How are you solving this today?"
The answer usually tells you much more than asking what features they want.
@hosseinyazdi I completely agree. I've found that asking how someone is solving the problem today often reveals the real bottleneck. It also shows what they've already invested in, what they're willing to tolerate, and what would actually make them switch. Those insights are usually far more valuable than a feature wishlist.
Hi Shahroz, the one that changed direction for me was "What have you already tried, and why did you stop using it?" It showed that people had tried the obvious solutions and quietly given up on them, so the real work was not adding a feature, it was avoiding the reason they walked away last time.
@alieksia That's a great question. We've found something similar while talking to companies evaluating Trackly. Asking what they tried before and why they stopped often reveals more than asking what features they want. Most of the time, the issue isn't missing functionality. It's that the previous solution was too complex, didn't fit their workflow, or created more work than it saved. Those conversations have had a big impact on how we continue improving Trackly.
@shahroz_siddique There is a book that helped me a lot with customer communication - "The Mom Test: How to Talk to Customers & Learn If Your Business Is a Good Idea When Everyone Is Lying to You" by Rob Fitzpatrick
I have started asking "What are you doing manually right now that you wish didn't have to", it gets people to talk about the actual pain point instead of the feature they think they want.
@samran_rezunate_llm I like that question. It shifts the conversation away from feature requests and toward real workflows. We've found that the manual tasks people mention are often symptoms of a bigger operational issue, and solving that root problem usually delivers much more value than simply adding another feature.
Shahroz, the question that changed things for me was not about my product at all. I started asking founders running more than one thing at once, a service business, a second location, a side venture, what they were most afraid they were about to miss while dealing with whatever was loudest that day. Almost nobody answered with a big strategic gap. It was always something quiet, a slow paying client, a task nobody owned, a signal that had not turned into a fire yet. That answer became the reason I am building FounderFlow. What surprised you most about the gap between what founders said they needed and what they actually needed?
@stacywycof83995 That's a great insight. We've seen something similar. Founders often ask for better reporting or more visibility, but after a deeper conversation, the real issue is usually that important information is scattered across different places, making it hard to act quickly. The problem wasn't missing data, it was missing clarity. Those conversations definitely changed how we think about building Trackly.
Missing clarity explains a lot of the freezing founders do. They can see the data but not what it means for today, so they default to whatever is loudest instead of whatever actually matters. That is the gap I am building FounderFlow to close. Are you finding founders want more dashboards to fix this, or are they starting to ask for something that just tells them the answer directly?
@stacywycof83995 I think they're asking for fewer dashboards and more actionable insights. In our conversations around Trackly, managers rarely ask for more charts. They want to know who's on site, what needs attention today, and whether anything requires action. The data is important, but presenting the right insight at the right time is what actually helps people make better decisions.
@shahroz_siddique That lines up with what I am seeing too. The founders I talk with do not want another chart, they want someone to just tell them the one thing that needs attention today. Curious whether Trackly is moving toward giving that direct answer, or if managers still expect to open a dashboard first before they trust it.
@stacywycof83995 That's exactly the direction we're moving in with Trackly. Managers still value having a dashboard, but they don't want to spend time figuring out what matters. They want to open Trackly and immediately know who's on site, who's missing, and what needs attention today. The dashboard should support the decision, not become the decision.
@shahroz_siddique That distinction matters more than most dashboards admit. The moment a manager has to open something to go find the answer, part of the value already leaked out of the day. Curious how Trackly decides what counts as needing attention today versus what can wait, is that ranked by the system already, or does the manager still have to make that call once they open it?
Good distinction. The signal isn't just what a customer asks for, but what changed in their workflow, why the old approach stopped working, and what evidence would show the new path helped.
We’ve built Zentrik Loops around keeping that reason attached to the decision as it moves into delivery, so the next review starts from customer context rather than a decontextualized feature request.
How well are you keeping those interview insights connected to the decisions the team actually makes?