It turned out to be way harder to build what customers actually wanted than anyone knew ahead of time. Nobody could foresee it. The only way we could have known we were egregiously over-promising in the sales pitches was to just actually start building it first, see how hard it would be and what the unexpected sources of engineering difficulty would be, and then scope our sales vision or pitches accordingly.
That particular product team failed badly and the product line was closed down. We started selling before building, and only later realized that when you do that, you’re talking out of your ass and you are doing a huge disservice to prospective clients who buy into your sales pitch just to be let down later when you cannot execute on the implementation for reasons that could have been known if only you had invested in building things first.
The same issue can also play out with costs: maybe you technically can build what you sold, but because you over-promised in the sales pitches, you end up in a situation where to be able to offer what was actually sold, the engineering costs force it to be intrinsically unprofitable, while had you known the cost projections from building first, you might have been able to scope the sales pitch to only a profitable set of features.
It’s way easier to throw away / rebuild something later when sales feedback indicates you should pivot than it is to build nothing at all, over-promise, and try to keep clients who end up unhappy that you misled them.
The cost of building first so you have adequate information about what it would require to profitably support selling a certain product or feature set is known as _investment_.
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.
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).
Nothing wrong with taking orders for something that doesn’t exist, so long as you can deliver.
The sales team’s problem is that they didn’t know what was technically feasible.
There may have been a way to decipher whether what was promised was build-able... before trying to build it.
And in any case, the point of collecting payment is to validate the market. No better validation than actual sales. But doesn’t mean the money has to be spent. They should hold on to it in case they need to give out refunds, and give out refunds when they have determined that they can’t deliver.
And in the special case of a kickstarter type campaign then the basis of that relationship was that the product may or may not come to fruition and that they don’t have to give out refunds.
Sounds to me like those people got tons of people to give them free money to try to bring something to market with no ramifications if the product can’t go to market. And no obligation to give out refunds if the product doesn’t go to market. How is that a failure?
You use the term "investment" -- do you invest in stock market / bitcoin / real estate by buying whatever looks cool, and chalking up your losses to the learning process, or do you research your choices and look for ROI opportunities??
Yes, the idea here is, "understand who you're marketing to and what they're looking for before you start building," and the phrasing used is what it is because that's catchier, but it's still not particularly concrete phrasing.
That is certainly the understanding of laymen. However, if you talk to people who work in sales, and look at their "pipelines" for creating sales leads, followup, closing, and whatever else they do, you get the sense that "selling" is actually an extensive, multi-part process. At least I think that's the view most sales professionals would have.
Yes it sounds like a stupid thing to do (and I did the same mistake). I think that's the difference between an engineer and an entrepreneur: one wants to build an app, the other one a business. Obviously you can be both, but I guess lot of people will try and eventually find out that they are more engineers than entrepreneurs.
In general though I think most startup's have more go-to-market risk than technical risk. If you can out compete tesseract in OCR you're not going to fail because of market. And if you're Salesforce you're not go to fail because you can't build software to track leads. You're going to failed because you couldn't find enough users.
This is why investors spend so much more time looking at adoption rates, and so little time looking at the backing infrastructure.