Building is easy. Deciding what not to build is harder.
Lately I’ve noticed a pattern while building in public.Most ideas don’t fail because they’re bad. They fail because they’re comfortable.
You keep adding features.
You keep polishing edges.
You keep telling yourself it’s “almost ready.”
But the hard questions get delayed:
Who is this actually for?
What problem would someone be annoyed enough to pay to solve?
If I removed half of this, would anyone complain?
The moments that sting a little when someone says “this isn’t for me”
or “I got stuck trying to do X”those have been more useful than praise.
Right now, I’m trying to optimize less for momentum and more for clarity:
noticing real friction instead of polite feedback
separating encouragement from demand
being willing to stop things that don’t pull people in naturally
Still early. Still learning. Still getting things wrong.
If you’re building too:
What’s something you kept improving that you eventually realized shouldn’t exist at all?
This really resonates. What you’re describing is the difference between building features and discovering demand.
One thing I’ve seen help with that clarity is spending time where users already complain and compare, especially on Reddit. When people are annoyed enough to write long posts asking for alternatives or describing broken workflows, it becomes very obvious what not to build and what actually matters.
The signal there is rarely praise, it’s friction, confusion, and “why does this suck?” moments. Those have saved me (and founders I work with) from shipping a lot of unnecessary features.
Curious if you’ve been observing real user conversations anywhere like that yet, or if this clarity is coming mostly from direct feedback?
Yeah, that distinction has been huge for me too. So far it’s been a mix, but the strongest signals haven’t come from praise or feature requests they’ve come from watching where people hesitate, compare, or quietly drop off. Direct feedback helps, but the “why does this suck?” moments (even when they’re not aimed at my product) tend to surface the real job much faster.
I’ve started paying more attention to those ambient conversations where people are already venting or stitching workarounds together and using direct feedback mainly to confirm or disprove what I’m seeing there.
Really resonating with this post. That line — "Most ideas don’t fail because they’re bad. They fail because they’re comfortable." — hits hard. I've lived it more times than I care to admit: death by incremental polishing while the core assumptions go untested
Exactly. Polishing feels safe because it looks like progress, but it often delays the uncomfortable work of testing whether the core assumption is even right. I’ve been guilty of hiding behind “one more improvement” more times than I’d like to admit too.
This resonates a lot. Especially the idea that comfort, not incompetence, kills most projects.
I’ve noticed the same pattern—polish becomes a way to avoid asking the uncomfortable questions. It feels productive, but it delays the moment where real users push back or walk away.
The distinction you made between encouragement and demand is sharp. People are generous with praise, but much quieter with commitment. Learning to read that gap honestly seems like one of the hardest builder skills.
Still early and still wrong is probably the most accurate state to be in. Appreciate you sharing this in public—it’s the kind of reflection that saves others months of building the wrong thing.
Appreciate this especially the point about comfort. That’s been the hardest thing to admit for me: polish can feel like progress while quietly protecting you from real answers.
The praise vs commitment gap is real too. I’m still learning to treat silence and hesitation as signals, not just the loud feedback.
“Still early and still wrong” actually feels like the most honest place to be right now. Sharing it publicly has been uncomfortable, but the perspective it unlocks has been worth it.
Real feedback stings because it’s useful. Praise feels good, but friction shows you where the product actually lives. Needed this reminder today.
Exactly. Praise is comfortable, but it rarely changes anything. The feedback that stings is usually pointing straight at the part that actually matters.
Those moments are uncomfortable, but they’re also the fastest way to get out of our own assumptions.
Totally agree. It’s uncomfortable because it challenges the story we’re telling ourselves. But that’s usually where the real product starts to take shape
Exactly. The discomfort is usually the signal you’re finally getting closer to the truth.
going thru that pain lol
Yeah 😅 it’s uncomfortable in the moment, but I’m starting to see that the pain usually means something real is surfacing. Way better than false confidence.
This really hits. I’ve noticed the same thing, especially the difference between encouragement and actual demand. The feedback that stings a bit usually points to something real that needs fixing or cutting.
Totally agree. Encouragement feels nice, but it’s the feedback that stings a bit that actually forces a decision. That’s usually where the real learning (or cutting) happens.
I think it does already exist, but not the way I think of it. There are countless version of something with the same function; how well it works, what it’s made of, etc can be a way to overwhelm myself quickly. I don’t know if it’ll solve someone else’s problems if I don’t know what it is they’re trying to solve. I can try to predict outcomes, but I’d still be limited to my own perspective as much as Id like to think I can adopt that of others.
They’ll be a a reason for wanting to acquire something. People will come up with that reason themselves imo. I just have to make “it”. Grounding myself in making things for me, is the first step. Just making it exist is a challenge, we can modify it later based on what outcome(s) that come from completing version 1.0. Don’t forget to celebrate achieving your milestones and never worry alone.
This is a really honest take. I like the idea of making it exist first instead of over-thinking outcomes. You can only learn so much in your head version 1 gives you something real to react to. And yeah, celebrating small milestones matters more than we admit.
This really resonated — especially the idea that comfort, not bad ideas, is what delays failure.
One thing I’ve noticed building is that polite feedback often feels encouraging but actually hides the real friction. The moments when someone says “this isn’t for me” or stalls at a specific step have been far more informative than praise.
Curious how you’re identifying real friction versus polite silence — are you watching behavior, asking sharper questions, or something else?
I’ve learned to trust behavior more than words. Polite feedback is easy to give, but real friction shows up in what people don’t do where they pause, where they drop off, or what they try to work around instead of using directly.
When someone says “this isn’t for me” and can point to a specific moment, that’s been way more useful than general praise. Even stalls or awkward silences tend to carry more information than encouragement.
These days I avoid asking “do you like this?” and instead ask things like “where did this feel annoying or confusing?” It’s a bit uncomfortable, but it almost always leads to the truth.
Great insight. The real work isn’t adding more — it’s having the courage to cut. Clarity over features. Asking ‘who would truly pay for this?’ is what turns a project into a product.
Exactly. Cutting forces you to confront demand, not taste.If someone wouldn’t pay, more features won’t change that.
This thread nails a truth most builders only learn after wasting months: clarity hurts more than effort. Building feels safe because it’s controllable. Deciding what not to build forces you to confront whether the thing deserves to exist at all.
What stood out to me is how “pull” shows up before validation and without persuasion. When something works, users don’t ask for explanations they ask for constraints. Limits, edge cases, pricing, access. They’re already mentally inside the product, testing its boundaries.
The opposite is just as telling. If a product needs a narrative to survive, it’s already on life support. The more words it takes to justify value, the less value there is.
I’ve learned to treat confusion as neutral data, but indifference as a verdict. Confusion means there’s a problem worth clarifying. Indifference means there’s no problem worth solving.
The hardest skill isn’t shipping fast it’s having the discipline to kill things that are “fine” but not necessary. Most products don’t fail loudly. They fade quietly while the builder keeps improving the wrong thing.
This post is a good reminder that real progress often looks like subtraction, not iteration.
The part about “pull” showing up as constraints really resonates.
When users start asking about limits, pricing, and edge cases, they’ve already crossed from curiosity to intent.
Everything before that is just noise.
"If I removed half of this, would anyone complain?" - This is the question I wish I'd asked earlier on multiple projects.
To your question: I spent weeks building an elaborate settings panel for a tool. Customization options for everything. Felt like "power user" features that would differentiate us. Then I looked at the analytics - almost nobody touched it. The few who did mostly just reset things to default after experimenting.
The uncomfortable realization: I was building for an imaginary power user who shared my preferences, not for actual users who just wanted the thing to work.
Your distinction between "encouragement" and "demand" is sharp. Encouragement feels good but it's often just politeness. Demand is when someone asks "when can I use this?" or "can you add X so I can do Y?" - there's a specific job they're trying to do.
What's your signal for knowing something "doesn't pull people in naturally"? Is it engagement metrics, or more gut-feel from conversations?
That example hits hard the “imaginary power user” trap is so real. I’ve fallen into that too, building for a version of myself instead of the person just trying to get a job done.
For me, the signal has been more conversational than metric-driven, especially early. Metrics lag, but conversations don’t. When something pulls, people don’t need reminders they follow up, ask edge-case questions, or try to bend it to their workflow.
When it doesn’t pull, the energy flips: more explaining, more justifying, more “maybe it’ll click later.” That’s usually when I know I’m pushing instead of listening.
"Metrics lag, but conversations don't" - that's quotable. And it's true. By the time your dashboard shows declining engagement, the actual loss happened weeks ago in conversations you weren't paying attention to.
The energy flip you described is the clearest diagnostic I've heard. When you're explaining instead of listening, when you're justifying instead of discovering - that's the push/pull distinction in real time.
I think the trap is that pushing feels productive. You're doing something. You're pitching, iterating, refining. But pull has a different quality - you almost can't keep up with the questions. People are already imagining how to use it before you finish explaining.
Have you found a way to create more of those pull conversations intentionally, or is it more about recognizing them when they happen organically?
Right now it feels less like creating pull and more like not getting in its way. The moments that turned into real pull weren’t when I polished the pitch, but when I shared something slightly rough and stayed quiet long enough to watch how people reacted.
When people start asking:
“Can I use this for X?”
“What happens if I try Y?”
or they come back on their own without a reminder
that’s usually the signal. No dashboard needed.
I’m still learning to trust those conversations over the urge to explain more. Pull seems to show up when you stop trying to manufacture it and instead pay close attention to where curiosity naturally clusters.
"Not getting in its way" - that reframe is important. Most advice treats pull as something you create. But what you're describing is more like clearing obstacles so natural curiosity can move.
The "slightly rough" detail matters too. Polished things feel finished - they signal "this is what it is, take it or leave it." Rough things invite participation. People fill in the gaps with their own use cases.
Those unprompted questions - "Can I use this for X?" - are the signal because they reveal the user's mental model, not yours. They're telling you what problem they're actually trying to solve, which is often different from what you thought you were building.
The hardest part of trusting those conversations is that they don't look like progress. No commits, no features shipped. But the clarity they create is worth more than weeks of building the wrong thing.
This is such a sharp way to put it. The “rough invites participation” point really landed for me. When something feels finished, people judge it. When it feels a bit open, they engage with it. That gap is where you learn what actually matters to them.
Also love how you framed unprompted questions as signal, not noise. Those “Can I use this for X?” moments have been more revealing for me than any structured feedback session they expose the job people want done, not the one I assumed.
And yeah, trusting conversations over commits is uncomfortable. It feels like standing still. But skipping that clarity tax almost always shows up later as wasted weeks.
This is the kind of insight you only get by paying attention, not by shipping faster.
"Paying attention, not shipping faster" - that's the counterintuitive lesson most builders learn too late.
The "clarity tax" framing is perfect. It feels like a cost in the moment - slowing down, having conversations that don't produce code. But it's actually the cheapest form of learning available. The alternative is building your way to clarity, which costs 10x more in wasted effort.
What strikes me about this whole thread is the consistent theme: the signals that matter most don't look like progress. Rough versions, unprompted questions, the absence of enthusiasm - none of these show up in a sprint demo. But they're the actual information that determines whether a product succeeds or slowly fades while you keep improving it.
The discipline isn't in shipping - it's in paying attention to what's already being said.
The “clarity tax” idea resonates a lot especially the part about signals that don’t look like progress. It’s uncomfortable because none of those inputs fit neatly into a roadmap or demo, but they’re usually the difference between momentum and quiet drift.
I also like how you framed discipline here. Shipping is visible, so it feels virtuous. Paying attention is quieter, and easier to dismiss but it’s often the harder work. Missing those early signals is how teams end up polishing something that never quite lands.
Feels like the thread keeps circling back to the same truth: progress isn’t just about moving forward, it’s about not moving confidently in the wrong direction.
"Not moving confidently in the wrong direction" - that's a better definition of progress than most. The default assumption is that forward motion equals value. But direction matters more than speed, and the wrong direction traveled quickly just means you're further from where you need to be.
The visibility asymmetry you pointed out is real. Shipping produces artifacts - commits, releases, demos. Paying attention produces clarity, which is harder to show in a standup. But the clarity is what makes the shipping worth anything.
What's interesting about this whole thread is how it keeps returning to the same core tension: the things that feel productive often aren't, and the things that actually matter often feel like you're standing still. The discipline is in trusting that distinction even when it's uncomfortable.
"Feeling stuck or uncomfortable is often a sign I'm finally paying attention, not falling behind" - that's the kind of reframe that changes how you work, not just what you work on.
The discomfort we avoid is usually where the real information lives. Smooth progress feels good but often means we're not questioning anything. The friction of "wait, should we even be doing this?" is where direction actually gets set.
Your point about artifacts vs. clarity is something I keep coming back to. It's easy to show what you shipped. It's much harder to show what you didn't ship because you realized it wasn't necessary. But the second decision is often more valuable than the first.
This has been an exceptional thread. The tension between productive-looking work and actually useful work is something every builder faces, and you've articulated it better than most. Appreciate the depth of thinking here.
I’ve felt that tension a lot doing things that look productive versus doing the work that actually changes direction.
The clarity vs. artifacts point is especially true. Commits and releases are easy to show, but realizing “we shouldn’t be doing this at all” is harder to surface and usually harder to act on.
I’m slowly learning that feeling stuck or uncomfortable is often a sign I’m finally paying attention, not falling behind.