How to Research When You Don't Have Users Yet

You have an idea for a product. You know you should talk to users before building it. But you don't have users yet—because the product doesn't exist.

This chicken-and-egg problem stops a lot of great ideas before they start. How do you research something that doesn't exist for people who don't exist yet?

Here's how I've learned to do meaningful cost-effective user research methods in the earliest stages of product development.

Start with the Problem, Not the Solution

Most people research their solution: "Would you use an app that does X?" or "What do you think of this feature?"

But solutions are hypothetical. Problems are real.

Instead of asking people to imagine using your non-existent product, ask them about their existing struggle with the problem you're trying to solve.

Bad questions:

• "Would you use a meal planning app with AI-enhanced UX design recommendations?"
• "How much would you pay for automated expense tracking?"
• "What features would you want in a project management tool?"

Good questions:

• "How do you currently decide what to cook for dinner?"
• "Walk me through how you track business expenses now."
• "What's the most frustrating part of managing projects at your company?"

People can tell you exactly how they currently struggle. They can't tell you how they'd use a solution they've never tried.

Find Your Proto-Users

You might not have users of your product, but you can find people who experience the problem you're trying to solve.

I call these "proto-users"—people who represent your eventual user base, even though they've never heard of your product.

Where to find proto-users:

• Reddit communities where people discuss the problem
• LinkedIn groups related to your target industry
• Facebook groups for people in your target demographic
• Twitter hashtags where people complain about the problem
• Your personal network (ask friends to introduce you to relevant people)
• Existing product reviews where people describe current solutions' shortcomings

The key is finding places where your target users are already talking about the problem you want to solve.

Study Their Current Workflow

Instead of asking people what they want, observe what they currently do.

Every product replaces or improves an existing workflow. Understanding that current workflow is your roadmap to a better solution.

What to document:

• What triggers them to start the task?
• What tools do they currently use?
• Where do they get stuck or frustrated?
• What workarounds have they created?
• How do they know when they're done?
• What happens if they make a mistake?

The gaps and friction points in their current process are your product opportunities.

Listen to Their Language

Pay attention to the exact words people use to describe their problems and current solutions.

This isn't just for marketing copy—it's for understanding how they think about the problem space.

What to capture:

• What do they call the problem? ("managing projects" vs. "keeping track of tasks")
• How do they describe pain points? ("it's a nightmare" vs. "it's inefficient")
• What words do they use for current solutions? ("tool" vs. "platform" vs. "system")
• How do they talk about ideal outcomes? ("faster" vs. "easier" vs. "more reliable")

When you use their language in your product, it feels familiar instead of foreign.

Validate with Paper Prototypes

You don't need a working product to test core concepts. Paper prototypes and wireframes can validate your biggest assumptions.

What you can test with low-fidelity prototypes:

• Does your mental model match theirs? (Do they understand your information architecture?)
• Are you solving the right problem? (Do they care about the outcomes your product promises?)
• Is your solution approach viable? (Can they complete key tasks with your proposed workflow?)
• What are you missing? (What questions do they ask that your design doesn't answer?)

I've killed bad ideas and improved good ones using nothing but sketches and conversations.

Analyze Competitor Reviews

Your competitors' users are your potential users. Their reviews are a goldmine of research data.

What to look for in reviews:

• What do people love? (These are table stakes for your product)
• What do they consistently complain about? (These are your opportunities)
• What workarounds do they mention? (These reveal unmet needs)
• Why do they switch to other products? (These are critical failure points to avoid)
• What do they wish existed? (These are potential features)

Read reviews on App Store, Google Play, G2, Capterra, Amazon—anywhere your target users might leave feedback about existing solutions.

Run Assumption Mapping Workshops

List out every assumption you're making about users, their problems, and your solution. Then prioritize which assumptions are riskiest to be wrong about.

Categories of assumptions:

• User assumptions: Who they are, what they do, how they behave
• Problem assumptions: What problems they have, how painful those problems are
• Solution assumptions: What kind of solution they want, how they'd use it
• Business assumptions: What they'd pay, how they'd discover your product

Test your riskiest assumptions first. If you're wrong about who your users are, nothing else matters.

Create Lean Research Plans

You don't need a PhD in user research to ask good questions. You just need a plan.

My simple research session structure:

1. Background (5 minutes): Who are they and what's their context?
2. Current state (15 minutes): How do they currently handle the problem?
3. Pain points (10 minutes): What's frustrating about their current approach?
4. Ideal state (10 minutes): If they could wave a magic wand, what would be different?
5. Concept reaction (15 minutes): Show them your prototype and listen to their response
6. Wrap-up (5 minutes): Any questions they have for you

Keep sessions conversational, not interrogational. You're trying to understand their world, not validate your ideas.

Start Small, Iterate Fast

You don't need to talk to 100 people. Start with 5-8 conversations. Look for patterns in their responses:

• What problems do they all mention?
• What solutions do they all currently use?
• What outcomes do they all want?
• What concerns do they all express?

Use those patterns to refine your concept, then test with another small group. Iterate your way to clarity.

The Real Goal

The goal of early-stage user research isn't to validate that people will love your product. It's to understand the problem space well enough to build something people actually need.

Most products fail not because they're poorly built, but because they solve problems that don't exist or solve real problems in ways that don't fit how people actually work.

You can't research your way to a guaranteed hit. But you can research your way out of building something nobody wants.

And that's a pretty good starting point.