I've seen a similar situation play out at a startup and I can see your point. However, I think there's a difference between talking to potential customers about requirements they have vs. promising to deliver a solution for them on the spot.
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.
I totally agree with you if we are talking about preliminary market research, which also usually involves components of research into the technical investment required.
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.
I’d say even for some new CRUD app, assumptions that it will be easy to build are so, so common, and the reality of most “super simple CRUD apps” is that the implementation is way harder than you thought, and selling advanced features before you definitively know how to build them is a big source of failure for seemingly straightforward products.
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.
My take is that the purpose is not to actually close a sale before building, but to make sure that you could actually close a sale.
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.
I'd also add that you should find common requirements that customers have and build your solution around those.
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.