Live data from Hacker News

Sales mistakes that software engineers make

pipelinedb.com

161–170 of 204 posts

Re: Sales mistakes that software engineers make

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

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.

Also, people are more able to communicate their wants and needs as deltas rather than absolutes. Creating something as a starting point is a great way to seed the conversation and get people thinking, even if that something doesn't end up getting used in the resulting product in any way.

Re: Sales mistakes that software engineers make

#162
While I think this is a great piece — especially the part about listening — and it's something we engineers all need to take to heart, I think its applicability varies depending on the nature of the product and the market.

If you're trying to serve a previously completely unmet need, as many startups are, then this advice is spot on and you should print it out and pin it to your wall. But there are different cases. Sometimes you're trying to bring an incremental advance to a well-established market. In that case there may well already be established marketing and distribution channels, and the value of your product may be readily evident to users of the existing ones. This is especially true in cases where the primary barriers to improvement are technological. To take an extreme example, people working on fusion power don't need to validate the market at all; when they finally build a working plant, they'll just have to plug it into the grid and get paid. Some of the things we build have this character, at least to some extent.

Another exception has to be made for truly visionary products. Sometimes, as Steve Jobs famously pointed out, people don't know they want something until they see it. The Macintosh might be the best example; computer users in 1983 were not generally thinking that they needed a GUI-based OS. This is a dangerous one, though, because we all want to think we're visionaries. If you're going to go down this path, do it with your eyes open, and realize your vision may be wrong — or, more frustratingly, right but too early (e.g. [0]).

[0] https://en.wikipedia.org/wiki/VPL_Research

Re: Sales mistakes that software engineers make

#163
I have to disagree with #1. The overwhelming response at this stage is a big FRIG OFF from the other end who in the past 10 years have steadily been receiving from various "disruptive" startups, who all read the same pile of garbage that is "The Lean Startup", who all preach the same fucked up assumption- that the rest of the world has access to the same socioeconomic environment, "The Country Club", friend of a CEO father who knows people, etc.

I feel that it's no longer a merit based but short term pump and dump in which private equity is traded but not without surrendering your control as the founder and that you are now on the dole on a community of investors that trade shares for pennies and have every legitimate reason to dump it to unsuspecting public market to reap profits.

Advices like #1, In 2018, honestly irrelevant, and increasingly sounding like the new telemarketer. For instance, I repeatedly get calls or emails from a variety of SaaS founders or other developers who started their product that I've grown to detune and avoid them.

The big marketing fields are prohibitively expensive so those with the pocket can bid up and essentially deny competitors access to the same consumers.

Trying to sell something that doesn't exist can be done, but not without compromises with unclear results. Why? The power dynamic is asymmetric due to the sheer capital and a hound of top tier lawyers ready to sink their teeth into your startup.

Meaning, they can even sign a memo or an agreement to express interest and then pull out. What the fuck are you gonna do, sue a Fortune 1000 company?

Re: Sales mistakes that software engineers make

#164

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…

Maybe the answer is to pre-sell a very simple product that you are certain you can build. Any half-decent engineer can build a CRUD app that consumes a spreadsheet and renders some graphs, for example. You can add all the theoretical magic that turns a good product into an amazing one after you build this basic MVP.

Re: Sales mistakes that software engineers make

#165

I have to disagree with #1. The overwhelming response at this stage is a big FRIG OFF from the other end who in the past 10 years have steadily been receiving from various "disruptive" startups, who all read the same pile of garbage that is "The Lean Startup", who all preach the same fucked up assumption- that the rest of the world has access to the same socioeconomic environment, "The Country Club", friend of a CEO…

None of these problems seem unique to selling a product that isn't complete. You're right that selling is hard, but it's done every day in a repeatable way by tons of sales professionals.

Re: Sales mistakes that software engineers make

#166

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…

Fundamentally it's about risk. If your startup is writing OCR that out competes tesseract or automatically diagnoses melanoma that has very different risks than building a B2B product to allow optometrists to manage their clients.

In general though I think most startup's have more go-to-market risk than technical risk. If you can out compete tesseract in OCR you're not going to fail because of market. And if you're Salesforce you're not go to fail because you can't build software to track leads. You're going to failed because you couldn't find enough users.

This is why investors spend so much more time looking at adoption rates, and so little time looking at the backing infrastructure.

Re: Sales mistakes that software engineers make

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

And of course there is the old: "If I had asked people what they wanted, they would have said faster horses." (and there is apparently no evidence that Henry Ford actually uttered those words) While talking to, and most of all listening to customers is important, it too easily leads to building things that people know they want/need. Something truly "revolutionary" is unlikely with that method. Of course, something t…

When talking with customers, focus on the problem, not the solution. The problem: going from here to there takes too long. There are many solutions to that problem. Faster horses are one of them. Cars another. Telephone, flying cars yet another. Not going is also a solution. Etc.

Re: Sales mistakes that software engineers make

#168
Currently I'm in totally "guilty" of #1, but it feels fine and I don't care if it's not the best way to launch something. I want to sell t-shirts online. What kind of research do I need? It's a proven model, people buy t-shirts and other merch online, so the only thing I need is to build it, design it before selling. I just want to build a side project that pays the bills, not going after to outplace major players.

#2 is interesting, I will do this by first selling to friends and talking to them in person to collect enough feedback to do an iteration on the product. I do agree that listening is key.

#3 The ideal situation for you is to have as many signed, legally binding customer contracts as possible

Meh, this is for one specific type of business, there's tons of business models that this doesn't apply to. If the product can collect money from day one, then you won't have the problem of mistaking interest for demand. What's even better is to turn people who are just interested into your advocates.

Re: Sales mistakes that software engineers make

#169

Currently I'm in totally "guilty" of #1, but it feels fine and I don't care if it's not the best way to launch something. I want to sell t-shirts online. What kind of research do I need? It's a proven model, people buy t-shirts and other merch online, so the only thing I need is to build it, design it before selling. I just want to build a side project that pays the bills, not going after to outplace major players. #…

If you are ordering the production of 1,000 shirts hoping that design will sell, you are guilty of #1.

If you are just designing it, putting on a website and will only actually manufacture the shirts you sell, then the solution to #1 is already built in your business model (assuming you are not spending 6 months of coding with your ecommerce website).

Re: Sales mistakes that software engineers make

#170
post #53

Earlier quoted context omitted.

You should have really spent the time it took you to type in this over-the-top response to read the article with a bit more sympathy instead. It's not necessary to solve unsolvable technical challenges to make something that helps people.

How do you know they are solvable if you pick what problems to solve before consulting engineers about feasibility or cost?

Go back and re-read the title, it's literally advice for Software Engineers.
Post reply on HN