[mlthoughts2018]

The first point is often totally wrong. I worked in a place where the sales team sold the product hard before much of it was built and before it was reliable.

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_.

[martinraag]

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.

[mlthoughts2018]

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.

[mixmastamyk]

I guess the question is, are you building another CRUD/business workflow app? Or inventing self-driving car algorithms with a KITT AI?

One is highly possible and likely, the other is not. Most ideas will be somewhere in between.

[mlthoughts2018]

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.

[galvarez800]

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.

[davemp]

I mostly agree. The only difficulty is that what people will say and what people will pay are not always aligned.

[techmatters]

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).

[djrogers]

I think you might be taking the term ‘selling’ too literally - it’s pitching an idea and soliciting feedback. If you’re taking orders for something that doesn’t exist yet, you’ve done it wrong. OTOH, if use the 3/12/24 months it takes to build the product to listen to future customers, you can ship something of value as soon as its ready.

[mygo]

Then every single Kickstarter is doing it wrong.

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.

[sobani]

Plenty of Kickstarters fail because the people creating the product realized too late how hard it was to create what they promised.

[mygo]

did the kickstarter fail?

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?

[gowld]

The point isn't to finish selling before you build, the point is to start selling -- do market research -- before you build.

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??

[da_chicken]

I agree that your interpretation is right, but "start selling" is an extremely ambiguous phrase here. After all, "a sale" is most often understood to be a finalized sale; "to sell" is most often understood to be completed transaction.

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.

[PhaseLockk]

> "to sell" is most often understood to be completed transaction.

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.

[mlthoughts2018]

I think your comment about investing in other assests only further agrees with my point. Selling before you build is like investing in an asset without due diligence.

[ggregoire]

I don't think the article is about companies building a new product before selling it. All companies do that and it works. I guess the article is more about engineers (usually one or two guys) building a product on their own (full-time or on the side of their job) before talking to any potential customer. Basically spending x months building a product then sending the first emails to companies that could be a good fit, and in most cases, don't find anyone interested in.

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.

[JesseAldridge]

Maybe the answer is to pre-sell a very simple product that you are certain you can build. Any half-decent engineer can build a CRUD app that consumes a spreadsheet and renders some graphs, for example. You can add all the theoretical magic that turns a good product into an amazing one after you build this basic MVP.

[JamesBarney]

Fundamentally it's about risk. If your startup is writing OCR that out competes tesseract or automatically diagnoses melanoma that has very different risks than building a B2B product to allow optometrists to manage their clients.

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.