[mlthoughts2018]

> “If you talk to a bunch of potential customers about a product idea and discover that there is demand for the product, then building a MVP that you can demo would be a logical next step. And if the MVP is something you can build quickly, then it probably makes sense to do this sooner than later.”

Sales to Engineering Managers:

Alright team, we’ve talked with a lot of customers and realized there is a huge demand for this thing called a perpetual motion machine. Let’s try to get a prototype built for the client on-site next week, ok?

Engineering Managers to Engineers:

Alright everyone, we scoped out this perpetual motion machine into 3 Jira tickets. The first ticket is 3 unitless Fibonacci numbers of work, to create the base machine we’re talking about here. The next ticket is another 3 units to have someone mock-up the motion part, not sure exactly what they want here but maybe just put an RC car underneath of the machine from the first ticket? Finally we saw “perpetual” in the request from sales and that really sounded like a time sink so we pushed back. We’re going to time box this one and call it a 2-pointer. We’re thinking don’t spend more than a few hours on the perpetual part. Let’s do it everyone!

Engineers to recruiters:

The job just isn’t allowing me to fulfill the technical goals I want to pursue.

Recruiters to engineers:

I’ve got a hot new start-up you’d be great for. They only pay 60% of market rates but they totally need someone who can build out their entirely unvetted vision of what products to sell!

[yread]

You should have really spent the time it took you to type in this over-the-top response to read the article with a bit more sympathy instead. It's not necessary to solve unsolvable technical challenges to make something that helps people.

[mlthoughts2018]

How do you know they are solvable if you pick what problems to solve before consulting engineers about feasibility or cost?

[slededit]

Go back and re-read the title, it's literally advice for Software Engineers.

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