<h2>Every Idea Begins With a Problem</h2>
Before you write a single line of code, before you register a domain, and definitely before you pitch to investors - you need to validate the problem you’re trying to solve.
In product development, this early step is called the Problem Stage. It sounds simple: “I found a problem, now I’ll solve it.”
But the reality is, most builders rush past this step. They assume the problem is real, assume people want a solution, and assume they know how to deliver it.
Let’s break that chain of assumptions.
In this guide, drawn from a practical teaching session, we’ll walk through what it really means to validate a problem, how to do it, and how to move toward building either a service or a product - the right way.
<hr>
<h2>Understand the Problem Stage</h2>
Let’s say you’re a hacker, or a builder, and you think: “I’ve got a problem worth solving.”
That’s the starting point - the problem stage.
But not all problems are worth solving. Some are:
<ul>
<li>Not real (just annoyances that don’t matter to others)</li>
<li>Not solvable (like teleportation to America)</li>
<li>Not feasible (even if solvable, the solution might be too expensive or slow to implement)</li>
</ul>
That’s why validation is critical.
<hr>
<h2>What Does Validation Really Mean?</h2>
Validation answers three core questions:
<ol>
<li>
Is the problem real?
Do people actually experience it? Is it painful enough for them to care?
</li>
<li>
Is the problem solvable?
Can you realistically build or offer something to fix it?
</li>
<li>
Is it feasible?
Can you deliver this solution affordably, reliably, and at scale?
</li>
</ol>
Only if all three check out can you move forward.
<hr>
<h2>Talk to Real People</h2>
The best way to validate a problem? Conversations.
Talk to potential users, industry insiders, even strangers online. Ask open-ended questions:
<ul>
<li>Have you faced this problem?</li>
<li>How do you deal with it currently?</li>
<li>Would you pay for a solution?</li>
</ul>
Don’t guess. Ask.
<h3>Online Validation Tactics</h3>
Thanks to the internet, talking to people is easier than ever. Try:
<ul>
<li>Social media posts: Share the problem publicly. See if others relate.</li>
<li>Communities and forums: Like Discord servers, niche Slack groups, Reddit? Reddit is still cool right?</li>
<li>Cold outreach: DM people on LinkedIn, email small businesses, or set up casual interviews.</li>
</ul>
Even a tweet like: “Anyone else find it annoying to book hotels in Islamabad?” can tell you a lot.
<hr>
<h2>Use the “Build in Public” Model</h2>
Posting your idea or problem statement online isn’t just marketing - it’s validation.
When you openly say:
<blockquote>
“This problem exists. Do others feel the same?”
</blockquote>
You can learn:
<ul>
<li>If people relate to the problem</li>
<li>If people react with interest</li>
<li>If people recommend solutions</li>
</ul>
That’s data. And that’s your early signal.
<hr>
<h2>Validate with Communities, and Experts</h2>
If you have access to communities or investors, go deeper:
<ul>
<li>Ask them, “Do you think this is a real problem?”</li>
<li>Ask, “How do you see others solving it?”</li>
<li>Ask, “Would you or others pay for this solution?”</li>
</ul>
This is basically a user interview. And you should treat it like gold.
Even if you’re not building a startup, these insights will save you months of wasted effort.
<hr>
<h2>Use Multiple Validation Channels</h2>
There’s no single way to validate. Use a mix:
<ul>
<li>Blog about it: Share a problem breakdown and ask for feedback.</li>
<li>Surveys: Use Google Forms or Typeform to collect structured responses.</li>
<li>Cold calling or messaging: Talk directly to your target persona.</li>
<li>Contextual observation: Watch how people behave around the problem.</li>
</ul>
Big companies do this every day - often without you noticing.
<hr>
<h2>From Validation to Execution: Service or Product?</h2>
Once you validate the problem is real and solvable, the next question is:
Do I build a service or a product?
Here’s a golden rule:
<blockquote>
It’s often easier to start with a service.
</blockquote>
Why?
<ul>
<li>You don’t need a dev team or huge investment.</li>
<li>You can test directly with users.</li>
<li>You can refine your process before automating it.</li>
</ul>
<h3>Example: Hotel Booking in Islamabad</h3>
Let’s say you validate this:
<blockquote>
“People hate booking hotels in Islamabad. It’s inefficient, confusing, and time-consuming.”
</blockquote>
What can you do?
<ul>
<li>Start with a service: Offer to book hotels for them - a concierge-style approach.</li>
<li>Test manually: Stand outside hotels and ask people what issues they faced.</li>
<li>Build trust: After a year or two, turn your service into an app.</li>
</ul>
This is how many platforms like Airbnb evolved. From service → product.
<hr>
<h2>Understanding Feasibility</h2>
Feasibility is about resources.
Ask:
<ul>
<li>How much money will it take?</li>
<li>How much time will it need?</li>
<li>How many people will it require?</li>
</ul>
Even if your idea is brilliant, poor feasibility can kill it.
So evaluate both the service and product versions of your idea. Choose what’s realistic for your current capacity.
<hr>
Most product ideas don’t fail because they’re bad. They fail because nobody needs them.
You saw a pain, assumed others felt it too, and rushed into solution mode. That’s the default builder mindset: code first, validate later (if ever). But real users don’t care about how clever your product is. They care whether it makes something in their life easier, faster, or less frustrating.
Validation is where that gap gets exposed.
And it’s better to hit that wall before you spend weeks on mockups, features, and beta launches. The goal isn’t to kill your idea. It’s to make sure you’re not building for a fantasy use case.
A real problem shows up again and again — in forum complaints, in awkward spreadsheets, in hacked-together workarounds. If you can’t find it in the wild, odds are it’s not worth solving yet.
So take your idea. Strip it down to the problem. Talk to real people. Stress test the pain. And don’t move forward until the answers are boringly obvious.
That’s how you build something that sticks.
<hr>
Want help figuring out your next step – or just want to surround yourself with builders who get it?
Join the SK NEXUS Squad and be part of a community that’s all about execution, insight, and leveling up beyond platforms.

Smiley Face

Knowledge by Execution - Breaking Down Tech for the Mango Man (Aam Aadmi/Regular Person) - https://www.sknexus.org/

The Mistake That Kills 9 Out of 10 Indie Projects