What's one assumption about your product that your users completely proved wrong?
One thing I've learned while building a SaaS is that it's easy to make decisions based on what you think users need.
The difficult part is accepting that you're sometimes wrong.
We had several ideas that seemed obvious during development, but after talking to real users, the conversations went in a completely different direction.
Instead of asking for more features, many people cared more about clarity.
They wanted to answer questions like:
Where is time being lost?
Which processes create the most friction?
How can we reduce manual work without making things more complicated?
That changed how we think about product development.
Now, before building anything new, we ask ourselves:
"What decision does this help the user make?"
That simple question has saved us from building features that looked impressive but wouldn't have solved a real problem.
I'm curious...
What's one assumption your users completely changed after you started talking to them?
I'd love to hear the lessons you've learned while building your product.
Replies
Stacys answer is the same lesson i learned, from the opposite direction. i assumed i knew my own product's limits. a stranger in a launch thread proved i didn't.
my app reads content provenance in files, the embedded markers that say where something came from. someone pointed out that a cryptographically intact signature isnt the same as a trustworthy one, anyone can sign something. i was fairly sure i handled that distinction. i went and checked my own code and he was right, i didn't.
so the assumption users broke wasn't about what they wanted, it was about what i thought i'd built. and the fix is exactly Stacys four confidence levels: instead of one "verified" state, you need separate states for verified, structurally valid but unknown signer, missing, and tampered. collapsing those into one confident label is the thing that costs trust.
honesty being a harder sell than confidence, i don't think it is anymore, at least not with technical users. saying "here's what i can't prove" is what makes the rest believable.
@matthias_stralman That's a great example. I think one of the easiest traps for founders is assuming the product behaves exactly as intended because we know how we built it. Real users test assumptions we don't even realize we're making. I also like your point about separating "valid" from "trustworthy" instead of collapsing everything into a single status. That kind of clarity is what builds long-term trust.
@shahroz_siddique exactly, and the trap is sneakier than it sounds: i wasn't wrong about the code, i was wrong about the words i'd been using to describe it. those drift apart quietly, and you don't notice because you wrote both.
the fix i've landed on is boring but works: whenever i make a claim publicly, i go verify it against the actual code before i say it again. caught two things that way this week.
@matthias_stralman That's a great habit. I think it's easy for our messaging to evolve faster than the product itself, especially when we're talking about it every day. Going back and validating claims against the actual implementation keeps expectations realistic and builds much more trust over time.
@shahroz_siddique well put. thanks for the thread, good one.
@matthias_stralman That distinction you found, valid versus trustworthy, is the same trap in a different shape. It is not that the code was wrong, it is that the label was doing more work than it deserved to do. I ran into the same thing with a metric that looked fine on the dashboard but was fine for the wrong reason. Checking your own claims against your own code every time you repeat them sounds tedious but it is probably the actual discipline behind trust, more than any feature.
Mine was around confidence, not features. I assumed founders would want the tool to sound certain, decisive, tell them exactly what to do. What I found testing on my own businesses first was the opposite, a confident wrong answer cost more trust than an honest maybe. So instead of hiding uncertainty I built four confidence levels into every alert, verified, very likely, needs review, monitor only, and let people see the difference. Curious if anyone else found honesty to be a harder sell than confidence, even when it was the more accurate answer.
@stacywycof83995 That's a really interesting insight. I think transparency builds stronger long-term trust than sounding certain all the time. Giving users visibility into confidence levels also helps them make better decisions instead of blindly following recommendations. I'd trust a tool that says "needs review" over one that's confidently wrong any day.
@shahroz_siddique Agreed, and the trust compounds in a way I did not expect going in. Once someone sees the tool say needs review a few times and later watches it turn out right, they start trusting the verified label more, not less. A tool that is occasionally humble earns more belief than one that never is.
Mine was the assumption that a useful monitoring product should always show fresh alerts. In early FleetStart Radar testing, an empty CQC panel looked broken even when the source was healthy and no registrations had changed. Users needed two separate answers: “Is the source working?” and “Did anything worth acting on change?”
We separated the live directory and source-health view from change alerts, added records-monitored and last-synchronised timestamps, and made the zero state explicit. Roadworks produced a related lesson: thousands of events are noise until they are matched against a saved customer job.
The decision question became: does this view prove the feed is healthy, or help someone decide what to act on? Trying to make one table do both made the product less trustworthy.
@simon_banner that split, is the source healthy versus did something worth acting on happen, is exactly why one confidence level was never going to be enough for us either. A quiet system and a broken system look identical if all you show is the absence of alerts. We ended up needing a fourth state, monitor only, specifically for that reason, so silence gets a label instead of getting mistaken for nothing to report.
@simon_banner @stacywycof83995 I really like the common theme in both of your examples. An empty dashboard or no alerts shouldn't leave users wondering if everything is fine or if something has failed. Making the system's state explicit gives people confidence in what they're seeing and helps them decide whether they need to act. That kind of clarity is often more valuable than showing more data.
@stacywycof83995 @shahroz_siddique Exactly. We found the zero state needs to answer both questions explicitly: "Is the feed healthy?" and "Is there a new actionable change?" Once those are separated, a quiet dashboard becomes evidence rather than ambiguity. It was a small interface change, but it materially improved trust in the monitor.
@stacywycof83995 @simon_banner That's a great way to put it. I think ambiguity is often more damaging than a lack of data. When users can clearly distinguish between "everything is working as expected" and "nothing has happened," they spend less time second-guessing the system and more time acting with confidence. Small UX decisions like that can have a huge impact on trust.
@shahroz_siddique Ambiguity being more damaging than a lack of data is the whole reason a fourth state existed for us at all, once monitor only sits next to needs review, silence stops being ambiguous and becomes a fact you can act on or ignore on purpose. Thank you for pulling this thread all the way through, it is rare to see a comment section actually finish a thought instead of trailing off.