That said, the article of this post seems to emphatically say something different: that you should actively _sell_ before building. Not merely collect research, but to sell stuff you do not already have the capability to deliver, and then somehow backfill that delivery capability after getting customer buy-in.
One is highly possible and likely, the other is not. Most ideas will be somewhere in between.
It’s very much sales hubris to ever believe you know how to build something you’ve never built before, even in cases when it might seemlike a minor variation of something you built before.
The article makes the correct point that many people confuse "being sort of close to closing a sale" with actually closing a sale, and these people may waste time building a product that clients are only sort of interested in but aren't willing to actually pay for.
Much better to have 100s of customers using a product with 1 feature, than 1000s of customers using a product with 1000s of features (with the corresponding overhead).
IMO you don't have to, or rather shouldn't, close the sale when first reaching out to potential customers like this. The goal should be to simply validate the problem statement - if that's done with enough potential customers you should move on to the next part of planning and building the initial implementation.
To your point, new information might still surface at this point, which could lead to the project being dropped. Having not sold (promised a solution) to anyone at this point, the likelihood of unhappy clients is rather low.
All that said, I think calling this initial work "sales" might give the wrong impression here, as I would categorise it more as market research. Whoever is carrying this work out should be very aware of this and not actually close the sale on something they are uncertain can be delivered in a profitable manner.