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.
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.