How to Validate a Startup Idea Before Building It

The most dangerous startup ideas are often the ones founders feel most confident about.

You see an inefficient process. You imagine a better way to handle it. The product starts taking shape in your head, and before long, you can picture the features, the interface, the company name, and the customers lining up to buy it.

Then you spend six months building it.

You finally get a meeting with an important prospect, deliver a polished presentation, and explain every brilliant detail. They smile, compliment the product, and tell you they’ll discuss it with their team.

Then you never hear from them again.

The problem wasn’t necessarily your presentation. The problem was that you developed the product in isolation. You became extremely good at explaining something the market never asked you to build.

There’s a much safer approach.

Instead of trying to invent the perfect idea, you can systematically discover what people already want. You can validate the problem, scope the product, build an initial customer base, and dramatically reduce the risk of failure before writing a single line of code.

I call this the Entrepreneur’s Discovery Process.

Product Discovery Starts With Conversations

Before you can build something valuable, you have to understand a market well enough to see what other people are missing.

Most founders assume that process begins with an idea.

It usually doesn’t.

It begins with conversations.

You don’t need decades of experience or a massive professional network to understand a market. You can become knowledgeable surprisingly quickly by systematically collecting information from the people already working in it.

Early in my career, I used this process to break into the Chicago real estate industry.

I was interested in a federal neighborhood redevelopment program, but I didn’t have any relevant connections or a clear path into the industry. What I did have was a publicly available list of organizations participating in the program.

So I started contacting them.

I sent roughly 70 letters and emails asking people to meet for coffee and tell me about their work. I wasn’t asking for a job, an investment, or any significant commitment. I was just asking for a conversation.

Several people agreed.

During those meetings, I didn’t try to impress anyone by pretending I knew more than I did. I explained what I was interested in, asked questions, and let them talk.

At the end of every conversation, I asked one more question:

“Is there anyone else you think I should talk to?”

That’s how the process compounds.

One conversation produces two or three introductions. Those conversations produce more introductions. With every round, you learn the terminology, understand the major players, and recognize the problems people repeatedly mention.

By the third round, I had spoken with dozens of people in a very specific niche. I knew where capital was moving, which projects were working, what frustrated people, and where they saw opportunities.

I wasn’t becoming an expert because I had spent years in the industry.

I was becoming an expert because I had systematically collected the knowledge of the people who had.

The same process can help you discover what product to build.

Start With a General Concept, Not a Finished Idea

Founders often feel pressure to present a fully formed vision.

Resist that pressure.

If your idea is too concrete at the beginning, you’ll probably focus on the wrong things. You’ll go too narrow too early and ignore valuable opportunities that sit just outside your original assumptions.

Start with a general concept instead.

You might say:

“Here’s the problem I’m interested in. Here’s the rough product I’m considering. It might include these features and work in this general way, but I want to understand whether this is actually valuable before I build it. Is this a real problem? How significant is it? Are there other problems in this area that would be more worthwhile to solve?”

Then stop talking.

You’re not there to pitch.

You’re there to learn.

Let the other person describe how the work actually gets done. Ask follow-up questions. Take detailed notes. When they use terminology you don’t understand, don’t pretend you know what it means. Ask them to explain it.

Every unfamiliar term, unusual process, manual workaround, and frustrated complaint gives you another piece of information that most people outside the industry don’t have.

At the end of the conversation, summarize what you heard and ask who else you should meet.

Then repeat the process.

Look for Important Problems People Hate

By your third or fourth conversation, patterns should begin to emerge.

You’ll hear the same problems described in slightly different ways. You’ll hear repeated complaints about the same workflows, systems, or limitations.

That repetition is what you’re looking for.

Some of the most useful questions you can ask are:

• What are the most time-consuming parts of this process?
• What are the most tedious or difficult parts of the workflow?
• What do you repeatedly do that feels like it should be automated?
• What part of the job does everyone hate doing?
• Where are mistakes most likely to happen?
• What existing tools have you tried?
• Have you created your own spreadsheet, template, or workaround?

You want to find work that is tedious, manual, repetitive, error-prone, and unnecessarily complicated.

But frustration alone doesn’t create a business opportunity.

A task can be extremely annoying without being important enough for someone to pay to fix. Another task might be strategically important but only happen once a year, making dedicated software difficult to justify.

The best opportunities usually combine four characteristics:

1. The problem is important.
2. It occurs frequently.
3. It consumes meaningful time or money.
4. The people performing it genuinely hate it.

When all four are present, you may have found something worth building.

Additional evidence makes the opportunity even stronger. Pay attention when people have already tried to solve the problem by purchasing software, hiring consultants, creating complicated spreadsheets, or building internal tools.

