Live data from Hacker News

Sales mistakes that software engineers make

pipelinedb.com

151–160 of 204 posts

Re: Sales mistakes that software engineers make

#151

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

AFAIK, YouTube started as a dating site and then pivoted based on actual usage patterns. See https://www.cnet.com/news/youtube-started-as-an-online-datin....

The whole thing wasn't built to become what it did. That's why you shouldn't build (too much) before starting to sell.

Re: Sales mistakes that software engineers make

#152
post #134

Earlier quoted context omitted.

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.

A few years ago I wanted to make a niche marketplace to sell/trade tabletop miniatures. Instead of actually building the thing, I made a few mockup interfaces pages, and then just made a responsive HTML page. None of the buttons actually worked. I then put a modal that said "launching soon, sign up now for news and a special bonus on launch". I spent $100 on ads on reddit and targeted forums with the goal to get 100…

How did you determine if that 100 email cutoff you set is reasonable or not? Honest question.

Re: Sales mistakes that software engineers make

#153
post #144

Earlier quoted context omitted.

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

Yes, that is my opinion. And if it's possible to build something minimal that helps demo or describe the product to users, it's totally reasonable to build that thing quickly and take it to customers for feedback.

The pitfall to avoid is investing large amounts of time, energy, and money building products in a vacuum based on assumptions about what people want and will pay for. I've heard this referred to as committing "assume-icide."

Re: Sales mistakes that software engineers make

#154
post #144

Earlier quoted context omitted.

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

> you have a higher chance by plotting it out and then executing, than accidentally stumbling upon a perfect business model for your completed product.

You have a higher chance of stumbling upon a perfect business model by speaking to the customers before / during product design.

Re: Sales mistakes that software engineers make

#155

Earlier quoted context omitted.

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 totally agree with you if we are talking about preliminary market research, which also usually involves components of research into the technical investment required. That said, the article of this post seems to emphatically say something different: that you should actively _sell_ before building. Not merely collect research, but to sell stuff you do not already have the capability to deliver, and then somehow back…

I guess the question is, are you building another CRUD/business workflow app? Or inventing self-driving car algorithms with a KITT AI?

One is highly possible and likely, the other is not. Most ideas will be somewhere in between.

Re: Sales mistakes that software engineers make

#156
post #111

Earlier quoted context omitted.

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

Yes, and this is the part I can't seem to figure out. I think it's more of a personality/networking issue. Right now I have an MVP of a function as a service platform; a general purpose development tool. I'm thinking meetups are the best bet, just to meet people, ask questions, and listen to pain points. But that alone is a skill set that needs to be cultivated; asking the right questions, not coming off as pushy, be…

I find presenting your experience can help a lot at local dev meetups and conferences. If you can find a venue for pitching your product, then great! But most of the time, people don't want to hear a product pitch. Instead, present ideas or work that is related with the goal of the community viewing you as an expert. Writing books or blogs can also help with this. And in your presentations, put your company's logo in the corner.

The nice thing is that presentations shine a spotlight on you, and then potential customers will come to you rather than you having to go to them. Eventually you will need to do the latter, but your first customers are likely to be people in the crowd watching your presentations or their friends. When you do start having to go find more customers, you will have a much better idea who to target as well and have at least a small network to utilize.

Re: Sales mistakes that software engineers make

#157

Earlier quoted context omitted.

This is all very true and relevant, yet still its also true that we see lots of stories from founders regretting that they never established market fit before sinking years into development. This is probably the pattern for 90% of indie game developers, but it crops up in other contexts as well. Once they finally know they are at the end of that road to nowhere, they do have regrets, and they have had other ideas in…

Is it possible to do indie game dev without building something and throwing it out there? Small games seem like a market where it's nearly impossible to know what's going to sell ahead of time, because buyers don't know what they want until they see it. Or until a lot of people are telling them it's the Next New Thing. It's relatively easy to research a market where you're offering a practical solution to a real prob…

Prototype. Make a pen-and-paper version, pantomime the game, tell the story -- do something to test the game's excitement power before building it.

http://www.pathsensitive.com/2015/10/the-prototype-stereotyp...

Re: Sales mistakes that software engineers make

#158
post #134

Earlier quoted context omitted.

A few years ago I wanted to make a niche marketplace to sell/trade tabletop miniatures. Instead of actually building the thing, I made a few mockup interfaces pages, and then just made a responsive HTML page. None of the buttons actually worked. I then put a modal that said "launching soon, sign up now for news and a special bonus on launch". I spent $100 on ads on reddit and targeted forums with the goal to get 100…

How did you determine if that 100 email cutoff you set is reasonable or not? Honest question.

I knew it was a small niche market, and I set it as really a "reasonable" goal.

"If 100 people in 30 days are interested with this ad spend, then I'll reach out engage them and build the thing."

Depending on your app/market, you can change that number accordingly, but I think 100 is just a great "feel good" number thats hard enough to hit as evidenced by my test.

Re: Sales mistakes that software engineers make

#159

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…

Another way to find people using X is to find tech conferences on X. Most software tech have conferences now.

Re: Sales mistakes that software engineers make

#160

Earlier quoted context omitted.

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.

I am poor therefore I write my own software.
Post reply on HN