41 ms·

Sales mistakes that software engineers make

777 points by Fergi 8y ago

option_greek 8y ago
>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.
- sdrothrock 8y ago
  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).
- slow_donkey 8y ago
  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.
- Fergi 8y ago
  (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 8y ago
    > “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 8y ago
      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 8y ago
        How do you know they are solvable if you pick what problems to solve before consulting engineers about feasibility or cost?
        slededit 8y ago
- stingraycharles 8y ago
  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.
  - Fergi 8y ago
    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.
- trevyn 8y ago
  The fantasy product in their mind is often a more compelling product than the actual product. See: Kickstarter.
- avinium 8y ago
  I want to hear from people who have actually done this. I suspect they all have well-known track records and are selling to people who trust them to deliver. I still haven’t met anyone personally (myself included) who managed to presell software with nothing but a presentation. I think the more common route is “find the first customer and build v1 for them as a consultant at a steep discount”.
- softwarefounder 8y ago
  Your 100% right. Especially in mid to large B2B plays.
- pjmlp 8y ago
  Most of the time that MVP can be done with some kind of wireframe tooling. Customers just want to have a better picture how it is supposed to work, instead of looking at powerpoints.
tinyvm 8y ago
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.
- ainar-g 8y ago
  >"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.
  - SimplyUnknown 8y ago
    There's nothing wrong with it. As you say, many quality products come from this kind of work. However, you can read this article as saying: "The only way you can sell software is by listening to customers and building exactly what they want." Which often is "We are using [Insert Tech Name] and it doesn't support feature X." This narrative is clearly false. Many good products are built and monetized by just building something what you think the world needs or you think is fun to build. Again, many more of these software projects have failed using this strategy. Many good products are built and monetized by listening to customers and building what they want. And again, many poor clones that add no value are built using this way. It is a two-way street which is not reflected in the article.
commonsense1234 8y ago
the fourth mistake is visiting your site. why do you need 40+ cookies to track visitors?
- throwaway487548 8y ago
  Block third-party cookies. Keep local data only until you quit your browser.
- ivanche 8y ago
  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 8y ago
    Tip: Site rendered fine with master JavaScript switch disabled.
koliber 8y ago
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 8y ago
  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 8y ago
    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.
ilaksh 8y ago
See a book called "The Mom Test".
- hassanjahan 8y ago
  It's a great book. I recommend it to all tech guys.
pjmlp 8y ago
Fully agree, matches quite a lot with what I see around me.
bambax 8y ago
> 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.
- lozzo 8y ago
  Very lucid comment. I would just object to your harsh "it's irrational and probably stupid..." final remark. It's not irrational and stupid. Building something allows you to sharpen your skills, validate your abilities, engage you to the problem you want to solve for real. cheers
  - jononor 8y ago
    Sometimes one pretends to build the thing for someone else, when its first and foremost for oneself. That can be a bit irrational but also often unnecessary - there is nothing wrong with making something for oneself.
- almostarockstar 8y ago
  I have also been here too many times to count. My take on it is that it's not a failure as long as you've learned something. In my case, for the first number of projects I built that nobody bought/wanted, I didn't learn to find the market first (sadly), but I did learn a huge amount about how to build things. Now I can build better things faster - but I'm actively learning to find the market.
  - Aaargh20318 8y ago
    I've been on the other side of this too often too. Sales selling things that don't exist yet, promising conflicting or impossible features and of course a ridiculous deadline. If you're doing bespoke work, sure you wait for a customer to define what they need. But if you're working on a product, then what a single customer wants is not very relevant. You build something that you think the market wants (based on market research, gut feeling, whatever) and then try selling it. Doing it the other way around is the definition of vaporware.
throwaway487548 8y ago
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 8y ago
  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 8y ago
    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.
deleted 8y ago
[deleted]
mlthoughts2018 8y ago
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 8y ago
  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.
bitxbit 8y ago
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.
0xferruccio 8y ago
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 8y ago
  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 8y ago
    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.
malcolmgreaves 8y ago
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 8y ago
  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 8y ago
    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.
- intrasight 8y ago
  > 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. Wrong and wrong It is VERY common across all industries to have customers pre-pay. In fact, I wouldn't take a potential customer's "interest" in meaning anything if they don't put their money where there mouth is.
mrtksn 8y ago
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 8y ago
  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 8y ago
    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.
bsvalley 8y ago
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 8y ago
  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.
fuball63 8y ago
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 8y ago
  >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.
  - adamc 8y ago
    Yeah, this.
  - auspex 8y ago
    It works if you are selling something of actual value and mail the right person.
    - goatherders 8y ago
ivanhoe 8y ago
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.
goshx 8y ago
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.
ptero 8y ago
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 8y ago
  > 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.
- cosinetau 8y ago
  Right, but, you'll tell a new customer you will have the product ready for them quickly, but because you didn't have a stakeholder that would, you're running the risk trying to sell them a product that wouldn't solve their particular problem (feature mismatch). Maybe if you believe the limits of technology would be a blocker to solving your customer's vision of their problem, then a prototype before you have a stakeholder that would compensate you somehow is probably the right answer. But I think you can easily confuse the business objectives with engineering objectives in making the assumption that the prototypical solution is representative of the customer's vision of the solution. It's not that I think you or a business can't live with that dissonance, I think it may open you up to that problem.
rawoke083600 8y ago
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.
- djrogers 8y ago
  I’m in sales, and sometimes I get so excited about a particular technology that I forget this rule too. Can’t imagine how hard it would be for someone who actually built the dang thing!
- thrav 8y ago
  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.”
iforgotpassword 8y ago
> 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.
sharemywin 8y ago
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.
duxup 8y ago
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 8y ago
  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.
jillesvangurp 8y ago
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.
wslh 8y ago
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
edanm 8y ago
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 8y ago
  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.
- zipwitch 8y ago
  Sometimes it's not about wanting to make money, about wanting to sell, or even about wanting to be useful. It's about having an idea and wanting to make it work. And if fame or fortune come your way as a result, great. But the real motivation is building it and seeing it work. (And maybe watching people go, "Wow! That's so awesome/amazing/elegant/etc!" But as long as you get to build it and it works, that's what's really important.)
loarake 8y ago
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 8y ago
  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.
ScottBurson 8y ago
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
browsercoin 8y ago
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 8y ago
  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.
kowdermeister 8y ago
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 8y ago
  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).
