Your Product Doesn't Need More Features. It Needs More Questions.
One thing I've noticed while working on a SaaS product is that people rarely ask the question we expect them to ask.
We spend days thinking about features.
Users spend seconds wondering whether the product solves their problem.
They're not asking:
"Does it support multiple workspaces?"
They're asking:
"Can this save me time tomorrow?"
The more products I look at, the more I think builders and users look at software in completely different ways.
As builders, we naturally focus on what we made. We know how difficult the architecture was, how many edge cases we handled, and how much work went into polishing a feature.
Users don't see any of that.
They only see the question they came to answer.
That changed how I look at product pages.
Instead of asking, "What features should we highlight?"
I've started asking, "What question is the visitor trying to answer?"
Sometimes it's:
"Will this work with the tools I already use?"
Sometimes it's:
"Can I trust the numbers?"
Sometimes it's simply:
"Is this actually faster than doing it myself?"
I've found those questions are usually more valuable than another feature announcement.
I'm still figuring this out, but it's made me spend less time adding things and more time removing uncertainty.
Curious if anyone else has noticed the same thing while building.
The best homepage question I found for DictaFlow wasn't "how accurate is the transcription model?" It was "will this type into the app I'm already using?" That changed the page from a feature list into proof about the last mile: cursor insertion, Citrix, and stubborn apps. Support emails and search queries have helped more than asking people what feature they want, because their own words show the doubt they have.
The question framing maps exactly to how good discovery works in sales. You stop presenting features and start identifying what question the buyer needs answered before they can say yes.
For my Chrome extension I spent months obsessing over the feature list. Then one user said "I just want to know if I can stop using my keyboard for emails." That one sentence rewrote the homepage. The feature didn't change. The question it answered became visible.
"Removing uncertainty" is exactly the right way to put it. Most product pages add more information when what users need is less to be unsure about.
This resonates with me - I spent months building features nobody asked for until I started doing weekly customer interviews, and suddenly the roadmap became obvious. How do you handle users who give wishy-washy answers when you ask them what they actually need?
This resonates a lot — with Nexmetra I kept adding tools thinking "more utility = more value," but the real question visitors have is usually just "will this measurement be accurate right now, without signing up?" Once I started designing around that instead of feature lists, homepage copy and even tool UX got a lot simpler. "Remove uncertainty" is a better north star than "add features."
Absolutely agree. Reducing uncertainty is one of the biggest values a product can provide. In SEO, users don't just need reports; they need answers about what is blocking growth. That's the idea behind SerpSpur — turning technical SEO insights into practical actions.
Agree with the direction. A question that often beats “what feature should we build?” is: “what did you try right before you looked for this?” It reveals the real workflow and the competing alternatives, which usually matters more than the requested feature list.
"This is exactly what I've been learning with Rallynex — I spent weeks adding features I thought people wanted, but the moment I started asking real founders what they actually struggled with, I realized I was building solutions to problems nobody had.
The shift from 'what should I build next?' to 'what are you stuck on right now?' changed everything for me.
What's been the most surprising thing you've learned from asking questions instead of building features?"
This is exactly what I’ve been learning while building AI SUPERTEAM by StaffedByAI
At first, I wanted to explain every tool, feature, automation, and AI capability because I knew how much work went into building them. But the customer is not thinking about the architecture.
They’re thinking:
“Can this help me get more customers?”
“Can this save me from doing five different jobs?”
“Can I actually use this without being highly technical?”
That realization changed how I describe the product. Instead of leading with everything AI SUPERTEAM can do, I’m trying to lead with the result: helping small-business owners market, capture leads, follow up, and manage more of their business without hiring an entire team.
You’re absolutely right—removing uncertainty may be more valuable than adding another feature.
What is the biggest question your visitors are trying to answer before they sign up?
This resonates hard. I just caught myself adding a “voice cloning studio” feature to my app when I should have been asking: “Does anyone actually want to clone their voice locally?”
The feature felt productive to build. The question felt scary to ask. That’s the tell.
I’m forcing myself to ship the current version as-is and ask 10 users what they’d use it for before I build anything else. If 8 of them say “I just want to type text and get audio,” then the studio mode was a waste of time. If 6 of them say “I wish I could use my own voice,” then it was the right call.
Questions > features. But only if you’re willing to hear the answer.
That shift makes sense. The harder part seems to be knowing whether you’ve identified the question the visitor actually has, or just written a more customer-shaped version of your own assumption.
How are you distinguishing between the two?
Absolutely agree.
And its something I need to explain at least once a week. Collegues always want to add something with the reason "the customer needs this", in about 8/10 cases the customer wants the reduction of friction, better insights in data already there or a problem solved, not a feature per se. Always asking first now what issue they try to solve and than think about a solution.
The reframe that stuck with me: users don't buy features, they buy the removal of a recurring annoyance. I ran into this building a browser tool — polite feedback was almost always a feature request, but the decisive signal was people describing the same pain unprompted, twice. Weigh actions over words and the right feature list writes itself.