> 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.
Thanks for this comment. I think you articulated the thought process that this post aims to speak to beautifully. Builders do want to build, and finding an audience first and doing the type of tedious customer development work described in this post IS an impediment to building, which is precisely the point I wanted to make.
Assuming that the goal of building a product is to ultimately generate revenue, having a temporary impediment between conceptualizing a product idea and building the product is a good thing. This impediment allows for the builder to pause and objectively scrutinize his own idea, using feedback from potential customers as data about the extent to which the product hypothesis is correct.
You're right that stagnation is the worst outcome. And the inverse of stagnation is momentum, which will exist to the extent that people want what we're making for them, something that can be determined in advance of building simply by talking to potential users and customers.
I'll also add here that the process mentioned in this post in no way inhibits the type of creative and inspired thinking that developers use to envision game-changing products. It's quite the opposite - rigorous and merciless scrutiny of our own ideas is the distillation process that allows us to refine our ideas into their essence, then confidently build things with conviction, and be right.
So to summarize (for my own understanding)... It's fine to want to build something first. However, if you want it to be financially profitable in a big scope of impact, you have a higher chance by plotting it out and then executing, than accidentally stumbling upon a perfect business model for your completed product.
Yes, that is my opinion. And if it's possible to build something minimal that helps demo or describe the product to users, it's totally reasonable to build that thing quickly and take it to customers for feedback.
The pitfall to avoid is investing large amounts of time, energy, and money building products in a vacuum based on assumptions about what people want and will pay for. I've heard this referred to as committing "assume-icide."
> you have a higher chance by plotting it out and then executing, than accidentally stumbling upon a perfect business model for your completed product.
You have a higher chance of stumbling upon a perfect business model by speaking to the customers before / during product design.
>> The reason why we don't ask first is, we want to build something.
Correlation isn't causation. Please don't be too upfront about "why we don't ask first".
Have you often encountered a situation where your non-tech boss didn't listen enough and you were right in the end? Or the cases when he even forgets a month later you were right in the first place? Or the times when you decided not to listen to your management and do it your way and they never realised it was you who was responsible for fixing it at all?
It's not just "being afraid of not finding what people want". It's also the psychology "maybe they don't understand it yet, so I should spend a bit more time on it". The sunk costs and the vision is what drives it.
It's amazing how easily people try to reduce behaviours of people to some singular emotion.
This is all very true and relevant, yet still its also true that we see lots of stories from founders regretting that they never established market fit before sinking years into development. This is probably the pattern for 90% of indie game developers, but it crops up in other contexts as well. Once they finally know they are at the end of that road to nowhere, they do have regrets, and they have had other ideas in the meantime that they did not pursue because they were dedicated to the current project.
All this aside, I have a side-project, and I'm not looking for any validation of it, just classic "build it and they will come" type thinking.
Is it possible to do indie game dev without building something and throwing it out there?
Small games seem like a market where it's nearly impossible to know what's going to sell ahead of time, because buyers don't know what they want until they see it. Or until a lot of people are telling them it's the Next New Thing.
It's relatively easy to research a market where you're offering a practical solution to a real problem. But entertainment markets - including direct sales of games, music, art, "influencers", and so on - are as much about trend, fashion, and some element of randomness, as about the core features of the product.
Big Game Devs and Entertainment Companies know this, which is why they repeat the same hits over and over, and spend a fortune on direct advertising and influence.
They still get it wrong sometimes, but slightly less often than solo devs.
Nope, but a box of Jenga and some small stuffed toys would suffice ;)
(And actually, my brother and I played a paper version of Worms when we were kids - with the map drawn in pen, and our movements and attacks plotted in pencil - was fun)
Adding to that, there is an entertainment component to almost everything these days. People like Turbo Tax because it makes it easier, and a little bit closer to fun, to do your taxes.
I know what you mean. One of my previous projects was a homeschool tracking SaaS. Even at $5/month people were complaining about the price and I never got more than a dozen subscribers.
In the end I shut it down (while keeping an instance running on a home server for my own use) because it was barely breaking even and wasn't worth the headache.
I was going to post the same thing. I guess we all have unique problems. Then there's the opposite, that everyone else have a problem, that you do not have, and thus you can not see the value of your solution. People have to literally throw money at you for you to understand they are actually willing to pay for something so simple as a hadron collider.
And of course there is the old: "If I had asked people what they wanted, they would have said faster horses." (and there is apparently no evidence that Henry Ford actually uttered those words)
While talking to, and most of all listening to customers is important, it too easily leads to building things that people know they want/need. Something truly "revolutionary" is unlikely with that method. Of course, something truly revolutionary is highly unlikely, period. So if your primary motivation is business success, you probably want to stay away from going for "revolutionary". On the other hand, it's not a given that business success has to be motivator or primary goal.
When talking with customers, focus on the problem, not the solution. The problem: going from here to there takes too long. There are many solutions to that problem. Faster horses are one of them. Cars another. Telephone, flying cars yet another. Not going is also a solution. Etc.
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.
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.
On the contrary, doing it the other way ensures that when you’re done someone is willing to buy what you built. It’s not about what one customer wants defining what you build, but rather having commitment from a handful of customers that they would buy what you propose to build. There’s a huge gap between securing a commitment to buy a future product and announcing vaporware you have no intention or ability to ship.
Well how is my audience supposed to know what I have to offer until they have it in front of them? Before that it's just me telling them an idea. Even after it's done I would not expect users to start using it on their own. Then you have to play a whole different game of getting people to use it.
A few years ago I wanted to make a niche marketplace to sell/trade tabletop miniatures. Instead of actually building the thing, I made a few mockup interfaces pages, and then just made a responsive HTML page. None of the buttons actually worked. I then put a modal that said "launching soon, sign up now for news and a special bonus on launch".
I spent $100 on ads on reddit and targeted forums with the goal to get 100 emails. If I got 100 emails, I would actually try and build the thing.
I got ~57.
You can market very far without anything that works. This is the "growth hack/MVP" mindset. I saved myself weeks of programming which would have been fun, but arguably a waste to building that specific business.
I knew it was a small niche market, and I set it as really a "reasonable" goal.
"If 100 people in 30 days are interested with this ad spend, then I'll reach out engage them and build the thing."
Depending on your app/market, you can change that number accordingly, but I think 100 is just a great "feel good" number thats hard enough to hit as evidenced by my test.
> how is my audience supposed to know what I have to offer until they have it in front of them?
This is, in an essence, sales. One need not be dishonest. Talking about upcoming products is fine. Collecting early sign-ups and for manufactured products, taking deposits, is ethical.
There's a weird/elusive balance you need to strike.
On the one hand, people like ideas, because it's easy enough to make something sound promising. "I like dogs, and Uber for dogs sounds awesome!".
It's not until your hand is out and you're asking them to actually shell out for something here and now that you'll know their true purchasing behavior.
On the other hand, if you're really trying to push the envelope, they won't understand what you're selling until they see it. Imagine trying to sell the idea of a car to a buggy driver - they'll probably shut you down with "that will never work".
You have to straddle these two obstacles by getting to the "hand out asking for money" stage as quickly as possible, while highlighting that core novelty/innovation that makes you unique.
I agree with you that we tend to shy away from these "first encounter" moments because we're afraid to find out we sunk months (or even years) building something that nobody wants (or that they're not willing to pay enough for to sustain a business). It's easier to think that "just one more" UI/website/feature will be enough to make it "perfect".
Now, I'm a firm believer that the early product development stage is not about building a product, but rather uncovering information - who your customer is, how to reach them, and what they're willing to spend money on.
Most important is the discipline to maintain a rapid prototype/customer feedback/iteration loop.
> we tend to shy away from these "first encounter" moments because we're afraid to find out we sunk months (or even years) building something that nobody wants
I believe this is the key line in bambax' comment:
> The worst outcome is not to build something nobody wants -- it's not to build anything.
As a 'builder' I completely agree with that. I don't want to start an 'Uber for dogs' business, but I do want to make a woof recognition system.
It's not irrational. People often don't know what they want, or think they know but often devise overly elaborate solutions. Also, building before asking means you can potentially create a new market with a new product that's never been seen before, which is far more lucrative.
Also, people are more able to communicate their wants and needs as deltas rather than absolutes. Creating something as a starting point is a great way to seed the conversation and get people thinking, even if that something doesn't end up getting used in the resulting product in any way.
I agree. Its most often the case that we arrive at problem to solve based on our own experiences/or troubles. A builders passion is fueled by his own problem and he can think of selling it if he see that the problem is present in life of others as well. Most successful products starts like this.
Trying to hunt for problem that others are facing won't is not at all motivating for a hacker mentality. And even if he is able to discover challenges of others he probably won't be able to execute the solution for it as neatly as he cad do for challenges of his own life.
Maybe we can tweak the advice to the following: if you need to build, build a little and get it validated by a potential customer before building more.
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
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.
Couldn't have said it better. I am another one of those people here with the same experience.
Ironically, building because of being afraid that nothing will be built often leads to exactly that outcome: months or years spent on something that nobody ever uses. Now it's built, but it doesn't matter, which is essentially the same as if it had never been built. In my experience, this really often is a self-fulfilling prophecy. And it has a tendency to become a vicious circle when the fear becomes self-reinforcing.
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.
> I fall into the "Build before talking to customers" trap constantly. Even though I know it's "wrong", it is hard to escape it because of the simple problem of not knowing who to talk to.
Then you have a different problem - you don't have a way to reach target customers.
Even if you build your product, how are you going to build a sales pipeline? Your customers won't hear about your product by themselves - you have to get it to them. Many many companies make products that are good, are actually useful, but they don't know how to build the marketing/sales pipeline that will actually make their products profitable.
And just like validating the product to build - building/validating a sales strategy is usually something you should do before building the product, both because it's harder, and because findings there may change what product you end up building.
Yes, and this is the part I can't seem to figure out. I think it's more of a personality/networking issue.
Right now I have an MVP of a function as a service platform; a general purpose development tool. I'm thinking meetups are the best bet, just to meet people, ask questions, and listen to pain points. But that alone is a skill set that needs to be cultivated; asking the right questions, not coming off as pushy, being self confident, and finding the right events.
I find presenting your experience can help a lot at local dev meetups and conferences. If you can find a venue for pitching your product, then great! But most of the time, people don't want to hear a product pitch. Instead, present ideas or work that is related with the goal of the community viewing you as an expert. Writing books or blogs can also help with this. And in your presentations, put your company's logo in the corner.
The nice thing is that presentations shine a spotlight on you, and then potential customers will come to you rather than you having to go to them. Eventually you will need to do the latter, but your first customers are likely to be people in the crowd watching your presentations or their friends. When you do start having to go find more customers, you will have a much better idea who to target as well and have at least a small network to utilize.
>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.
> I just can't imagine cold-calling/emailing people actually works.
I felt this way for the longest time. I hate cold calls. I hate making them, I hate recieving them. Everyone I've ever talked to claims to hate cold calls. Why do people still do this. Who the hell is buying from cold calls?
So I sat down with a couple of people from a sales team, and just asked them what they did. And apparently, a good chunk of their day is legitimately just cold-calls. (Literally through the phone book, or through LinkedIn, or tradeshow cold-stops, etc). While a cold call almost never translate into an instant sale, we can trace most sales back to a start from a cold call.
They don't sell pecan pies or double glazing either. Enterprise software at price tags over $100k/each, or custom development engagements at $100-300k. And it usually starts with a cold call.
So while it still sounds absolutely insane to me, multiple sales people have told me that cold calls work. And these folks regularly win deals and earn good commissions, so I tend to believe them.
This is the reason that us developers keep falling into the same "build first" trap.
Because we're wired the way you describe, unable to even imagine a world where one of those emails would ever get responded to, we miss the sorta obvious fact that, yes, they do work quite nicely.
People wired like normal don't have the same dread of unsolicited contact that we do. And those are the same people who end up as managers, bosses, business owners, etc. People who do the actual software purchasing in the world.
So yes, as impossible as it seems, those mails do work. And we need to send them.
I still find it hard to do. And I'm never anything but amazed when it works.
> I just can't imagine cold-calling/emailing people actually works.
For what it's worth cold calling is a bit different than it used to be—at least in software sales. Today many companies take an account-based approach. This means that there is a good amount of qualification happening before the cold call. Does the account use Salesforce, Gmail, other key integrations? How much ARR are they doing?
If the account is a good match, then the reps will go through the organization on LinkedIn and try and find 3-5 key stakeholders. Who knows about the problems this software solves? Who can be an influencer? A decision maker? Those people are put on a cadence that involves several touch points—emails, calls, social mentions. Stuff like that.
By the time the first cold call is made there is a fair chance that the person on the other end is interested in the solution—or at least in hearing a potential one. Because the research has been done upfront and leads that don't match have been disqualified, this is much more effective than the power dialing.
I made a living using LinkedIn’s sales navigator premium subscription to field prospects. It required me to (a) have a large amount of connections in the first place and (b) have a solution for large enough companies to be represented on LinkedIn. (I did electrical product contract manufacturing sales)
Once the decision-maker position is knowable thanks to (a) + the subscription, it was quick to find a name to use to break into the fort so to speak via a “two-touch” method of email and cold calling. A sale at the end of the day begins with a conversation and a persistence in continuing the contact in order to accelerate a deal.
It’s important to note that presentation goes a very long way; it helps I write in my leisure and have a fastidiousness which shows off in my email templates. That’s where I think many cold callers fail: they are too urgent or come across as too unprofessional which registers as a sense of risk before the relationship can even begin.
Finally, everything involves iterating. I was able to comfortably deliver my sales pitch in under 10 seconds over the phone to some of the largest retail buyers in North America by crafting the message via answering the question: “what is it they need to hear?”
10 seconds is a lot of time, but not so much time that it will leave a bad taste in the customers mouth if they have no current interest. You are trying to help them, after all, and they should be able to receive that first impression no matter what.
Notably, cold calling/emailing works badly for developer tools, decisions are made rarely and we’re pretty locked in once a project is underway. Which is one reason we resist doing it.
But many categories, where you solve a common and easily described business need, it can work great. This is one if the best guidelines for designing a product to sell.
This may sound overly harsh, but if you can't find 10 potential customers to ask them about whether they want your product: How will you find your first 10 real customers?
It doesn't mean this is not a good product for someone to build, but it means this is a company YOU probably wouldn't be able to make successful.
This is just from my experience, cause I have fallen into this trap in the past. ;)
The problem is that what I'm building is a function as a service platform, a general development tool. So developers/managers are the target audience. I think it's a matter of finding the “BANT” (budget, authority, need, timeline) requirements the article mentions.
Why not use this time to "sell" us your function as a service platform? You keep saying its a function as a service platform, but I still have no idea what it is or why it would be useful. I think you're missing a perfect opportunity to tell us more and get feedback from your potential customers (considering the HN crowd is full of developers/managers).
>there's no way to search "startups using x" for a generic technology, like serverless or NoSQL
Are you aware of stackshare.io? It's not perfect for what you're asking - you have to search for specific tools rather than categories like NoSQL - but if I understand your goal correctly it seems like something that'd be useful to you.
Not sure that is a reliable indicator. How many times have you seen job openings that list under required experience years of Java, c++, JavaScript, angular, Java script, HTML, react, nosql, mongodb, and postgres all on the same line? The majority people writing those job ads have no idea what they're asking they just dump the list a few stakeholders gave them and these stakeholders will put anything they can think of in there, including technologies the company has used once 10 years ago for a small project that is long dead.
I have thought of getting on BuiltWith, AlternativeTo, and StackShare. There's probably a way to find small companies doing this (and the job posting tip, which is interesting) but I haven't been as proactive as I could be, I guess.
Crunchbase has a Built With section. I'm not sure how its constructed, but I'm guessing it only looks at what it can determine from a company's site. I suppose github could be another source.
> there's no way to search "startups using x" for a generic technology, like serverless or NoSQL.
1. Make a list of companies & products that implement "serverless" or "NoSQL" or X.
2. There are plenty of tools that search websites to see what they're using. They tend to work better for frontend tech than back though. Sometimes backend tech is visible though. Here's a nice compiled list based off a quick Google Search - https://geekflare.com/what-technology-website-using/
3. Search job boards, industry forums, social media, chat channels (Slack/Gitter/etc), videos, online in general for any mention of those products. You'll get a list of companies using them. Forums, social media & chats will help you see what issues your users are having with them & allow you to build relationships without "cold calling".
"it is hard to escape it because of the simple problem of not knowing who to talk to"
I think this is why the average age of entrepreneurs skews higher...because you get more experience and connections on who to talk to and what questions to ask. And this is why serial entrepreneurs succeed.
If you think of it as a software product standpoint. Once you have a team to build out the entire stack, your next software product would be easier. But the time it takes to find your UI person, backend, mobile, etc...takes time.
My inner circle of professionals are developers. If I wanted some dev resources I could. But when I meet certain people for the first time who don't know a lot of devs, they look at me like a unicorn.
My wife runs a small business/franchise. We were hoping to use that as a stepping stone for future, bigger businesses. There are lots of small business associations around us, Chamber of Commerce, etc. They would have some resources if you want to network.
Steve Blank’s book “Four Steps to the Epiphany” has advice on getting those contacts (and stories of people who finally asked “if we gave this to you for free, would you use it?” only to be told “no”).
> 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.
Search for job ads on angelist etc.. if a company is looking for a dev with NoSQL experience they probably are using NoSQL.
>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.
There isnt necessarily a 'right way' to do things.
I have received terrible advice from marketing/business people. Showing people my MVP was fine for some customers, but others didnt trust me based on a low quality landing page.
While I wanted to make everything perfect and add a feature before presenting it, I was pressured into showing people.
What I thought they'd say, they said. What I thought they wanted, they wanted.
3 years later, things are fine. I worry I created some skeptics that spread negativity(which I've seen).
There is something to be said about building your vision.
As a note/recommendation, don't be absolute in either. Ask for feedback from friends along the way.
I spend a lot of time reading stuff, but I'm starting to think that what I really need is just confidence and persistence.
I'm learning more and more that with many things in life, everything is a gray area. Trying to distill something as complex as success into a ruleset is impossible.
Your story about the MVP is what makes me nervous; it's good to hear that there is some wiggle room when it comes to the MVP impressing or flopping.
It took me years to realise that whenever a non-tech person would see the ugly UI he would actually lie to me about the prospects and give me some generic advice because they simply didn't want to appear dumb.
Not all of them are like that, but you get used to the overthinking approach most of the techies take so you expect some critique rather than some sort of defensive take on the matter.
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.
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.
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.
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.”
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!
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.
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.
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.)
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.
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.
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.
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???"
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.
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
Thanks for the honest feedback. You are definitely correct that there are many successful projects and businesses that did not start with a clear sense that people would use or buy their products. But there are a disproportionately large number of projects and businesses that have failed, precisely because they did not have a clear sense that people wanted what they were making and would pay for it.
Also, this post isn't saying that builders shouldn't begin with a strong, fundamental conviction about how things should be dramatically different. I, as the author, would actually argue the exact opposite. The point I'm making is that once we have our convictions, we should test and measure the extent to which those convictions are correct before investing large amounts of time, money, and energy into productizing them.
Lastly, the point about asking questions and then listening to customer feedback would only result in building minimally better products if the product hypothesis we start with is itself unimaginative. But that hypothesis can be literally anything. Customer feedback simply teaches us if market demand lines up with our assumptions about market demand.
A "Hobby" project turning into a business is a rarity. It comes down to expectations of returns.
If you want a business, a monetize-able product, you have to think about sales. The observation that majority of Software start-ups fail to avoid the mistake #1 from this article is accurate. And majority of Software start-ups start with an expectation of monitory returns.
If the expectation is a personal sense of fulfillment, anything other than a business for that matter, then what you are creating becomes more of an art than a product. There is a chance you might earn from it, but it is slim.
So the entrepreneurs would rush to it's keyboard create a clone of the Tech and add the feature X.
The important thing to remember is that most software isn’t that special. Sometimes you will be redefining the whole market; more often you will be building a faster horse. But that’s okay! People using horses still want them to be faster, and it’s a valid and often successful business strategy to sell products which are similar to, but better/faster/cheaper than, your competitors’.
I don't see listening carefully and asking open ended questions as a step towards simply building what the potential customer wants.
Quite the opposite: seeking to understand their underlying needs, the context they are in, and the factors influencing their thinking helps build empathy.
If we truly understand the needs we are trying to fulfil it is more likely that we will build a good product, it's a superficial understanding that tends to lead to products that are treating symptoms rather than causes and only minor improvements.
Open ended questions is how you understand their underlying needs.
"What are your pain points" and "so why is that an issue" can give you incredible insight just by listening. They should be doing 90 percent of the talking. honestly playing dumb is powerful.
Engineers tend to want to be right and give answers which make them terrible sales people.
The best way to do this is by asking good questions, and then listening carefully and taking notes
Even better is to watch people work. I've written
software for domains where I'll never be an end user and knew very little about how the end users actually work. Talking to people and asking questions is of course nice, but nothing beats sitting behind an actual end user for 30 minutes and watching what they actually do.
>"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.
There are two big problems. If someone has lived without X for long enough they've probably found workarounds for living without X so that just adding X might not be that valuable to them or at least it might be hard to convince them how valuable it is to have X. The second is you often greatly underestimate how much work it is to get to the point where you have a good enough clone to even have something to add X to. And while you're busy working on your clone the original company might get around to adding X and thus undermining your whole business.
Haven't we all seen examples of companies that do the same stuff as other companies but better and succeed?
Sure, but they're often better in a whole category of ways (price or speed or ease of use etc.) and not just a clone of an existing product with X added.
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.
">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"
... --> not if you are actually listening!
Listening is not about 'let them tell us what feature they want' ... it's 'problem discovery'.
This is maybe the most valuable thing because young devs with 0 exposure to how operations actually work within a company will have their eyes opened wide.
This is where you can hone in on both real and perceived pain points, and develop the lingo that will work in messaging as you go to sell the 'learned' product you make ...
It all comes down to domain knowledge, I believe, where it is hard to provide good solutions without actually knowing anything about the type of problems being under scrutiny.
There are other types of generic problems, e.g. word processing, but those domains are often overpopulated with solutions where it is either hard to compete or hard to earn money.
The point you are making is that it is worthwhile to invest in understanding a problem domain well and the more specific it is, the more you have it for yourself :)
It's not just the problem domain though - there are issues that are very specific in the 'real world' that are not apparent to those even who understand the problem domain well, especially if it's a true B2B style product. Second, is understanding the mindset and uses cases of buyers. Tech people tend to way over-estimate the sophistication of users, and also underestimate how hard it often it is to do basic things.
I once worked for a huge high tech company in Product Marketing, we wanted to run this simple program to reach out to some users. Our problem? We had to host a few images and bits of content and we literally had nowhere to host them. Seriously. Just a few images. We had no production capability for that ... even working with the marketing ops teams ... they have complicated tools and content management systems unsuited to 'just hosting a file'.
We reached out to our customers (carriers like AT&T) so that maybe they could host. Same problem! We're talking business unites of major high tech corporations here unable to just host a file.
Want to use S3? Or whatever? Enter 'legal'. Make a request to the legal department, maybe get a response in a month. Maybe.
It was eerie and funny and sad ... but it was a real eye opener.
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.
> 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.
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.
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.
>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.
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.
> “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!
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.
Why do you think my comments did not already account for that? The article claims that software engineers make the mistake of building before they sell, and advises an aggressive form of selling before building instead.
But that advice directly means to skip engineering due diligence (which very often requires building before you sell). It doesn’t matter if the person implementing the advice would be an engineer or a sales person or anyone else.
Your comment comes off as if it is supposed to glibly (and I think also rudely) undermine what I wrote, but in fact I think you didn’t understand what I wrote, and you seem to suggest that it would be impossible for an engineer (using the article’s advice) to fail to consult an engineering estimate of technical feasibility prior to selling something.
Having a high degree of confidence that you are capable of building what you are selling is a given.
Nobody reading this is building anything resembling a perpetual motion machine. Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.
Your comment is plain old reductio ad absurdum. It’s not clever.
Writers are entitled to favor conciseness over having to pre-empt any fallacious dismissal they’ll get from whichever random person on the internet needs to entertain themselves that day.
> “Having a high degree of confidence that you are capable of building what you are selling is a given.”
No, it is emphatically not a given. Not in the context of some new CRUD tool. Not in the context of latest & greatest self-driving cars. Absolutely not.
> “Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.”
You’re just simply extremely wrong about this. Even internally to a large company you often have projects spun up for face detection, natural language processing, complex workflow management tools, adtech tools, embedded systems, robotics, medical devices, systems dealing with personally identifying information, and on and on.
Expand to include start-ups and the breadth and scope of products being developed grows dramatically.
All the time, across all of these situations, you face engineers, product managers, sales people, and many others, who over-promise on product offerings during initial stage sales piloting. It happens all. the. time. And one of the most serious drivers of this huge and risky oversight is a lack of investment in building parts of the product in advance of attempting to sell it, in order to acquire knowledge that you did not already have regarding the cost and blockers of the engineering implementation.
That you dismiss this as implausible by saying “confidence that you are capable of building what you are selling is given” is nothing other than an indication you do not know what you’re talking about in this topic. I feel frustrated to receive such a rude comment that is self-evidently more focused on trying to undercut me, even mentioning wildly non sequitur things about concise writing as if it applied to the original article, than focused on the actual discussion of the thread.
It just doesn't invalidate the point the article is making.
Your point - which I'll paraphrase as don't sell something you can't build - is valid and important.
The article's point - which may be paraphrased as don't build something you can't sell - is also valid and important.
Neither is more important than the other; like basically everything in business there is a tradeoff, and the ones who succeed will be the ones who get the tradeoff right.
But the author makes their point because they see too many people over-optimising on the "build first" approach and failing, when they might have avoided failure if they'd done a bit more "sell first" - or, as the article actually says, "talk to potential customers to properly understand what they want first".
You're getting frustrated (indeed, coming across as enraged) and resorting to strawman and absurdist arguments because you're incorrectly seeing the article as making an absolutist point, and then responding to it with your own opposing absolutist point. If you just approach the topic with appropriate nuance you'll save yourself the need to be frustrated.
Edit: changing implied quotes to be clear they're paraphrased.
Sure at a big company. But this advice is targeted to engineers who want to start their own company. Its unlikely they can even afford any of the layers of cruft you are talking about.
If this was advice for starting some new initiative at BigCorp I might agree with you.
The need to build before selling is more critical for start-ups or single person gigs or consulting, because in those situations you don’t have existing stable revenue streams to use to absorb financial or reputational losses that come from underestimating implementation time or cost and failing to deliver sales promises.
If it matters to build before selling in a mature company, it matters even more in a start-up / solo business / consulting feasibility discussion / etc.
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”.
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.
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.
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.
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).
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.
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).
> 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.
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.
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
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.
Also I don’t think there is a right way of doing a startup, there’s no guide you can follow or rules. What I’m saying is that addressing real problems and talking with people that have the authority and budget to address them before building something seems like a good way to minimize risk for b2b ventures.
Anyway the advice of sell first build later and talk to customers sound very smart, it's just that it I don't see much of success stories based on that process.
On the other hand, build something basic, put it in front of the people, measure and iterate based on the measurements have so many examples. Like pretty much everything out there.
So yes, the stuff on the article sound smart but is it?
Tuft and Needle started selling with a fake landing page to validate their idea.
Once they got their first sale for a mattress they started working on the company.
(source: their indiehackers interview)
Hotjar started a super successful referral campaign before having a working product.
Pietr Levels validated features with a fake credit card form to see if people would pay for some membership.
And there are countless other examples. Building a landing page that explains the product or a proof of concept isn’t building the product, if something can help you give the idea of what you have in mind build it.
Oh, it happens to me too. As techies maybe we think in the context of "Wouldn't be cool if..." and just really want to believe that it's not just cool but actually people will use it and pay for it and ignore the signs of the opposite as long as we can because it's really cool and sure people will come around and see how cool it is if I can make it shinier.
>you added a reference that your thoughts are for B2C. But Facebook and Google are B2B, the Cs are the product
It still holds though, they had the product(the users) first. They did not start as companies that figured out that they need users by first selling ad spaces to companies and talking to them. They had something valuable in hand(usres) and iterated the business models through the years.
Facebook was created to solve Mark's problem of accessing a pipeline of hot girls to sleep with. It grew because while solving his problem he solved the exactly same type of problem the other people had, including the hot girls who needed a pipeline to pretty boys/jocks/nerds/etc to sleep with.
The clean product we currently know came much later.
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
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.
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]).
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.
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.
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.
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 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.
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.
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.
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
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.
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.
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.
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_.
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.
I totally agree with you if we are talking about preliminary market research, which also usually involves components of research into the technical investment required.
That said, the article of this post seems to emphatically say something different: that you should actively _sell_ before building. Not merely collect research, but to sell stuff you do not already have the capability to deliver, and then somehow backfill that delivery capability after getting customer buy-in.
I’d say even for some new CRUD app, assumptions that it will be easy to build are so, so common, and the reality of most “super simple CRUD apps” is that the implementation is way harder than you thought, and selling advanced features before you definitively know how to build them is a big source of failure for seemingly straightforward products.
It’s very much sales hubris to ever believe you know how to build something you’ve never built before, even in cases when it might seemlike a minor variation of something you built before.
My take is that the purpose is not to actually close a sale before building, but to make sure that you could actually close a sale.
The article makes the correct point that many people confuse "being sort of close to closing a sale" with actually closing a sale, and these people may waste time building a product that clients are only sort of interested in but aren't willing to actually pay for.
I'd also add that you should find common requirements that customers have and build your solution around those.
Much better to have 100s of customers using a product with 1 feature, than 1000s of customers using a product with 1000s of features (with the corresponding overhead).
I think you might be taking the term ‘selling’ too literally - it’s pitching an idea and soliciting feedback. If you’re taking orders for something that doesn’t exist yet, you’ve done it wrong. OTOH, if use the 3/12/24 months it takes to build the product to listen to future customers, you can ship something of value as soon as its ready.
Nothing wrong with taking orders for something that doesn’t exist, so long as you can deliver.
The sales team’s problem is that they didn’t know what was technically feasible.
There may have been a way to decipher whether what was promised was build-able... before trying to build it.
And in any case, the point of collecting payment is to validate the market. No better validation than actual sales. But doesn’t mean the money has to be spent. They should hold on to it in case they need to give out refunds, and give out refunds when they have determined that they can’t deliver.
And in the special case of a kickstarter type campaign then the basis of that relationship was that the product may or may not come to fruition and that they don’t have to give out refunds.
Sounds to me like those people got tons of people to give them free money to try to bring something to market with no ramifications if the product can’t go to market. And no obligation to give out refunds if the product doesn’t go to market. How is that a failure?
The point isn't to finish selling before you build, the point is to start selling -- do market research -- before you build.
You use the term "investment" -- do you invest in stock market / bitcoin / real estate by buying whatever looks cool, and chalking up your losses to the learning process, or do you research your choices and look for ROI opportunities??
I agree that your interpretation is right, but "start selling" is an extremely ambiguous phrase here. After all, "a sale" is most often understood to be a finalized sale; "to sell" is most often understood to be completed transaction.
Yes, the idea here is, "understand who you're marketing to and what they're looking for before you start building," and the phrasing used is what it is because that's catchier, but it's still not particularly concrete phrasing.
> "to sell" is most often understood to be completed transaction.
That is certainly the understanding of laymen. However, if you talk to people who work in sales, and look at their "pipelines" for creating sales leads, followup, closing, and whatever else they do, you get the sense that "selling" is actually an extensive, multi-part process. At least I think that's the view most sales professionals would have.
I think your comment about investing in other assests only further agrees with my point. Selling before you build is like investing in an asset without due diligence.
I don't think the article is about companies building a new product before selling it. All companies do that and it works. I guess the article is more about engineers (usually one or two guys) building a product on their own (full-time or on the side of their job) before talking to any potential customer. Basically spending x months building a product then sending the first emails to companies that could be a good fit, and in most cases, don't find anyone interested in.
Yes it sounds like a stupid thing to do (and I did the same mistake). I think that's the difference between an engineer and an entrepreneur: one wants to build an app, the other one a business. Obviously you can be both, but I guess lot of people will try and eventually find out that they are more engineers than entrepreneurs.
Maybe the answer is to pre-sell a very simple product that you are certain you can build. Any half-decent engineer can build a CRUD app that consumes a spreadsheet and renders some graphs, for example. You can add all the theoretical magic that turns a good product into an amazing one after you build this basic MVP.
Fundamentally it's about risk.
If your startup is writing OCR that out competes tesseract or automatically diagnoses melanoma that has very different risks than building a B2B product to allow optometrists to manage their clients.
In general though I think most startup's have more go-to-market risk than technical risk. If you can out compete tesseract in OCR you're not going to fail because of market. And if you're Salesforce you're not go to fail because you can't build software to track leads. You're going to failed because you couldn't find enough users.
This is why investors spend so much more time looking at adoption rates, and so little time looking at the backing infrastructure.
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?
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.
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.
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.
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.
> 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.
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.
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.