Live data from Hacker News

Sales mistakes that software engineers make

pipelinedb.com

111–120 of 204 posts

Re: Sales mistakes that software engineers make

#111

I fall into the "Build before talking to customers" trap constantly. Even though I know it's "wrong", it is hard to escape it because of the simple problem of not knowing who to talk to. The article suggests doing a search for potential companies, finding contacts on linkedin, and sending out some emails. But what about experimental technologies or developer tools? I wouldn't expect a lot of success with a slow movin…

> I fall into the "Build before talking to customers" trap constantly. Even though I know it's "wrong", it is hard to escape it because of the simple problem of not knowing who to talk to.

Then you have a different problem - you don't have a way to reach target customers.

Even if you build your product, how are you going to build a sales pipeline? Your customers won't hear about your product by themselves - you have to get it to them. Many many companies make products that are good, are actually useful, but they don't know how to build the marketing/sales pipeline that will actually make their products profitable.

And just like validating the product to build - building/validating a sales strategy is usually something you should do before building the product, both because it's harder, and because findings there may change what product you end up building.

Re: Sales mistakes that software engineers make

#112
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…

Well how is my audience supposed to know what I have to offer until they have it in front of them? Before that it's just me telling them an idea. Even after it's done I would not expect users to start using it on their own. Then you have to play a whole different game of getting people to use it.

Re: Sales mistakes that software engineers make

#113

The first point is often totally wrong. I worked in a place where the sales team sold the product hard before much of it was built and before it was reliable. It turned out to be way harder to build what customers actually wanted than anyone knew ahead of time. Nobody could foresee it. The only way we could have known we were egregiously over-promising in the sales pitches was to just actually start building it first…

I've seen a similar situation play out at a startup and I can see your point. However, I think there's a difference between talking to potential customers about requirements they have vs. promising to deliver a solution for them on the spot. IMO you don't have to, or rather shouldn't, close the sale when first reaching out to potential customers like this. The goal should be to simply validate the problem statement -…

I mostly agree. The only difficulty is that what people will say and what people will pay are not always aligned.

Re: Sales mistakes that software engineers make

#114
I sometimes don't understand why technical people seem resistant to "lean startup" methodologies. It's just the scientific method, applied to build a product! You build hypotheses, then try to prove them, and in the course of this, usually learn more information about the world. That simple.

You think you have a product which is useful to someone? Prove it! Talk to people, ask them, build simple prototypes of the core parts.

You think you know how to sell your product? Prove it! Build out some sort of pipeline, e.g. use a landing page and see if you can get people to it.

Etc.

There are good and bad ways to do this, obviously, and it's not easy. But the basic idea is simple enough - and most of the arguments against it sound pretty much the same as how it would sound for someone to be against scientific experiments and hypothesis testing.

Re: Sales mistakes that software engineers make

#115

Selling something before you make it is highly unethical. You have no idea if you can actually make it, so you run the risk of committing fraud. Additionally, such a strategy could only work if what you're making is very simple. If it's complex, is your customer really going to be okay with "please sign here and we'll get it to you in the next year." Have a dream. Turn it into a vision. Make a business plan. Create a…

> Selling something before you make it is highly unethical. You have no idea if you can actually make it, so you run the risk of committing fraud.

Wrong and wrong

It is VERY common across all industries to have customers pre-pay. In fact, I wouldn't take a potential customer's "interest" in meaning anything if they don't put their money where there mouth is.

Re: Sales mistakes that software engineers make

#116

I fall into the "Build before talking to customers" trap constantly. Even though I know it's "wrong", it is hard to escape it because of the simple problem of not knowing who to talk to. The article suggests doing a search for potential companies, finding contacts on linkedin, and sending out some emails. But what about experimental technologies or developer tools? I wouldn't expect a lot of success with a slow movin…

> there's no way to search "startups using x" for a generic technology, like serverless or NoSQL. Smells like a side project waiting to be built.

Crunchbase has a Built With section. I'm not sure how its constructed, but I'm guessing it only looks at what it can determine from a company's site. I suppose github could be another source.

Re: Sales mistakes that software engineers make

#117
post #48

Selling something before you make it is highly unethical. You have no idea if you can actually make it, so you run the risk of committing fraud. Additionally, such a strategy could only work if what you're making is very simple. If it's complex, is your customer really going to be okay with "please sign here and we'll get it to you in the next year." Have a dream. Turn it into a vision. Make a business plan. Create a…

The point is to first validate your idea by asking people if they're actually willing to pay for your service, hypothetically. I don't think the author means actually setting up a contract where the potential interested parties actually pay you upfront for a service that doesn't exist.

There is no greater indicator of interest than having a customer willing to pay up front. I have been on both sides of such deals in my career.

Re: Sales mistakes that software engineers make

#118
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 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 market research, gut feeling, whatever) and then try selling it. Doing it the other way around is the definition of vaporware.

Re: Sales mistakes that software engineers make

#119

The first point is often totally wrong. I worked in a place where the sales team sold the product hard before much of it was built and before it was reliable. It turned out to be way harder to build what customers actually wanted than anyone knew ahead of time. Nobody could foresee it. The only way we could have known we were egregiously over-promising in the sales pitches was to just actually start building it first…

I've seen a similar situation play out at a startup and I can see your point. However, I think there's a difference between talking to potential customers about requirements they have vs. promising to deliver a solution for them on the spot. IMO you don't have to, or rather shouldn't, close the sale when first reaching out to potential customers like this. The goal should be to simply validate the problem statement -…

I'd also add that you should find common requirements that customers have and build your solution around those.

Much better to have 100s of customers using a product with 1 feature, than 1000s of customers using a product with 1000s of features (with the corresponding overhead).

Re: Sales mistakes that software engineers make

#120

I fall into the "Build before talking to customers" trap constantly. Even though I know it's "wrong", it is hard to escape it because of the simple problem of not knowing who to talk to. The article suggests doing a search for potential companies, finding contacts on linkedin, and sending out some emails. But what about experimental technologies or developer tools? I wouldn't expect a lot of success with a slow movin…

>finding contacts on linkedin, and sending out some emails Has that ever worked? I'm not on LinkedIn, yet somehow companies still find my work email and I'm always getting emails from people about how there product is the best thing ever and can we set up a call, or there is a webinar, or can they come by. Oh, and did I not see their previous attempts to reach me? Yes, I saw them, but I've never responded to any of t…

Notably, cold calling/emailing works badly for developer tools, decisions are made rarely and we’re pretty locked in once a project is underway. Which is one reason we resist doing it.

But many categories, where you solve a common and easily described business need, it can work great. This is one if the best guidelines for designing a product to sell.

Post reply on HN