The feature you're most sure about is the one you should question first
I've built a lot of software for founders. The features that got cut or rebuilt were almost never the risky ones. They were the ones everyone was certain about.
Certainty is where you stop asking questions. And the questions you skip are the ones that cost you a rebuild three weeks later.
The pattern I see with SaaS founders:
You build the feature you assumed users wanted, ship it, and watch nobody touch it. Meanwhile the thing you almost didn't build is the one they actually use.
The fix isn't more research. It's asking the uncomfortable question before you write a line of code: "what if the part I'm sure about is wrong?"
The founders who ship things people use aren't smarter. They just question their own certainty earlier than everyone else.
What's a feature you were 100% sure about that flopped, or one you almost didn't build that took off?
Total truth bomb. Every flop feature I’ve shipped came from unchallenged certainty, and my biggest win was a tiny afterthought I almost cut entirely. Stopping to question your own sure instincts before writing code is such an underrated superpower for SaaS builders. Thanks for sharing this perspective!
Thanks! The afterthought winning while the sure thing flops is the pattern every time. Questioning your own instincts really is the underrated skill.
nice
nice
At SocialPost.ai the feature I was certain about was advanced scheduling controls, and usage data showed almost nobody touched them; a small AI caption rewriter we nearly cut became the most used feature in the product. The tell I now watch for on my own roadmap and in portfolio companies: if a feature survives every planning meeting without a single debate, that is the one nobody pressure tested. Certainty in the room usually means the customer was never in the room.
"Certainty in the room means the customer was never in the room." That's the sharpest line here. And the no-debate feature being the untested one is a great tell, I'm stealing that. Scheduling controls vs the caption rewriter is the perfect example.
Like this framing! The features that feel most obvious internally are often the ones most shaped by your own assumptions. Early users are useful not only because they find bugs, but because they show which parts of the product actually create clarity for someone who did not build it
Yes, early users show which parts create clarity for someone who didn't build it. You can't see that yourself, you're too close to your own assumptions.
Really helpful to read this. As a non-technical founder I keep going back and forth on how much to build vs validate first — how did you decide?
My rule: validate anything you're building because it "obviously" makes sense. Build the small version, watch if anyone uses it before expanding. Cheapest validation there is. As a non-technical founder, usage beats opinion every time.
"Certainty is where you stop asking questions" — this just reframed how I think about my Day 5 layer.
I was 100% sure my "real payment signal" detector was the most important part of the pipeline. After reading this, I realize the part I'm not questioning is the Shopify migration idea itself — which is exactly the assumption I should be stress-testing before building.
That's the real catch, you were stress-testing the detector but not the migration idea underneath it. The assumption you're not questioning is always the one to question first. Good catch.
The problem always has been, is, and will be distribution. No matter how you look at it, find a solution to this recurring problem and have a profitable business. And you, as a company in the market, do you have any solution to this recurring problem? Or...
Distribution is the real problem, agreed. My angle: build in public and add value in communities before selling. Slow, but it compounds. Still working it myself.
I think certainty is actually more dangerous than uncertainty. When we're unsure, we validate. When we're confident, we skip validation because it "just makes sense." I've started forcing myself to ask, "What evidence do I actually have that users need this?" before building anything.
"Certainty is more dangerous than uncertainty" is exactly it. Uncertainty triggers validation, confidence skips it. That one question, "what evidence do I actually have", kills most bad features before they're built.
Happened to us with feedback capture. We were sure collecting feedback was the product, turns out nobody cared until the feedback actually went somewhere after it landed. Hard to question it though, it was the whole reason we started.
Right, "nobody cared until it went somewhere after it landed." The capture felt like the product, but the routing was. Hard to question because it was your origin story, that's exactly when certainty blinds you most.
The version of this I keep hitting: the feature I'm most sure about is usually one that adds a decision for the user, and those are the ones that flop. Dashboards, settings, stats screens — I'm certain people want them because I'd want them as the builder, and then nobody opens them. What sticks is whatever quietly removes a decision so the person doesn't have to think about it. My rule now is that certainty about a feature is a signal to ask who it's really for — me or the user. Half the time "obviously they need this" just means "I'd enjoy building this." So the question before writing code isn't "will they use it," it's "does this add a choice or remove one?"
Since we're both in the accounting-integration space, curious what's been your hardest edge case? For me it's always fee/refund timing that posts late and breaks reconciliation.
Great example. Dry-run felt pointless because its job is doing nothing, but it's what makes people trust the thing that does everything. Correctness doesn't earn trust, visibility does. Shipping it ON by default was the right call.
Lived this exact pattern with my first Shopify app (it syncs orders into accounting software). The feature I was 100% sure about was the sync itself — fully automatic, zero clicks, that was the whole pitch. The thing I almost didn't build was a "dry run" mode that just shows what would be written to your books without actually writing anything. Felt like a waste of a week for a feature whose entire purpose is doing nothing. Turned out dry-run is what makes merchants trust the automatic part at all — nobody wants a robot writing into their accounting ledger sight unseen, so I ended up shipping with dry-run ON by default and letting people flip the switch after they've watched it behave. The "sure thing" was worthless without the "why would anyone build that". Your framing of certainty as the place you stop asking questions is exactly right — for me the blind spot was assuming trust would come free with correctness.
Exactly, the doubt forced better thinking. Right now? Anything touching how much to automate vs. leave manual. I keep assuming people want full automation, but some want control at the critical step. Still validating that one.
This. We validated zero overlap across 8 newsletters before drafting a single issue. The feature we were most sure about (niche segmentation) required the most scrutiny. That doubt forced better thinking. What feature are you second-guessing right now?
Validating zero overlap before writing a single issue is the move most skip. And you're right, the feature you're surest about deserves the most scrutiny. Doubt forces better thinking.
this hit home tbh. when i started building BountyKai i was convinced vulnerability detection would be the feature everyone cared about.after talking to pentesters and bug bounty hunters, i realized the real pain was much earlier in the workflow. people were spending hours just understanding the application, mapping APIs and figuring out the business logic before they could even start testing.that completely changed what i prioritized. sometimes the feature you think you're building isn't actually the product.
"The feature you think you're building isn't the product." That's it. The real pain was upstream, understanding the app before testing it. Talking to actual users is what surfaced it. You can't reason your way to that.
One thing that’s helped me: forcing myself to write a one-sentence user story for the “obvious” feature and then asking, “when, exactly, does this moment happen in their day?” If I can’t picture that moment clearly, the feature is probably about my needs, not theirs. Have you found a lightweight way to validate those “obvious from day one” features without slowing down shipping too much?
Love the "when exactly does this moment happen in their day" test. My lightweight version: ship the obvious feature as the smallest possible version, then watch if anyone touches it before building it out. Cheaper than research, faster than debate. Usage is the only honest validator.
I think certainty is often a signal that we've stopped looking for alternatives, not that we've found the right answer.
The features that create the biggest surprises usually aren't the ones that were difficult to build—they're the ones nobody thought needed validating because they felt obvious from day one.
"Certainty means we stopped looking for alternatives." That's the whole thing in one line. And you're right the surprises come from the obvious features, not the hard ones, difficulty triggers validation, obviousness skips it. The feeling of "this is obvious" is the exact signal to stop and question it.
I think that's the interesting part.
The moment something starts feeling obvious, it often stops being treated as a decision and starts being treated as a fact.
That's usually where the biggest strategic surprises begin.
the part that clicked for me: the features i'm most "sure" about are usually the ones i'd use myself, so i skip the research. the risky ones get validated precisely because i'm not sure. so the certainty isn't really about the user, it's me describing my own workflow and assuming everyone shares it.
honest example from my own product (affiliate software): i was certain people wanted a slick analytics dashboard. the screen they actually open every week is the boring "did this affiliate get paid the right amount" one. the flashy part I was sure about barely gets touched.
That's the sharpest version of it, "certainty is just me describing my own workflow." Nailed it. And your example is perfect: the payment-accuracy screen is boring but load-bearing, because it touches money and trust. The analytics dashboard was the fun build, not the needed one. Money-critical always beats flashy. Did the boring screen change how you prioritize now?