[deleted]
Sales mistakes that software engineers make
31–40 of 204 posts
Re: Sales mistakes that software engineers make
#32While the read was interesting and bring solid points, I strongly disagree with the majority of the arguments. >The biggest mistake I see developers make is assuming that they are building something that people both want and will pay a meaningful amount of money for. Lots of projects were build with no exact plan on how to monetize them of if there would be customers to buy it. They just had a vision about how X or Y…
">The best way to do this is by asking good questions, and then listening carefully and taking notes
Again I strongly disagree here. This pattern pushes entrepreneurs to create a version++ of something"
... --> not if you are actually listening!
Listening is not about 'let them tell us what feature they want' ... it's 'problem discovery'.
This is maybe the most valuable thing because young devs with 0 exposure to how operations actually work within a company will have their eyes opened wide.
This is where you can hone in on both real and perceived pain points, and develop the lingo that will work in messaging as you go to sell the 'learned' product you make ...
Re: Sales mistakes that software engineers make
#33While the read was interesting and bring solid points, I strongly disagree with the majority of the arguments. >The biggest mistake I see developers make is assuming that they are building something that people both want and will pay a meaningful amount of money for. Lots of projects were build with no exact plan on how to monetize them of if there would be customers to buy it. They just had a vision about how X or Y…
I don't see listening carefully and asking open ended questions as a step towards simply building what the potential customer wants. Quite the opposite: seeking to understand their underlying needs, the context they are in, and the factors influencing their thinking helps build empathy. If we truly understand the needs we are trying to fulfil it is more likely that we will build a good product, it's a superficial und…
Open ended questions is how you understand their underlying needs.
"What are your pain points" and "so why is that an issue" can give you incredible insight just by listening. They should be doing 90 percent of the talking. honestly playing dumb is powerful.
Engineers tend to want to be right and give answers which make them terrible sales people.
Re: Sales mistakes that software engineers make
#34Surprisingly good one. Usually it is "not asking high-enough prices" kind of bullshit. I have been burned by 1 and 3 more than once. Also I have lots of ideas which actually have no real demand, like to list cheap, remote, nice and quiet, organic locations in Asia yet suitable for remote working and long-term stay, like Sikkim or Nepal or Ladakh (order of magnitude cheaper than Thai coast line). But, unfortunately, t…
I would buy account on such service, and I bet I know a few more guys that would pay for such information with details and human reviews.
Re: Sales mistakes that software engineers make
#35The 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, see how hard it would be and what the unexpected sources of engineering difficulty would be, and then scope our sales vision or pitches accordingly.
That particular product team failed badly and the product line was closed down. We started selling before building, and only later realized that when you do that, you’re talking out of your ass and you are doing a huge disservice to prospective clients who buy into your sales pitch just to be let down later when you cannot execute on the implementation for reasons that could have been known if only you had invested in building things first.
The same issue can also play out with costs: maybe you technically can build what you sold, but because you over-promised in the sales pitches, you end up in a situation where to be able to offer what was actually sold, the engineering costs force it to be intrinsically unprofitable, while had you known the cost projections from building first, you might have been able to scope the sales pitch to only a profitable set of features.
It’s way easier to throw away / rebuild something later when sales feedback indicates you should pivot than it is to build nothing at all, over-promise, and try to keep clients who end up unhappy that you misled them.
The cost of building first so you have adequate information about what it would require to profitably support selling a certain product or feature set is known as _investment_.
Re: Sales mistakes that software engineers make
#36While the read was interesting and bring solid points, I strongly disagree with the majority of the arguments. >The biggest mistake I see developers make is assuming that they are building something that people both want and will pay a meaningful amount of money for. Lots of projects were build with no exact plan on how to monetize them of if there would be customers to buy it. They just had a vision about how X or Y…
>"We are using [Insert Tech Name] and it doesn't support feature X" >So the entrepreneurs would rush to it's keyboard create a clone of the Tech and add the feature X. Uhm, why is this bad? Haven't we all seen examples of companies that do the same stuff as other companies but better and succeed? I'm pretty sure even pg wrote about this in one of his "How to start a start-up" essays.
Uhm, why is this bad?
There are two big problems. If someone has lived without X for long enough they've probably found workarounds for living without X so that just adding X might not be that valuable to them or at least it might be hard to convince them how valuable it is to have X. The second is you often greatly underestimate how much work it is to get to the point where you have a good enough clone to even have something to add X to. And while you're busy working on your clone the original company might get around to adding X and thus undermining your whole business.
Haven't we all seen examples of companies that do the same stuff as other companies but better and succeed?
Sure, but they're often better in a whole category of ways (price or speed or ease of use etc.) and not just a clone of an existing product with X added.
Re: Sales mistakes that software engineers make
#37While the read was interesting and bring solid points, I strongly disagree with the majority of the arguments. >The biggest mistake I see developers make is assuming that they are building something that people both want and will pay a meaningful amount of money for. Lots of projects were build with no exact plan on how to monetize them of if there would be customers to buy it. They just had a vision about how X or Y…
(Jeff from PipelineDB / author here) Thanks for the honest feedback. You are definitely correct that there are many successful projects and businesses that did not start with a clear sense that people would use or buy their products. But there are a disproportionately large number of projects and businesses that have failed, precisely because they did not have a clear sense that people wanted what they were making an…
I agree with tinyvm and I agree with your replies, it all should be part of the wisdom.
I have the honor of making all three mistakes you mention and my project didn't end up well :).
Re: Sales mistakes that software engineers make
#38How about all the mistakes companies make due to “sales” people? How many times have sales-oriented execs driven companies into the ground in the past 40+ years in tech? They nearly killed Apple. I am not harping on the article. It’s a good read for indy developers.
Re: Sales mistakes that software engineers make
#39I can resonate with this so much.
Just recently I had an idea for a product and rushed to building it because it “solved” a problem.
But then when it came to trying to get some sales it has been a failure. The only people that were willing to buy the product didn’t understand it.
When starting out in my opinion if you don’t have a large network of people in the tech industry it’s important to focus on products that either increase sales or save a lot of money (3-4x cheaper than existing solutions).
I find that the products that sell have to be a no brainer deal.
I wrote about what I learned building and selling a cybersecurity saas here, don’t make my same mistakes: https://ferrucc.io/posts/sales-for-cybersecurity-saas/
Re: Sales mistakes that software engineers make
#40>Sales Mistake #1 - Building Before you Start Selling What if the customer wants to see a demo ? Is it better to inform them from the very start that this is a conversation about the product that is non existent ? Isn't it better to have a MVP in place. Almost all the sales guides/people tell this. But this is also something I can't get my head around.
(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…
> “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!