
Sales mistakes that software engineers make - Fergi
https://www.pipelinedb.com/blog/three-sales-mistakes-software-engineers-make
======
bambax
> _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 people want?

The worst outcome is not to build something nobody wants -- it's not to build
anything. We don't ask not because we forget about it, but because we're
afraid of the answer.

Yes, it's irrational, and probably stupid (because, what's the point of
building something nobody wants?) but the desire to build is the driving
force, and finding an audience first, is perceived as an impediment.

~~~
nobody271
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.

~~~
lbotos
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
emails. If I got 100 emails, I would actually try and build the thing.

I got ~57.

You can market very far without anything that works. This is the "growth
hack/MVP" mindset. I saved myself weeks of programming which would have been
fun, but arguably a waste to building that specific business.

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

~~~
lbotos
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.

------
mlthoughts2018
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, 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_.

~~~
martinraag
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 - if that's done with enough potential customers you
should move on to the next part of planning and building the initial
implementation.

To your point, new information might still surface at this point, which could
lead to the project being dropped. Having not sold (promised a solution) to
anyone at this point, the likelihood of unhappy clients is rather low.

All that said, I think calling this initial work "sales" might give the wrong
impression here, as I would categorise it more as market research. Whoever is
carrying this work out should be very aware of this and not actually close the
sale on something they are uncertain can be delivered in a profitable manner.

~~~
mlthoughts2018
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 backfill that delivery capability after getting customer buy-
in.

~~~
mixmastamyk
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.

~~~
mlthoughts2018
I’d say even for some new CRUD app, assumptions that it will be easy to build
are so, so common, and the reality of most “super simple CRUD apps” is that
the implementation is way harder than you thought, and selling advanced
features before you definitively know how to build them is a big source of
failure for seemingly straightforward products.

It’s very much sales hubris to _ever_ believe you know how to build something
you’ve never built before, even in cases when it might seemlike a minor
variation of something you built before.

------
fuball63
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 moving Fortune 1000 company in my city, and there's no way to search
"startups using x" for a generic technology, like serverless or NoSQL.

I have found a little success going to meetups and talking in person to other
developers and entrepreneurs, so maybe I need to more aggressively take this
route. The internet is too big/impersonal/oversaturated from what I can tell.

What would really be helpful as a software engineer is a guide on how to
improve entrepreneurial networking, which has to be the foundation before
tackling some of the techniques in this article.

~~~
irrational
>finding contacts on linkedin, and sending out some emails

Has that ever worked? I'm not on LinkedIn, yet somehow companies still find my
work email and I'm always getting emails from people about how there product
is the best thing ever and can we set up a call, or there is a webinar, or can
they come by. Oh, and did I not see their previous attempts to reach me? Yes,
I saw them, but I've never responded to any of them from anyone. I just can't
imagine cold-calling/emailing people actually works.

The best thing you can do is to make sure you appear high in the google
rankings so that when I have a need and start searching for whom might be able
to fill that need, you come up near the top.

~~~
maxsilver
> I just can't imagine cold-calling/emailing people actually works.

I felt this way for the longest time. I _hate_ cold calls. I hate making them,
I hate recieving them. Everyone I've ever talked to claims to hate cold calls.
Why do people still do this. Who the hell is buying from cold calls?

So I sat down with a couple of people from a sales team, and just asked them
what they did. And apparently, a good chunk of their day is legitimately just
cold-calls. (Literally through the phone book, or through LinkedIn, or
tradeshow cold-stops, etc). While a cold call almost never translate into an
instant sale, we can trace most sales back to a start from a cold call.

They don't sell pecan pies or double glazing either. _Enterprise software_ at
price tags _over $100k /each_, or custom development engagements at
_$100-300k_. And it usually starts with a cold call.

So while it still sounds absolutely insane to me, multiple sales people have
told me that _cold calls work_. And these folks regularly win deals and earn
good commissions, so I tend to believe them.

~~~
agilebyte
And a good sales person will be one that is OK making cold calls over and over
knowing that wast majority of them will be a dud.

------
loarake
I want to echo point #2 about listening rather than talking. When I first
pitched my work to radiation therapy vendors at big conferences, I was
expecting a kind of adversarial exchange to take place where I'd have to
defend my software against cynical people trying to find its flaws, shark-tank
style.