Those behaviors demonstrate more than interest.

They demonstrate intent.

Turn Your Research Group Into Early Adopters

After enough conversations, you’ll begin to see the shape of the product.

You may have spoken with 30 or 40 people by this point. That sounds like a lot when you begin, but those people are no longer just research subjects.

They’re potential early adopters.

They’ve helped shape the concept. They’ve explained exactly what bothers them and why existing solutions don’t work. They know you’re trying to fix a problem they care about, and many will become emotionally invested in seeing you succeed.

This doesn’t mean your product should solve every problem they mentioned.

It shouldn’t.

You still need to identify the highest-value opportunity and ignore everything else for now.

Write the simplest possible description of the first product:

“This product will help this specific type of user accomplish this specific task faster by doing these three things.”

That’s the level of clarity you want.

No giant product specification. No exhaustive feature list. No elaborate slide deck explaining what the company might become in five years.

Just a clear user, a clear task, and a clear improvement.

Then bring that description back to the people you interviewed.

Validate the Concept in Phases

Don’t send the same product concept to everyone at once.

That wastes the opportunity to improve it between conversations.

Instead, divide your contacts into small groups.

Show the initial concept to the first group and ask them to criticize it. They might explain that a required integration will be extremely difficult or that one part of the proposed workflow doesn’t match how the job is actually performed.

Use that information to revise the concept before taking it to the next group.

The second group may identify another weakness or suggest a simpler workaround. Revise it again.

Continue this process until you reach the final group.

The response should gradually change.

At first, you’ll hear:

“That sounds interesting, but…”

Later, you want to hear:

“Yes. That’s exactly what I’ve been looking for. When can I use it?”

That’s when you know you’re getting close.

You’re not trying to make the product sound clever or impressive. You’re trying to make it feel obvious.

The person hearing the description should immediately understand what it does, why it matters, and how it removes a painful part of their work.

When the concept feels obvious, move to mockups.

Validate Mockups Before Building the Product

Turn the product description into a few simple screens.

They don’t need to be beautiful. They don’t need to function. They only need to make the workflow concrete enough for people to react to it.

Take the mockups to the first group.

Ask them:

• Where does the workflow break?
• What is confusing?
• What is missing?
• What would you expect to happen next?
• Which part would you use most often?
• Which part would you remove?

Revise the mockups and show the improved version to the next group.

Repeat the process until the interface begins to feel as obvious as the product description.

Only then should you build the MVP.

By this point, you haven’t just asked people whether they like your idea. You’ve validated the problem, the proposed solution, the product scope, and the basic workflow through several rounds of increasingly specific feedback.

You also have a group of potential customers waiting to test it.

Choose Your Early Users Carefully

Not all feedback is equally valuable.

Founders often assume they should start with the person who has the most experience in the industry. Sometimes that works. But the most experienced person can also be deeply attached to the process you’re trying to replace.

In many professions, people build their identity around the difficult parts of their job—the complicated spreadsheet, the painstaking analysis, or the custom workflow only they understand.

To them, that pain isn’t waste.

It’s their value.

When you show them software that makes the process easier, they may instinctively reject it because it threatens how they’ve always defined their expertise.

That doesn’t mean you should ignore experienced users. It means you should be deliberate about who you involve first.

Look for two types of early adopters.

The first is the tech-savvy operator.

This person understands the workflow but isn’t emotionally attached to doing it the old way. They can imagine how technology might improve the process and will give you detailed feedback when the data is wrong, the workflow breaks, or the interface becomes confusing.

They help you build a better product.

The second is the top performer.

This is the person everyone else respects: the highest-producing broker, the most effective analyst, or the operator who consistently delivers the best results.

If you convince that person to use the product, you gain more than one customer. You gain credibility.

Other people see the top performer using it and think:

“If they’re using it, maybe I should try it too.”

The tech-savvy user improves the product.

The top performer accelerates adoption.

You need both.

Let the Market Pull the Product Out of You

Even after development begins, the discovery process doesn’t stop.

Release the MVP to a small number of users. Watch them use it. Find what breaks. Identify what confuses them. Fix the highest-value issues, then bring in the next group.

The process remains the same at every stage:

Conversation.
Feedback.
Refinement.
More conversation.
More feedback.
More refinement.

That’s how you move from a vague idea to a product people actually want.

You don’t lock yourself in a room and guess your way there. You don’t spend months perfecting a presentation based on untested assumptions. You don’t make one enormous bet and hope the market agrees with you.

You let the market pull the product out of you, one conversation at a time.

By the time you write the first line of code, the product should no longer feel like your idea.

It should feel inevitable.