I am building a B2B developer tool.
Six weeks ago I made a decision that felt uncomfortable at the time:-
I would spend a full month talking to potential users before
touching the codebase.
No mockups. No landing page. No code.
Just conversations.
Here is what actually happened.
Why I did this
I had a problem I wanted to solve.
I had experienced it myself.
I was convinced other people felt it too.
That conviction felt like validation.
It was not.
Feeling strongly that a problem exists is not the same as understanding who feels it, how badly, and whether they would pay someone else to solve it.
I had seen too many developers including myself in past projects build something for six months based on personal conviction and launch it to silence.
This time I wanted real signal before real investment.
The method
I picked the communities where my target users spend time.
Posted genuine questions about the problem space. Not about solutions. Not about what I was building. Just about the pain.
Then I read every reply carefully. Not for validation.
For pattern recognition.
What I found three completely different groups
I expected to find one audience.
I found three.
Group 1 — "This isn't a problem if you set it up correctly"
The largest group by volume of replies.
These are experienced practitioners who have already solved the problem their own way.
They have built internal tooling, established processes, and accumulated deep expertise over years.
When I described the pain I was exploring they did not recognize it as pain. They recognized it as a skill gap.
Their reply was essentially:
learn the tools better and this goes away.
They are not wrong. They are also not my customer.
High expertise means low pain means low willingness to pay for a solution to something they have already solved.
Group 2 — "Yes it is painful but we have accepted it"
The second largest group.
These people feel the friction daily.
They have tried to fix it.
Hit walls.
And eventually made peace with the situation as permanent.
The most common phrase from this group: "That is just how it works."
This group is interesting because the pain is real and present.
But acceptance has killed urgency.
To sell to Group 2 you do not need a better product.
You need to break their belief that the situation is unfixable.
That is a marketing problem as much as a product problem.
Group 3 — "I have no idea how to fix this and it costs us time every week"
The smallest group by volume.
The loudest pain.
The only ones who asked follow-up questions.
These are the people sitting with a problem they cannot solve, watching it cost them time repeatedly, with no clear path forward.
They are not waiting for awareness.
They are waiting for a solution that actually exists.
These are my people.
The uncomfortable insight
I spent four weeks looking for validation.
What I found instead was that the community I was targeting was mostly made up of people who were not my customer.
Group 1 pushed back hard on the premise of my posts. Some were dismissive. Some were genuinely helpful.
All of them confirmed they did not need what I was building.
Group 2 agreed with the problem but had already stopped looking for solutions.
Only Group 3 maybe 10 to 15 percent of respondents showed the combination of pain and openness that makes someone a real potential customer.
If I had read only the volume of responses, I would have concluded the market did not exist.
Reading the quality and pattern of responses told a different story.
What changed in how I am building
Before the research I was building for the average user in the community.
After the research I am building specifically for Group 3.
That sounds obvious in retrospect. It was not obvious before.
Group 3 has different needs than the experienced practitioners in Group 1.
They do not want to learn the internals. They want the internals explained to them in plain language.
They do not want more configuration options.
They want fewer decisions to make.
They do not want a powerful tool that rewards expertise.
They want something that works without requiring them to become an expert.
This changed several product decisions I had already made.
Some features I was excited to build became irrelevant.
Some I had deprioritized became critical.
Four weeks of conversations saved me from building the wrong version of the right product.
The thing I did not expect
The pushback from Group 1 was valuable in a way I did not anticipate.
Their objections became my objection-handling script.
Every time an experienced user said "just do X and this problem goes away" they were telling me exactly what my product needed to address for the cases where X does not work.
The critics gave me the edge cases.
The edge cases became the product.
What I would do differently
Start with lurking, not posting.
I spent the first week posting questions.
I should have spent it reading existing threads to understand the language the community uses to describe the problem.
Language matters more than I expected.
The words your customer uses to describe their pain are not always the words you use to describe what you are solving.
Finding that gap early would have made my posts sharper from day one.
Where I am now
Six weeks in. Product half built.
The research did not validate my idea.
It refined it.
I know exactly who I am building for.
I know what they need.
I know what objections I will face.
I know which features matter and which ones
I was building for myself not for them.
That is worth four weeks of uncomfortable conversations on the internet.
If you are pre-product and thinking about doing something similar do it.
But read the replies for patterns not for validation. The patterns are where the real signal lives.
What did you find when you talked to users before building?
Building a developer tool in public.
Writing about what I find along the way.