Instead I found that vendors were dying to tell _me_ what they need and what's
important for them. I quickly realised that the most important part after
giving my pitch was to basically ask tons of questions about what they think
is important and why. The vendors' answers were invaluable in honing my pitch
for other vendors, but also to steer the direction of my project.

~~~
stanleydrew
This can be dangerous as well though. Most people aren't naturally adversarial
and get uncomfortable pushing down paths where you don't know the answer or
seem unprepared.

You often won't get someone to really challenge your assumptions unless they
have some meaningful motivation. So you may have to listen in a different way
than you're used to, or push people a bit to get them really comfortable with
telling you things they might think you don't want to hear.

------
rawoke083600
I guess its obvious now but when I demo'ed/try-to-sale my software projects I
would spend 15 min showing "the guy" all the features.. INSTEAD of listing and
teasing-out the ONE requirement/problem the guy had and THEN spending 15 min
showing him how the software will fix he's one big problem.

~~~
thrav
This is the art of the demo. If you don’t have 1-3 big problems that you’re
about to show the customer how you’ll solve, you’re just shouting into the
void.

If customers won’t tell me what problems they’re trying to solve, I adopt a
very monotonous cadence and tone and repeatedly say, “I can keep going through
standard features, but this would be a lot more useful for both of us if you
could tell me a bit more about your needs.”

------
edanm
I sometimes don't understand why technical people seem resistant to "lean
startup" methodologies. It's just the scientific method, applied to build a
product! You build hypotheses, then try to prove them, and in the course of
this, usually learn more information about the world. That simple.

You think you have a product which is useful to someone? Prove it! Talk to
people, ask them, build simple prototypes of the core parts.

You think you know how to sell your product? Prove it! Build out some sort of
pipeline, e.g. use a landing page and see if you can get people to it.

Etc.

There are good and bad ways to do this, obviously, and it's not _easy_. But
the basic idea is simple enough - and most of the arguments against it sound
pretty much the same as how it would sound for someone to be against
scientific experiments and hypothesis testing.