vimarshk 8y ago
The three points are spot on! I have done a couple of these in my career. Great summary!
devit 8y ago
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.
sova 8y ago
Asking is better than listening is better than talking
eismcc 8y ago
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.
CM30 8y ago
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.

777 points by Fergi 8y ago

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

sdrothrock 8y ago
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).
slow_donkey 8y ago
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.
Fergi 8y ago
(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 8y ago
  > “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 8y ago
    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 8y ago
      How do you know they are solvable if you pick what problems to solve before consulting engineers about feasibility or cost?
      - slededit 8y ago
stingraycharles 8y ago
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.
- Fergi 8y ago
  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.
trevyn 8y ago
The fantasy product in their mind is often a more compelling product than the actual product. See: Kickstarter.
avinium 8y ago
I want to hear from people who have actually done this. I suspect they all have well-known track records and are selling to people who trust them to deliver. I still haven’t met anyone personally (myself included) who managed to presell software with nothing but a presentation. I think the more common route is “find the first customer and build v1 for them as a consultant at a steep discount”.
softwarefounder 8y ago
Your 100% right. Especially in mid to large B2B plays.
pjmlp 8y ago
Most of the time that MVP can be done with some kind of wireframe tooling. Customers just want to have a better picture how it is supposed to work, instead of looking at powerpoints.

tinyvm 8y ago

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.

ainar-g 8y ago
>"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.
- SimplyUnknown 8y ago
  There's nothing wrong with it. As you say, many quality products come from this kind of work. However, you can read this article as saying: "The only way you can sell software is by listening to customers and building exactly what they want." Which often is "We are using [Insert Tech Name] and it doesn't support feature X." This narrative is clearly false. Many good products are built and monetized by just building something what you think the world needs or you think is fun to build. Again, many more of these software projects have failed using this strategy. Many good products are built and monetized by listening to customers and building what they want. And again, many poor clones that add no value are built using this way. It is a two-way street which is not reflected in the article.

commonsense1234 8y ago

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

throwaway487548 8y ago
Block third-party cookies. Keep local data only until you quit your browser.
ivanche 8y ago
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 8y ago
  Tip: Site rendered fine with master JavaScript switch disabled.

koliber 8y ago

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 8y ago
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 8y ago
  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.

ilaksh 8y ago

See a book called "The Mom Test".

hassanjahan 8y ago
It's a great book. I recommend it to all tech guys.

pjmlp 8y ago

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

bambax 8y ago

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

lozzo 8y ago
Very lucid comment. I would just object to your harsh "it's irrational and probably stupid..." final remark. It's not irrational and stupid. Building something allows you to sharpen your skills, validate your abilities, engage you to the problem you want to solve for real. cheers
- jononor 8y ago
  Sometimes one pretends to build the thing for someone else, when its first and foremost for oneself. That can be a bit irrational but also often unnecessary - there is nothing wrong with making something for oneself.
almostarockstar 8y ago
I have also been here too many times to count. My take on it is that it's not a failure as long as you've learned something. In my case, for the first number of projects I built that nobody bought/wanted, I didn't learn to find the market first (sadly), but I did learn a huge amount about how to build things. Now I can build better things faster - but I'm actively learning to find the market.
- Aaargh20318 8y ago
  I've been on the other side of this too often too. Sales selling things that don't exist yet, promising conflicting or impossible features and of course a ridiculous deadline. If you're doing bespoke work, sure you wait for a customer to define what they need. But if you're working on a product, then what a single customer wants is not very relevant. You build something that you think the market wants (based on market research, gut feeling, whatever) and then try selling it. Doing it the other way around is the definition of vaporware.

throwaway487548 8y ago

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 8y ago
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 8y ago
  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.

deleted 8y ago

[deleted]

mlthoughts2018 8y ago

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 8y ago
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.

bitxbit 8y ago

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.

0xferruccio 8y ago

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 8y ago
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 8y ago
  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.

malcolmgreaves 8y ago

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 8y ago
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 8y ago
  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.
intrasight 8y ago
> 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. Wrong and wrong It is VERY common across all industries to have customers pre-pay. In fact, I wouldn't take a potential customer's "interest" in meaning anything if they don't put their money where there mouth is.

mrtksn 8y ago

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 8y ago
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 8y ago
  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.

bsvalley 8y ago

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 8y ago
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.

fuball63 8y ago

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 8y ago
>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.
- adamc 8y ago
  Yeah, this.
- auspex 8y ago
  It works if you are selling something of actual value and mail the right person.
  - goatherders 8y ago

ivanhoe 8y ago

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.

goshx 8y ago

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.

ptero 8y ago

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 8y ago
> 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.
cosinetau 8y ago
Right, but, you'll tell a new customer you will have the product ready for them quickly, but because you didn't have a stakeholder that would, you're running the risk trying to sell them a product that wouldn't solve their particular problem (feature mismatch). Maybe if you believe the limits of technology would be a blocker to solving your customer's vision of their problem, then a prototype before you have a stakeholder that would compensate you somehow is probably the right answer. But I think you can easily confuse the business objectives with engineering objectives in making the assumption that the prototypical solution is representative of the customer's vision of the solution. It's not that I think you or a business can't live with that dissonance, I think it may open you up to that problem.

rawoke083600 8y ago

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.

djrogers 8y ago
I’m in sales, and sometimes I get so excited about a particular technology that I forget this rule too. Can’t imagine how hard it would be for someone who actually built the dang thing!
thrav 8y ago
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.”

iforgotpassword 8y ago

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

sharemywin 8y ago

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.

duxup 8y ago

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 8y ago
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.

jillesvangurp 8y ago

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.

wslh 8y ago

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

edanm 8y ago

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 8y ago
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.
zipwitch 8y ago
Sometimes it's not about wanting to make money, about wanting to sell, or even about wanting to be useful. It's about having an idea and wanting to make it work. And if fame or fortune come your way as a result, great. But the real motivation is building it and seeing it work. (And maybe watching people go, "Wow! That's so awesome/amazing/elegant/etc!" But as long as you get to build it and it works, that's what's really important.)

loarake 8y ago

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 8y ago
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.

ScottBurson 8y ago

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

browsercoin 8y ago

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 8y ago
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.

kowdermeister 8y ago

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 8y ago
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).

vimarshk 8y ago

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

devit 8y ago

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.

sova 8y ago

Asking is better than listening is better than talking

eismcc 8y ago

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.

CM30 8y ago

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.