[Fergi]

(Jeff from PipelineDB / author here)

Good questions!

I would definitely suggest being straightforward and honest with the potential customers you're talking to. And ideally, it would be better to have a MVP you can demo than nothing, but the main point here is that talking to potential customers before building anything is a better strategy than building a product and then talking to customers.

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.

The trap to avoid here is building products in a vacuum, based on assumptions about what people want and will pay for. Doing the customer development (pre-sales) work to prove, or disprove, customer demand for a product before building the product is wise.

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