~~~
ericabiz
I can shed a bit of light into this as a Myers-Briggs INTJ (so common in
Silicon Valley it's called the "programmer type.")

I'd definitely rather be behind a computer than out talking to people,
especially people I don't know.

And I fear rejection--just being brutally honest. (Most people wouldn't admit
that this is a core reason they don't like sales.)

I've gotten a ton better since I've run retail stores for the last 3+ years,
and that's pushed me out of my comfort zone so frequently that I'm pretty
decent at small talk now. (INTJs tend to hate small talk, and sales can be a
lot of small talk!)

I doubt I'll ever get to the point where sales is fun for me like it would be
for some of the extrovert types. Still, sales is worth doing as a boundary-
pushing exercise and a getting-comfortable-with-rejection exercise.

------
koliber
I tried to correct some of these mistakes with my latest venture. In the past,
I would build something that I _thought_ was a pervasive problem with a
demand, only to learn later that I was wrong. Ideas are worth very little
until they are verified in the real world. You can get a lot done by just
talking with people.

This time, I've spent a lot of time asking people what they thought of the
idea, and hashing it out. I got a lot of positive feedback. People understood
the problem. I got a feeling that they "got" the solution. When I sat down to
build it, I had more confidence in it than prior projects.

There's still a lot more selling work ahead. The project is just starting to
garner interest. I feel so out of my element selling, but I realize it is just
another

P.S. The project is goodgrids.com. It's an API for converting CSVs to
beautifully formatted Excel spreadsheets, and extracting data from Excel
spreadsheets into CSVs for uploading into legacy systems.

~~~
klohto
I was working on something similar this weekend! (Well, kinda)

Basically, I had an ugly CSV from my bank and importing it into Excel yielded
horrible results. So I wrote a processor with customizable rules that splits
values into defined colums. In the end, I had all my payments for past 3 years
split into defined categories, added some stats, got rid of useless or empty
fields and nicely formatted it.

~~~
koliber
Excellent! Building tools to automate and solve your own problems is such a
satisfying endeavor. Unfortunately, the majority of people lack the skills you
have and remain frustrated.

------
duxup
I don't entirely disagree, but I've seen taking these concepts too far blow up
just as often as building without input (at least in my experience).

In those cases a company finally gets a customer, usually a big one(s)
(everyone sees mega dollar signs and maybe they get a taste of it), and then
that customer monopolizes the development demands to the point that the
product and development are laser focused on the whims of a company or handful
of companies, and not something that everyone else who isn't engaged in the
process will buy.

It gets worse when those companies don't REALLY know what they will actually
buy or keep long term, as they're used to effectively just picking from a list
of what is available. When given a chance to influence development they often
will make odd corner case choices that are legit annoyances with existing
products or their own problems.... but absolutely won't sell the product at
the end of the day or over keep them as a customer the long term. They won't
tell you what really works already because they only really recall problems
with past products.

It's a delicate balance. Getting user input is hugely important, but they're
not going to tell you the truth all the time, and they don't always know it.
Sales guys, also don't necessarily know what it is either.

I've been on both ends where I was all "OMFG engineering did you think about
how people use this!?!? Did you ask anyone??" and "This product is now only
useful to one company because all we do is take user input and make widgets
what the hell is going on???"

~~~
mygo
I'd say that if someone falls into that trap then they haven't really done the
market research in the spirit of this strategy.

The purpose of speaking to customers first before building is to find out how
much demand there is for the product and how much they're willing to pay for.

It's to find out that there is really only one company or a few that want
this... before possibly wasting your time building it.

If someone knowingly goes into building a product for a single customer, then
that had better been a conscious decision, knowing the ramifications of that.
Be aware of it and don't let it be something that just happens.

In any case, for engineers, speaking to customers before building is not the
default. So there's a strategy that they are going out of their way to adopt,
for a specific purpose. So they need to do it right, not half-assed, and
design the app for a large number of users with input from a good amount of
people, otherwise their single main customer who will have them by the balls.

The market researcher should go into it knowing that the user cannot always
list out exactly what they want. Everything the market researcher should do is
purposeful, to try to discover what that _thing that needs to exist_ really
is, how big the addressable market is, and for how much money the market will
bear. It's a whole strategy... And it's a better strategy than building
without working with real actionable data from a sample of the actual future
users.

------
tinyvm
While 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.

~~~
Fergi
(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 and
would pay for it.

Also, this post isn't saying that builders shouldn't begin with a strong,
fundamental conviction about how things should be dramatically different. I,
as the author, would actually argue the exact opposite. The point I'm making
is that once we have our convictions, we should test and measure the extent to
which those convictions are correct before investing large amounts of time,
money, and energy into productizing them.

Lastly, the point about asking questions and then listening to customer
feedback would only result in building minimally better products if the
product hypothesis we start with is itself unimaginative. But that hypothesis
can be literally anything. Customer feedback simply teaches us if market
demand lines up with our assumptions about market demand.

~~~
butterNaN
A "Hobby" project turning into a business is a rarity. It comes down to
expectations of returns.

If you want a business, a monetize-able product, you _have_ to think about
sales. The observation that majority of Software start-ups fail to avoid the
mistake #1 from this article is accurate. And majority of Software start-ups
start with an expectation of monitory returns.

If the expectation is a personal sense of fulfillment, anything other than a
business for that matter, then what you are creating becomes more of an art
than a product. There is a chance you might earn from it, but it is slim.

------
ptero
This is a very good post. I am in special agreement with #2 (on listening).

However, #1 for me is not quite right. Selling before building anything may
backfire as your prospects could see you as an airhead selling vaporware. "OK,
this tech looks useful, but so is anti-gravity. Show me that it is buildable
and that your team can build it quickly."

One way to allay such concerns is to have a quick prototype that (on a
logarithmic scale) is halfway to the product you are selling. This can say
"yes, we do not have a product for you today (because we did not focus on it
yet), but we _can_ build it quickly". Would this be something you are
interested in? My 2c.

~~~
fyfy18
> One way to allay such concerns is to have a quick prototype

Once you've discovered a need for a potential product, this is the most
important bit. You should spend as little time as possible trying to build the
MVP.

It's really important to stick to the 'minimum' and not over-engineer it. That
means if you have the choice of using ML that will take 6 months to build, or
you can build it in a month and then spend 12 hours a day juggling
spreadsheets, you should do the later.

Once you get to market, and (hopefully) have real customers paying you, you'll
discover much more valuable insights than you ever could just by talking to
prospects up front.

------
jillesvangurp
All true. However there are also a bunch of mistakes sales people make when
selling software:

Selling something that hasn't been built or planned yet. This leads to
disappointed customers and/or rushed delivery of half assed features. This is
easy for the sales persons to do and they tend to move on anyway before the
shit hits the fan. Aldo, it's technically not their problem when the shit hits
the fan.

Confusing what the customer says they want with what they actually need. This
leads to wasted development effort building something that doesn't ultimately
solve the customer's problem, that nobody else really wants. When sales people
take charge of requirements, always question the rationale.

Giving into a big customer's demands to land a deal and thus crippling the
company doing custom development for that one customer at a huge discount and
at the cost of shipping value to other paying customers. I would say this is
the #1 mistake in selling SAAS software. It's literally a company killer as
often the customer is unhappy anyway and then cancels the deal. I've seen
multiple startups get stranded doing all sorts of crap for a customer that
ultimately walks away.

Listening to a customer that has not committed to paying. Before they pay,
they are just haggling over details. They'll want everything you suggest and
then some. After they pay, they've committed to you and then you can be
reasonable about their demands. Especially in an early phase of a company
everybody is interested in becoming a customer if only you were to do X, Y,
And Z. You check back two weeks later they'll come up with more crap. It never
ends and they may never buy something.

My recommendation is to always build an MVP and try to sell the MVP. If you
can't sell the MVP, it's not viable. If it takes a long time to build it, it
is not minimal. If you have no MVP you have nothing to sell. An MVP is not a
click demo, it needs to be a functioning thing that delivers value to paying
customers. Building it should be proportional to the amount of risk you are
willing to take financially and the amount of money you are going to make if
successful.

Of course definitely talk to potential customers as early as you can but don't
promise anything you can't deliver.

After the MVP stage work with roadmaps and prioritize according to what is
needed, feasible, and valuable. Most stuff customers want fails at least one
of these tests. Most sales people are poor judges of feasibility or necessity.

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

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

~~~
mlthoughts2018
> “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!

~~~
yread
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.

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

~~~
slededit
Go back and re-read the title, it's literally advice for Software Engineers.

~~~
mlthoughts2018
Why do you think my comments did not already account for that? The article
claims that software engineers make the mistake of building before they sell,
and advises an aggressive form of selling before building instead.

But that advice directly means to skip engineering due diligence (which very
often requires building before you sell). It doesn’t matter if the person
implementing the advice would be an engineer or a sales person or anyone else.

Your comment comes off as if it is supposed to glibly (and I think also
rudely) undermine what I wrote, but in fact I think you didn’t understand what
I wrote, and you seem to suggest that it would be impossible for an engineer
(using the article’s advice) to fail to consult an engineering estimate of
technical feasibility prior to selling something.

~~~
tomhoward
Having a high degree of confidence that you are capable of building what you
are selling is a given.

Nobody reading this is building anything resembling a perpetual motion
machine. Pretty much everyone in this post’s intended audience is building
some combination of a database and a bunch of web forms and tables to
undertake a routine business process.

Your comment is plain old reductio ad absurdum. It’s not clever.

Writers are entitled to favor conciseness over having to pre-empt any
fallacious dismissal they’ll get from whichever random person on the internet
needs to entertain themselves that day.

~~~
mlthoughts2018
> “Having a high degree of confidence that you are capable of building what
> you are selling is a given.”

No, it is emphatically not a given. Not in the context of some new CRUD tool.
Not in the context of latest & greatest self-driving cars. Absolutely not.

> “Pretty much everyone in this post’s intended audience is building some
> combination of a database and a bunch of web forms and tables to undertake a
> routine business process.”

You’re just simply extremely wrong about this. Even internally to a large
company you often have projects spun up for face detection, natural language
processing, complex workflow management tools, adtech tools, embedded systems,
robotics, medical devices, systems dealing with personally identifying
information, and on and on.

Expand to include start-ups and the breadth and scope of products being
developed grows dramatically.

All the time, across all of these situations, you face engineers, product
managers, sales people, and many others, who over-promise on product offerings
during initial stage sales piloting. It happens all. the. time. And one of the
most serious drivers of this huge and risky oversight is a lack of investment
in building parts of the product in advance of attempting to sell it, in order
to acquire knowledge that you did not already have regarding the cost and
blockers of the engineering implementation.

That you dismiss this as implausible by saying “confidence that you are
capable of building what you are selling is given” is nothing other than an
indication you do not know what you’re talking about in this topic. I feel
frustrated to receive such a rude comment that is self-evidently more focused
on trying to undercut me, even mentioning wildly non sequitur things about
concise writing as if it applied to the original article, than focused on the
actual discussion of the thread.

~~~
slededit
Sure at a big company. But this advice is targeted to engineers who want to
start their own company. Its unlikely they can even afford any of the layers
of cruft you are talking about.

If this was advice for starting some new initiative at BigCorp I might agree
with you.

~~~
mlthoughts2018
The need to build before selling is more critical for start-ups or single
person gigs or consulting, because in those situations you don’t have existing
stable revenue streams to use to absorb financial or reputational losses that
come from underestimating implementation time or cost and failing to deliver
sales promises.

If it matters to build before selling in a mature company, it matters even
more in a start-up / solo business / consulting feasibility discussion / etc.

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

~~~
soneca
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).

------
iforgotpassword
> The responses that customers give to thoughtful, open-ended questions inform
> how customers think about their problems, needs, budgets, timeline, decision
> making process, fears, alternative options to your product, and the extent
> to which they perceive that your product solves their problem.

What I'd like to add here, since the article only indirectly says so, is that
you shouldn't take any idea or request you get literally and start
implementing it. Try to figure out what the underlying problem of the customer
is, since often times they already have half a solution in their mind and just
tell you what they need to make it work, when there might actually be a
completely different approach to their problem that they didn't think of. I
think that's the hard part of talking to customers.

And obviously, if your product does seem to be a good fit for the customer,
but requires some rethinking of how to organize things or change workflows,
finally selling the product is still hard, because they won't immediately see
the benefit. In those cases, word of mouth really is your best friend, which
somewhat requires you're selling in a sector where potential customers are
strongly networked, so anything in the public sector is a good example here.

> Many engineers I've talked to report experiencing social anxiety and a sense
> of discomfort during sales conversations.

Something I can relate to. I really learned a lot in this field over the
years, but I still leave selling to sales people. I'm often times joining our
sales rep when he's visiting new or potential customers because of what I can
learn, and just in case the customer has some specific technical questions.
But when there's questions about feature requests or anything they dislike I'm
easily tempted to always give honest answers like "uh I don't think this can
easily be changed, I'd have to think about how I'd approach this", which,
while honesty in general is a good thing, just doesn't work well in a sales
conversation, like you have no clue about what you're doing. So I know when to
shut up and let the sales guy fill in for me.

As of #3, we approach this by giving every customer a free trial of 6 month
and then a 50% discount for the next 6 month. Since our product falls into the
category of requiring some rethinking and restructuring, this has proven to be
an excellent strategy, since we are often met with equal amounts of interest
and hesitation.

------
mrtksn
Are there examples of great companies that actually started selling before
building the product?

From Google to Facebook, all the companies that I've ever researched seems to
be based on people fiddling with ideas and then quickly iterate to the
direction when they start getting traction.

Sure, there are crowdfunding sites or established companies selling based on
CGI drawings or concept videos but this seems to be not the rule but the
exception for the products that I use. What seems to be the rule is that
people have some ideas, they build MVPs and fast-iterate or pivot based on the
reception.

For the b2c, at least... Anyway, the article is probably talking about b2b
where it can be O.K. to start with some slides of value propositions and build
the thing later because of the selling process taking moths and the
implementation, potentially years.

edit: hmm, maybe I am taking the "selling" a bit too literally.

~~~
0xferruccio
Google and Facebook are moonshots by extremely talented people. I don’t know
about you, but I have no close to zero chances of building something similar.

It’s wiser to be realistic, find problems businesses have, understand them
better than anyone else and try to solve them.

EG. some dropshipping platforms don’t have integrations with some e-commerce
platforms, interview dropshippers and build the ones they’d need. It might not
be fancy, but it works. I respect this more than people that try and change
the world with a new decentralised web 3.0 no one will ever use

EDIT: you added a reference that your thoughts are for B2C. But Facebook and
Google are B2B, the Cs are the product

~~~
mrtksn
So, are there any examples of something that started with the selling first
building later?

Sure, for a small operation that is not particularly innovative you can do
that. You can first sell someone a house and later build it but I am not aware
of a product that made it big by consulting the potential users without having
a product(MVP or even a POC) in hand. Usually, it seems, people start with a
product that they have some kind of awareness of its purpose and value,
measure the reactions and iterate it thereafter.

I mean, if selling first and building later is the right way to do a start-up,
there must be people who actually succeeded with their start-ups by selling
first and building later but I'm yet to hear about one.

~~~
0xferruccio
Oracle to the CIA.

Also I don’t think there is a right way of doing a startup, there’s no guide
you can follow or rules. What I’m saying is that addressing real problems and
talking with people that have the authority and budget to address them before
building something seems like a good way to minimize risk for b2b ventures.

~~~
mrtksn
>Oracle to the CIA.

I was unable to confirm it.

Anyway the advice of sell first build later and talk to customers sound very
smart, it's just that it I don't see much of success stories based on that
process.

On the other hand, build something basic, put it in front of the people,
measure and iterate based on the measurements have so many examples. Like
pretty much everything out there.

So yes, the stuff on the article sound smart but is it?

~~~
0xferruccio
Tuft and Needle started selling with a fake landing page to validate their
idea.

Once they got their first sale for a mattress they started working on the
company. (source: their indiehackers interview)

Hotjar started a super successful referral campaign before having a working
product.

Pietr Levels validated features with a fake credit card form to see if people
would pay for some membership.

And there are countless other examples. Building a landing page that explains
the product or a proof of concept isn’t building the product, if something can
help you give the idea of what you have in mind build it.

~~~
mrtksn
Cool, thank you!

I think I took the "selling" word a bit too literally.

~~~
0xferruccio
Happy this conversation helped you :)

