If You’re So Sure Your Users Want It… Why Aren’t They Using It?

It’s a classic early-stage startup scenario:
A founder is absolutely convinced their users need a new feature. They skip research, go straight into building… and launch with excitement, only to hear crickets.

No one uses it.

It happens all the time, and most of the time, it could have been avoided with just a little bit of user research.

You Don’t Need Fancy Research

I get it. Early-stage startups often lack the resources for lengthy, detailed research projects. You might not have a UX researcher on the team, or even a designer.

But here’s the good news:
Some research is better than none.

Even lightweight, scrappy validation can make a world of difference, and it’s often faster and cheaper than rebuilding features later.

🧠 How Can I Do It?

There are plenty of low-cost, low-effort ways to validate your ideas before jumping into code:

• Talk to your existing users. They already use your product and have valuable insights.

• Post polls or surveys in relevant communities or on social media.

• Use survey platforms like Typeform, Google Forms, or even pay a small fee to send surveys to a targeted audience via tools like Pollfish or user research panels.

🧮 How Many People Do I Need?

Spoiler: You don’t need hundreds.

According to research by NN Group and Maria Rosala, you can start learning meaningful patterns from just 5 to 30 participants, depending on:

• The number of distinct user personas

• How niche your market is

• Your interviewing experience

Start small and iterate.

❓ What Should I Ask?

If there’s one resource I recommend on this, it’s The Mom Test by Rob Fitzpatrick. It radically changed how I approach user interviews.Here’s the gist:

Don’t ask people what they will do. Ask them what they have done.

Bad questions sound like:

• “Would you use this feature?”

• “Do you like our app?”

These are future-based and unreliable.

Good questions focus on past behavior:

• “When was the last time you faced [problem]?”

• “What did you do to solve it?”

• “Have you paid for a solution? Why or why not?”

💡 Rule of thumb: ask about the past, not the future.

🗣️ But Wait… Didn’t Steve Jobs Say Customers Don’t Know What They Want?

Yes. And he wasn’t wrong.

But there’s a difference between asking users to design your product (bad idea), and asking them to describe their problems and context (great idea).

Your users might not know what the solution should look like. That’s your job. But they do know what frustrates them, and that’s where you start.

⚡ Isn’t It Faster to Just Build and Test?

Sometimes! If you can prototype and test your idea in hours or a couple of days, then go for it. But don’t confuse prototyping to learn with shipping a full feature.

The moment you’re investing weeks of dev time into something unvalidated, you’re taking an expensive gamble.

Instead, try this approach:

• Validate the problem through user interviews or surveys.

• Sketch out a low-fidelity solution.

• Get early feedback before building anything at scale.

Why It All Matters

When you validate your ideas before building:

• You reduce wasted dev time

• You increase the chances that your features actually get used

• You build stronger product-market fit over time

It’s not about slowing down. It’s about moving smarter.