When Darrell and I were planning analytics for Clipflow, I wanted to get an initial version in front of people quickly. I expected our first attempt to have things wrong.
That's become easier to accept after years of building software. You can put plenty of thought into a feature and still misunderstand which parts customers need, or how they expect those parts to work.
We had our own reasons for wanting analytics. We were making content and wanted to know what to make more of. That gave us a starting point, but it couldn't answer every question about how other teams would use it.
The plan was to build something people could work with, then let them point out the gaps. Paying customers have a much more concrete response than someone considering a feature in the abstract. They're trying to get a job done with it.
You have to leave room for that response to change your thinking. If you spend all your time defending the first design, you've missed a useful part of releasing it.
I find it quite freeing to assume my best effort will need correcting. It lets me put the work in without pretending the first version should be the final answer.
It also gives us a reason to move. We can keep discussing the feature internally, but there are things we're only going to learn when someone else uses it.
So I'd rather give people something useful to try, listen carefully and build from there. Being willing to find out where you're wrong is a practical part of developing the product.