I find this topic to be really sensitive to me as I find that the first impact
with the customer is always a big reality check for every idea I have.

I often find myself building what “I think” people/companies want, but I think
it’s healthy to try and build what they’re already willing to pay for!

~~~
mrtksn
Oh, it happens to me too. As techies maybe we think in the context of
"Wouldn't be cool if..." and just really want to believe that it's not just
cool but actually people will use it and pay for it and ignore the signs of
the opposite as long as we can because it's really cool and sure people will
come around and see how cool it is if I can make it shinier.

------
commonsense1234
the fourth mistake is visiting your site. why do you need 40+ cookies to track
visitors?

~~~
ivanche
Furthermore, on Firefox 55 and uBlock Origin only the first 2 paragraphs are
shown. Luckily outline.com works once again:
[https://www.outline.com/eACAzB](https://www.outline.com/eACAzB)

~~~
gorhill
Tip: Site rendered fine with master JavaScript switch disabled.

------
ScottBurson
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](https://en.wikipedia.org/wiki/VPL_Research)

------
ivanhoe
In my opinion these advices apply mostly to B2B and enterprise segment, where
you sell to much smaller group of people and it's easier to articulate their
needs and demands ahead, and where each individual sale is a significant
achievement.

------
bsvalley
Great pieces of advice but it’s like asking a sales person to learn how to
code. My best advice and where I believe engineers should spend 100% of there
energy up front, is to go out there and find a cofounder who’s primary skill
is to sell stuff. Product or marketing folks.

Both strategies (yours and mine) are very tough and time consuming, so I’d
definitely pick mine. Why? Because it would be so much more optimized in the
long run. That’s how most of the tech companies started and there’s a good
reason for that.

~~~
chasd00
Yes! Find a salesperson for the reasons above. I'll add this, in all startups
I've been in the actual code or engineering made up 20% of the company at
most. Sales, marketing, operations, finance, you better be just as good in
those areas as you are in your favorite pet language.

------
ilaksh
See a book called "The Mom Test".

~~~
hassanjahan
It's a great book. I recommend it to all tech guys.

------
CM30
There's also a fourth related mistake they make too:

Focusing on building instead of selling.

It's not just that you need to start selling your product before you make it
to gauge demand, you also need to continue to sell your product and market it
after it goes up too.

But that's not fun for many software engineers. It's not enjoyable setting up
ads and deals with influencers and meeting with clients and working on SEO and
what not. It's fun to sit in front of a computer writing code.

So we get a bunch of technically fancy projects with nice looking GitHub
profiles and Hacker News showcase posts, all of which barely anyone actually
uses. It doesn't help that for a certain percentage of developers (read, many
people here), they seem to think selling or marketing something is inherently
immoral in some way or another.

