Hacker News Reader

Comment by Fergi | Hacker News Reader

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

View on HN

> “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!

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.

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

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

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.

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.

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

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.

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.

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.

Reply on news.ycombinator.com