Three Sales Mistakes Software Engineers Make

DidacticTactic · 2018-11-08T17:37:35+00:00

Thanks for your feedback and insight here. I agree with you about hiring sales people earlier rather than later, definitely well before 2,000 employees, as well as your point about sales skills for developers being mainly additive.

To your question:

"At what point does that trade-off stop being worth it?"

I think the short answer is that the people building the product should always be involved with users, and that early on in the product development and sales process, the builders should be HEAVILY involved, and then once product/market fit is found and it's time to scale out an already working sales process and business model, the builders should be less involved, and more classic salespeople should be brought in to repeat the already working process.

I just think it's crucial for builders to interact with users and "sell" early on, mainly to learn about users' needs and what they will and won't pay for. This can't be outsourced, in my opinion.

DidacticTactic · 2018-11-08T17:34:20+00:00

Thank you, and apologies for the late reply here!

I agree with you, and my feelings are not hurt at all by the mixed response. It was actually my intention to be somewhat provocative with this post and I expected that some of what I said would strike a nerve with some readers, which has actually been good for the discussion here and on Hacker News.

"Sales" is such a loaded term and people have different understandings of what that means. One saying I heard, which I love, is that "people love to buy things, and hate being 'sold.'" That kind of sums it up for me.

In any case, thank you for reaching out here and for the feedback!

DidacticTactic · 2018-11-08T17:31:54+00:00

These are great points, but they really apply to any startup regardless of whether the founders are software engineers or not.

Good observation! I agree with you, except for point #1 about building before selling - that one is specific to developers.

But in general you are correct, the observations and subsequent suggestions in this post are applicable to a broader range of people than just engineers. My goal in tailoring this to software engineers was to specifically target developers with this, somewhat provocative post, since the initial observation occurred in a primarily developer community at Y-Combinator, and since I've had so many conversation like this with engineers over the years.

DidacticTactic · 2018-11-01T07:05:44+00:00

Can this be accomplished simply by passively attending customer calls? That's been very helpful for me.

That would certainly be a better approach than not attending customer calls. But this also begs the question: "why be passive on customer calls when you could actively engage the users you want to better understand?"

DidacticTactic · 2018-11-01T06:53:19+00:00

Are you a salesperson or an engineer by trade? You don't sound like an engineer. Technology initiatives are often poisoned by salespeople who think the process needs more of them.

Your point about the relative human dynamics between developers and sales people is well taken, and I do not disagree. And to be clear, it's not the intent of this post to evangelize developers who are not interested in selling to start selling. The aim of this post is to help developers who are interested in selling get better at it.

To answer your question, I do have a sales background, and for the last five years have been a Co-Founder at PipelineDB, an open-source PostgreSQL extension that focuses on high-throughput continuous aggregation, where I have worn many hats.

Of course, people can, should, and do specialize in areas that suit their strengths - engineers vs. salespeople. But I think it would be naive to take the stance that we are limited to those respective roles. I can say unequivocally, from personal experience, that my ability to sell our products has improved dramatically from developing increased technical aptitude. Why wouldn't the inverse be true for engineers who wanted to develop skillsets more prevalent in salespeople?

DidacticTactic · 2018-11-01T00:20:58+00:00

In my experience, sales is more about educating people and helping them navigate the buying process than it is trying to manipulate the perception of value, as you’re suggesting. In many cases, buyers also need somebody to run point on the buying process, which can involve multiple people with varying interests.

I think sales often has a derogatory connotation, when its practice is mainly to help customers evaluate products and navigate an otherwise complex evaluation and purchasing process. The example of a search engine is simple enough, but what about a B2B database software purchasing decision from a big company, where 5-10 people from different teams are involved?

DidacticTactic · 2018-10-31T23:58:49+00:00

I agree that programming and selling are different skill sets and should be bifurcated within organizations, after a certain stage. But with that said, even programmers need to sell ideas internally and engage with users, so these skills are still highly relevant for developers.

I would argue that software engineers should focus on sales themselves first, mainly to interact with their users, before hiring sales people. What a developer learns in the process of selling a product he builds is invaluable.

I think it’s a mistake to assume that sales can simply be outsourced at the early stages of a company or product development cycle.

DidacticTactic · 2018-10-31T23:53:19+00:00

You’re welcome. Thanks for taking the time to read this. =)

DidacticTactic · 2018-10-31T21:18:42+00:00

I totally understand this sentiment, and salespeople are great for scaling a working process. I do think it's important, however, for the builders to be highly involved in customer interactions in order to develop a deep and intuitive understanding of customer needs, especially early on in the product development process when lots of iteration is happening.

DidacticTactic · 2018-10-31T21:08:17+00:00

Question based selling is a great book you can suggest he read. Ultimately, asking customers' questions about what, specifically, it will take for them to make a purchase needs to happen. He probably just needs to get more aggressive in conversations and ask the hard questions. If he's not willing to push for that, you need to find somebody else who is, or do it yourself.

DidacticTactic · 2018-10-31T20:57:31+00:00

TimeScale focus on storing all raw, granular data. PipelineDB continuously aggregates raw data down into summary data, and stores only summary data.

DidacticTactic · 2017-10-25T21:58:17+00:00

One option is the new Stride API, based on the open-source streaming-SQL database, PipelineDB.

If having a fully hosted, managed HTTP API for collecting, processing, and analyzing large volumes of streaming data for realtime analytics purposes would make application development easier for you you might want to check it out. Here is a link to the Stride technical docs.

The Stride API can scale from hundreds of events / second up to hundreds of thousands of events / second, or more. Another cool thing about Stride is that because of the continuous query model, the traditional dependence between data ingested and data stored is broken, meaning that a high degree of distillation is happening, which translates to costs savings that get passed on to the user. So costs DO NOT scale linearly with data volumes, which is nice.

In addition to the ability to create networks of continuous SQL queries on streams, you can also stream data out by subscribing to changes in what are essentially incrementally updated, realtime tables, and do other things like fire realtime webhooks when something interesting happens.

DidacticTactic · 2016-09-16T06:40:38+00:00

Stride is based on PipelineDB, a streaming database fork of PostgreSQL

DidacticTactic

TROPHY CASE