------
0xferruccio
I 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/](https://ferrucc.io/posts/sales-for-cybersecurity-saas/)

~~~
lbriner
I think a similar issue is rushing to fix something in an industry you have no
experience of. You might not think you need to know about property before you
start an AirBnB but actually they had to learn from mistakes and wrong
assumptions, fortunately they were agile enough to pivot.

Engineers often assume that everything is as simple as "my product can do
that, please pay me money" when there are a raft of other blockers in certain
industries, some already mentioned above. The more you understand these before
you start, the less time you spend trying to understand e.g. why a hospital
won't just buy some random new product even though it promises to fix a big
problem.

~~~
0xferruccio
Asking questions and trying to sell something is an amazing learning
experience.

Especially if you don’t have experience in an industry the best thing you can
do to learn is to try and sell something or schedule calls with people in the
industry.

------
eismcc
Good article. I will go out on a limb with a couple self-observed behaviors:

I'd venture to guess that a good litmus test for knowing if someone is ready
to start a business is measuring their ability to deal with conflict.

When engineers aren't good at dealing with conflict, they are likely heading
towards escapism when they start a project:

1) Engineers sometimes don't necessarily want customers, they want
intellectual freedom. Having customers is scary, and if your subconscious goal
is escapism, having customers is even scarier. 2) Listening to people may lead
you down the road of doing something you don't want to do. See #1. This may
mean not having the freedom to do what you think you want to do. Which likely
is not making money.

