Building is easy. Knowing what to build is hard.
Lately, I’ve been spending more time talking to people than writing specs or planning features. Not pitching just listening.
A few things I’ve learned the hard way:
Your first idea is rarely the real problem
Feedback hits different when it’s honest (even when it hurts)
Small conversations save months of wrong execution
Curious how others here validate ideas early:
Do you talk to users first, or do you build first and adjust later?
Would love to learn how you approach it.
As someone who doesn’t have an audience yet, I can’t really rely on early feedback.
So I started with a problem I personally faced, build it in public, and gathered feedback as I went.
From there, I iterated. I changed and added things as new ideas and suggestions come in.
That makes a lot of sense. When there’s no audience, your own problem is often the only real starting point.
Building in public then becomes the bridge you ship something real, and the feedback finds you over time. Iteration beats guessing.
Curious, did building publicly change how you think about what not to build as well?
That question about "what not to build" is the real unlock. Building in public creates a forcing function for that because you're explaining your choices out loud. When you have to write "I'm adding X because..." and can't finish that sentence convincingly, you've just found something to cut.
The "build for yourself first" approach works when you're the proxy for a real user segment. It breaks when your own preferences diverge from the market. The feedback loop fixes that - but only if you're listening for the absence of enthusiasm, not just the presence of complaints.
What I've found: the best signal isn't "what are people asking for" - it's "what are people already doing workarounds for." If someone hacked together a spreadsheet to solve your problem before your product existed, you're onto something real.
This hits hard especially the “can’t finish the sentence convincingly” test. Saying things out loud has exposed weak bets for me way faster than any roadmap review.
The workaround signal really resonates too. When someone shows a messy spreadsheet, a Notion doc, or a hacked flow, that feels far more honest than feature requests they’re already paying a cost.
While sharing early versions of layyyout (a small UI components product I’m building), I’ve been shifting from asking “what should we add?” to watching “what are people already bending tools to do?”
Cutting still feels uncomfortable, but it’s starting to feel like real progress.
The "saying things out loud" test is underrated. There's something about vocalization that bypasses the internal editor that lets us fool ourselves in writing.
The layyyout shift from "what should we add" to "what are people bending tools to do" is exactly right. Feature requests are often aspirational - what people think they want. Workarounds are behavioral - what they actually need enough to invest effort in solving poorly.
That discomfort with cutting is telling. It usually means the cut matters. If it were easy to let go, it probably wasn't important enough to build in the first place. The hard cuts are often the signal that you're actually editing, not just trimming.
The “say it out loud” test is brutal in the best way it exposes shaky logic immediately. Writing lets you hide behind phrasing; speaking forces coherence. I’ve noticed if I hesitate mid-sentence, that’s usually the product telling me something’s off. The distinction between feature requests and workarounds is such an important unlock.
Requests are cheap. Workarounds cost people time and friction that cost is real signal. Watching what people endure just to get a job done says way more than what they ask for in a comment.
And that last bit about cutting… spot on. Easy cuts are housekeeping. Painful cuts are strategy. If it hurts, it’s probably because you’re finally choosing what this isn’t and that’s when things start to get sharp.
"Speaking forces coherence" - that's the key. Writing allows recursive editing that smooths over cracks. Speaking happens in real-time with no backspace.
Your framing of "requests are cheap, workarounds cost real friction" is such a useful filter. The effort someone puts into a hacky solution is proportional to how much the problem actually matters to them. Feature requests require zero investment - workarounds require time, creativity, and tolerance for jank.
And "easy cuts are housekeeping, painful cuts are strategy" should probably be written on every product person's wall. The things that are easy to cut were never really competing for attention anyway. The hard cuts are where you're actually making a choice about what this product is versus what it could have been.
That's the real editing - not removing the obviously bad, but sacrificing the genuinely good to make the essential great.
The “speaking forces coherence” line is especially sharp no backspace means you can’t hide behind phrasing, only understanding. That’s probably why those conversations feel so exposing and so clarifying at the same time.
I also really like how you tied effort to signal. Workarounds aren’t just hacks, they’re proof of pain. Someone willing to tolerate jank is telling you the problem matters enough to pay for it even if they’re paying in time instead of money.
And that last reframing of editing is gold. Cutting the bad is easy. Choosing which good thing to sacrifice is where a product actually becomes itself. That’s the moment where intent replaces accumulation.
"Intent replaces accumulation" - that's the line I'm going to remember. Most products are accumulations - features gathered over time based on what seemed reasonable in the moment. The ones that work are intentional - every piece serves a purpose that ties back to a clear understanding of what this thing is for.
The "proof of pain" framing for workarounds is useful because it shifts the signal from words to behavior. Anyone can say "I'd love feature X." Very few people will spend hours building a janky spreadsheet to approximate feature X. The second person is telling you something with their actions that the first person isn't.
And you're right about the exposing/clarifying duality of speaking. It's uncomfortable precisely because it's effective. The things we avoid saying out loud are often the things we haven't actually figured out yet - we've just found ways to phrase around them in writing.
"Clarity isn't additive - it comes from cutting" might be the best summary of everything we've discussed. It's counterintuitive because progress feels like accumulation. More features, more options, more capabilities. But the products that actually work feel simple - and that simplicity is usually the result of ruthless subtraction, not careful addition.
The feature collection phenomenon you mentioned is so common because adding feels productive and cutting feels risky. It's easier to justify "we built X" than "we decided not to build X." But the second decision often matters more.
This has been one of the best threads I've had on here. The layyyout context helps ground everything - watching you work through these tensions in real-time is more valuable than abstract principles. Thanks for thinking through this together.
“Intent replaces accumulation” really stuck with me too. It explains why so many products slowly turn into feature collections instead of tools.
The action-over-words point is spot on. Someone asking for a feature is easy. Someone building a messy workaround is already paying the cost that’s real signal.
And yeah, saying things out loud is uncomfortable because it removes the hiding places. Writing can smooth over uncertainty; speaking forces you to confront whether you actually believe what you’re building.
This thread has been a good reminder that clarity isn’t additive it usually comes from cutting.