[mlthoughts2018]

Why do you think my comments did not already account for that? The article claims that software engineers make the mistake of building before they sell, and advises an aggressive form of selling before building instead.

But that advice directly means to skip engineering due diligence (which very often requires building before you sell). It doesn’t matter if the person implementing the advice would be an engineer or a sales person or anyone else.

Your comment comes off as if it is supposed to glibly (and I think also rudely) undermine what I wrote, but in fact I think you didn’t understand what I wrote, and you seem to suggest that it would be impossible for an engineer (using the article’s advice) to fail to consult an engineering estimate of technical feasibility prior to selling something.

[tomhoward]

Having a high degree of confidence that you are capable of building what you are selling is a given.

Nobody reading this is building anything resembling a perpetual motion machine. Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.

Your comment is plain old reductio ad absurdum. It’s not clever.

Writers are entitled to favor conciseness over having to pre-empt any fallacious dismissal they’ll get from whichever random person on the internet needs to entertain themselves that day.

[mlthoughts2018]

> “Having a high degree of confidence that you are capable of building what you are selling is a given.”

No, it is emphatically not a given. Not in the context of some new CRUD tool. Not in the context of latest & greatest self-driving cars. Absolutely not.

> “Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.”

You’re just simply extremely wrong about this. Even internally to a large company you often have projects spun up for face detection, natural language processing, complex workflow management tools, adtech tools, embedded systems, robotics, medical devices, systems dealing with personally identifying information, and on and on.

Expand to include start-ups and the breadth and scope of products being developed grows dramatically.

All the time, across all of these situations, you face engineers, product managers, sales people, and many others, who over-promise on product offerings during initial stage sales piloting. It happens all. the. time. And one of the most serious drivers of this huge and risky oversight is a lack of investment in building parts of the product in advance of attempting to sell it, in order to acquire knowledge that you did not already have regarding the cost and blockers of the engineering implementation.

That you dismiss this as implausible by saying “confidence that you are capable of building what you are selling is given” is nothing other than an indication you do not know what you’re talking about in this topic. I feel frustrated to receive such a rude comment that is self-evidently more focused on trying to undercut me, even mentioning wildly non sequitur things about concise writing as if it applied to the original article, than focused on the actual discussion of the thread.

[tomhoward]

Everything you're saying is valid.

It just doesn't invalidate the point the article is making.

Your point - which I'll paraphrase as don't sell something you can't build - is valid and important.

The article's point - which may be paraphrased as don't build something you can't sell - is also valid and important.

Neither is more important than the other; like basically everything in business there is a tradeoff, and the ones who succeed will be the ones who get the tradeoff right.

But the author makes their point because they see too many people over-optimising on the "build first" approach and failing, when they might have avoided failure if they'd done a bit more "sell first" - or, as the article actually says, "talk to potential customers to properly understand what they want first".

You're getting frustrated (indeed, coming across as enraged) and resorting to strawman and absurdist arguments because you're incorrectly seeing the article as making an absolutist point, and then responding to it with your own opposing absolutist point. If you just approach the topic with appropriate nuance you'll save yourself the need to be frustrated.

Edit: changing implied quotes to be clear they're paraphrased.

[slededit]

Sure at a big company. But this advice is targeted to engineers who want to start their own company. Its unlikely they can even afford any of the layers of cruft you are talking about.

If this was advice for starting some new initiative at BigCorp I might agree with you.

[mlthoughts2018]

The need to build before selling is more critical for start-ups or single person gigs or consulting, because in those situations you don’t have existing stable revenue streams to use to absorb financial or reputational losses that come from underestimating implementation time or cost and failing to deliver sales promises.

If it matters to build before selling in a mature company, it matters even more in a start-up / solo business / consulting feasibility discussion / etc.