Live data from Hacker News

Sales mistakes that software engineers make

pipelinedb.com

141–150 of 204 posts

Re: Sales mistakes that software engineers make

#141
post #137
post #24

> Sales Mistake #1 - Building Before you Start Selling (...) If you’re wrong, you’ll save time and money by not building something people don’t want. I fell into this trap often, so I know it well. The reason why we don't ask first is, we want to build something . Anything. If we're "wrong", we won't "save" time and money, we will delay the moment we start making, maybe indefinitely. What if we never find something p…

True. Especially when I build something that solves one of my own problems. I think it's great and maybe others would like it too. Then I discover that amongst all of humanity, I have problems which are absolutely unique and shared by no one else, anywhere.

Don't be so hard on yourself. Someone else somewhere probably does have each problem that you have.

But finding them is prohibitively costly.

Re: Sales mistakes that software engineers make

#142
post #24

> Sales Mistake #1 - Building Before you Start Selling (...) If you’re wrong, you’ll save time and money by not building something people don’t want. I fell into this trap often, so I know it well. The reason why we don't ask first is, we want to build something . Anything. If we're "wrong", we won't "save" time and money, we will delay the moment we start making, maybe indefinitely. What if we never find something p…

It's not irrational. People often don't know what they want, or think they know but often devise overly elaborate solutions. Also, building before asking means you can potentially create a new market with a new product that's never been seen before, which is far more lucrative.

See YouTube

Re: Sales mistakes that software engineers make

#143
post #24

> Sales Mistake #1 - Building Before you Start Selling (...) If you’re wrong, you’ll save time and money by not building something people don’t want. I fell into this trap often, so I know it well. The reason why we don't ask first is, we want to build something . Anything. If we're "wrong", we won't "save" time and money, we will delay the moment we start making, maybe indefinitely. What if we never find something p…

I agree. Its most often the case that we arrive at problem to solve based on our own experiences/or troubles. A builders passion is fueled by his own problem and he can think of selling it if he see that the problem is present in life of others as well. Most successful products starts like this.

Trying to hunt for problem that others are facing won't is not at all motivating for a hacker mentality. And even if he is able to discover challenges of others he probably won't be able to execute the solution for it as neatly as he cad do for challenges of his own life.

Re: Sales mistakes that software engineers make

#144
post #24

> Sales Mistake #1 - Building Before you Start Selling (...) If you’re wrong, you’ll save time and money by not building something people don’t want. I fell into this trap often, so I know it well. The reason why we don't ask first is, we want to build something . Anything. If we're "wrong", we won't "save" time and money, we will delay the moment we start making, maybe indefinitely. What if we never find something p…

(Jeff from PipelineDB & post author here)

Thanks for this comment. I think you articulated the thought process that this post aims to speak to beautifully. Builders do want to build, and finding an audience first and doing the type of tedious customer development work described in this post IS an impediment to building, which is precisely the point I wanted to make.

Assuming that the goal of building a product is to ultimately generate revenue, having a temporary impediment between conceptualizing a product idea and building the product is a good thing. This impediment allows for the builder to pause and objectively scrutinize his own idea, using feedback from potential customers as data about the extent to which the product hypothesis is correct.

You're right that stagnation is the worst outcome. And the inverse of stagnation is momentum, which will exist to the extent that people want what we're making for them, something that can be determined in advance of building simply by talking to potential users and customers.

I'll also add here that the process mentioned in this post in no way inhibits the type of creative and inspired thinking that developers use to envision game-changing products. It's quite the opposite - rigorous and merciless scrutiny of our own ideas is the distillation process that allows us to refine our ideas into their essence, then confidently build things with conviction, and be right.

Re: Sales mistakes that software engineers make

#145

Earlier quoted context omitted.

I have also been here too many times to count. My take on it is that it's not a failure as long as you've learned something. In my case, for the first number of projects I built that nobody bought/wanted, I didn't learn to find the market first (sadly), but I did learn a huge amount about how to build things. Now I can build better things faster - but I'm actively learning to find the market.

