Sales mistakes that software engineers make
pipelinedb.com
Sales mistakes that software engineers make
1–10 of 204 posts
Re: Sales mistakes that software engineers make
#2>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.
Re: Sales mistakes that software engineers make
#3>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.
Sales people can sell things they don't have on hand, and doing the selling first can help verify that the proposed product is in fact, a good fit for the market (or that the market even exists).
Re: Sales mistakes that software engineers make
#4>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.
I'm not fully qualified to answer but from my experience in building our product, sales isn't necessarily about pitching - if you're actively listening to potential users you're able to better understand what to even build. The article actually does a great job of explaining this imo.
Re: Sales mistakes that software engineers make
#5>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 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.
Re: Sales mistakes that software engineers make
#6>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.
What we did was making a landing page somewhere, "sign up for limited beta access", and gauge interest that way. We collected a few email addresses, but it was mostly for validation of the idea, that there was a genuine audience.
Re: Sales mistakes that software engineers make
#7While 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 technology should be , and just created something by putting their guts in it.
The idea that you should marketize something before starting to build is coherent but not true for tech especially when Innovation sometimes requires to educate the customers about how to use a technology , Serverless and Docker are good examples of that I think.
>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 already existing because the customers told them :
"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.
This is usually called consulting in my opinion and they are already lots of people doing that... Being a "Founder" of something involve taking risk and not just adding a tiny feature because it can brings money on the short term.
It's about having a vision.
As a result , we could quote the hundreds of email startups we have today who basically do the same thing with often one tiny feature of difference...
> that does not mean that you have created enough incremental value for customers to make them willing to pay you a meaningful amount of money for your product
I agree on this one.
Re: Sales mistakes that software engineers make
#8>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.
The fantasy product in their mind is often a more compelling product than the actual product. See: Kickstarter.
Re: Sales mistakes that software engineers make
#9>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.
What we did was making a landing page somewhere, "sign up for limited beta access", and gauge interest that way. We collected a few email addresses, but it was mostly for validation of the idea, that there was a genuine audience.
I think this is a smart strategy, and is essentially using marketing in the same way that this post suggests using sales, to gauge customer interest in a potential product. The extent to which manual sales outreach or the kind of marketing technique described here should be used likely depends on the kind of product in question. B2B products with higher contract prices and a smaller number of total potential customers will likely require a sales strategy, where B2C products with lots of users and lower contract values may be better served with this kind of marketing tactic.
Great point, though! This is an important topic to consider with marketing and sales strategy development. Thanks for the comment.
Re: Sales mistakes that software engineers make
#10While 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.