------
wslh
The points are good but I think the problem with engineers trying to sell is
deeper: engineers are focused in the truth while salesmen use a grayscale.
Sometimes they go to the darker side and even black. The point of selling is
selling! The startup community escapes this talk because it is politically
incorrect but you can see the behavior in many successful companies. For
example, thinkabout Microsoft negotiating/selling to IBM

------
devit
It's because sales, and in general any social activity, has inherently
unpredictable and random results, while engineering is mostly deterministic.

Also, much easier to sell something that exists since obviously customers
don't gain much by and thus don't care much about signalling whether they
would buy something that they might be able to buy in the future, as opposed
to just buying something they want and can get immediately.

------
bitxbit
How 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.

------
goshx
I find that this applies to non software engineers as well. When people are in
love with their own idea sometimes it is difficult for them to listen and to
learn if people really want that.

------
pjmlp
Fully agree, matches quite a lot with what I see around me.

------
vimarshk
The three points are spot on! I have done a couple of these in my career.
Great summary!

------
sharemywin
That's because most people determine that if your doing something where your
getting told that's "the dumbest thing I've ever heard" 9 out of 10 times it
times to find something else to do.

------
sova
Asking is better than listening is better than talking

------
browsercoin
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?

~~~
JamesBarney
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.

------
throwaway487548
Surprisingly 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, there is
absolutely no demand for this kind of arrangements, because there is almost no
demand for remote work in the first place.

~~~
kornishon
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.

~~~
throwaway487548
These are basically village home-stays with 3G/4G internet, and when people
realize this they abandon the prospect. ;)

Also there are some visa restrictions - in some places you could stay up to 60
days, Indian visa is usually just 3 months.

Nevertheless, remote Indian and Nepalese hilly areas are absolutely wonderful.

------
malcolmgreaves
Selling something before you make it is highly unethical. You have no idea if
you can actually make it, so you run the risk of committing fraud.
Additionally, such a strategy could only work if what you're making is very
simple. If it's complex, is your customer really going to be okay with "please
sign here and we'll get it to you in the next year."

Have a dream. Turn it into a vision. Make a business plan. Create an MVP. Then
go try to sell it and listen to the feedback.

I'd you're wrong, then suck it up and deal with the consequences of failure.
Failure is never fatal; it's the courage to continue that counts.

~~~
kayza
The point is to first validate your idea by asking people if they're actually
willing to pay for your service, hypothetically. I don't think the author
means actually setting up a contract where the potential interested parties
actually pay you upfront for a service that doesn't exist.

~~~
intrasight
There is no greater indicator of interest than having a customer willing to
pay up front. I have been on both sides of such deals in my career.