I've been on the other side of this too often too. Sales selling things that don't exist yet, promising conflicting or impossible features and of course a ridiculous deadline. If you're doing bespoke work, sure you wait for a customer to define what they need. But if you're working on a product, then what a single customer wants is not very relevant. You build something that you think the market wants (based on marke…

On the contrary, doing it the other way ensures that when you’re done someone is willing to buy what you built. It’s not about what one customer wants defining what you build, but rather having commitment from a handful of customers that they would buy what you propose to build. There’s a huge gap between securing a commitment to buy a future product and announcing vaporware you have no intention or ability to ship.

Re: Sales mistakes that software engineers make

#146

I want to echo point #2 about listening rather than talking. When I first pitched my work to radiation therapy vendors at big conferences, I was expecting a kind of adversarial exchange to take place where I'd have to defend my software against cynical people trying to find its flaws, shark-tank style. Instead I found that vendors were dying to tell me what they need and what's important for them. I quickly realised…

This can be dangerous as well though. Most people aren't naturally adversarial and get uncomfortable pushing down paths where you don't know the answer or seem unprepared.

You often won't get someone to really challenge your assumptions unless they have some meaningful motivation. So you may have to listen in a different way than you're used to, or push people a bit to get them really comfortable with telling you things they might think you don't want to hear.

Re: Sales mistakes that software engineers make

#147

Earlier quoted context omitted.

It's not irrational. People often don't know what they want, or think they know but often devise overly elaborate solutions. Also, building before asking means you can potentially create a new market with a new product that's never been seen before, which is far more lucrative.

See YouTube

[deleted]

Re: Sales mistakes that software engineers make

#148
post #144
post #24

> Sales Mistake #1 - Building Before you Start Selling (...) If you’re wrong, you’ll save time and money by not building something people don’t want. I fell into this trap often, so I know it well. The reason why we don't ask first is, we want to build something . Anything. If we're "wrong", we won't "save" time and money, we will delay the moment we start making, maybe indefinitely. What if we never find something p…

(Jeff from PipelineDB & post author here) Thanks for this comment. I think you articulated the thought process that this post aims to speak to beautifully. Builders do want to build, and finding an audience first and doing the type of tedious customer development work described in this post IS an impediment to building, which is precisely the point I wanted to make. Assuming that the goal of building a product is to…

So to summarize (for my own understanding)... It's fine to want to build something first. However, if you want it to be financially profitable in a big scope of impact, you have a higher chance by plotting it out and then executing, than accidentally stumbling upon a perfect business model for your completed product.

Re: Sales mistakes that software engineers make

#149
post #24

> Sales Mistake #1 - Building Before you Start Selling (...) If you’re wrong, you’ll save time and money by not building something people don’t want. I fell into this trap often, so I know it well. The reason why we don't ask first is, we want to build something . Anything. If we're "wrong", we won't "save" time and money, we will delay the moment we start making, maybe indefinitely. What if we never find something p…

Couldn't have said it better. I am another one of those people here with the same experience.

Ironically, building because of being afraid that nothing will be built often leads to exactly that outcome: months or years spent on something that nobody ever uses. Now it's built, but it doesn't matter, which is essentially the same as if it had never been built. In my experience, this really often is a self-fulfilling prophecy. And it has a tendency to become a vicious circle when the fear becomes self-reinforcing.

Re: Sales mistakes that software engineers make

#150
post #137

Earlier quoted context omitted.

True. Especially when I build something that solves one of my own problems. I think it's great and maybe others would like it too. Then I discover that amongst all of humanity, I have problems which are absolutely unique and shared by no one else, anywhere.

Don't be so hard on yourself. Someone else somewhere probably does have each problem that you have. But finding them is prohibitively costly.

And they're poor.
Post reply on HN