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.
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 of stumbling upon a perfect business model by speaking to the customers before / during product design.
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.
My thought are usually; "I know no one wants it now... but that's because they can't see my vision..."
How many times do I have to destroy my ego...
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.
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.
Then I discover that amongst all of humanity, I have problems which are absolutely unique and shared by no one else, anywhere.
But finding them is prohibitively costly.
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 often will see the price of an API (cough Google maps) and roll my own solution.
But where the heck am I supposed to get all the data?
That’s exactly my point. Making a full replacement for an API (endpoint) is much more than writing some swagger.
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.
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.
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.
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.
"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.
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.
Listen to problems people have now before you build so you know what to build. Then you can easily explain your product in terms of their problems.
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.
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.
The whole thing wasn't built to become what it did. That's why you shouldn't build (too much) before starting to sell.
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.
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.
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_.
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.
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.
One is highly possible and likely, the other is not. Most ideas will be somewhere in between.
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.
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.
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).
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?
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??
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
If it didn't work people wouldn't be doing it I presume. It probably works every now and then but it's good enough when the cost of doing it is low.
When does it work? When you reach someone who is actively looking for it.
For example, in the talk given by YC Partner Aaron Harris, suggests that cold e-mailing professional investors work when done right.
Perhaps you need to go to meetups with potential customers instead of other developers.
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.
Smells like a side project waiting to be built.
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".
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.
Search for job ads on angelist etc.. if a company is looking for a dev with NoSQL experience they probably are using NoSQL.
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'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.
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.
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.
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.
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.”
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.
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'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.
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.
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.
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???"
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.
>The biggest mistake I see developers make is assuming that they are building something that people both want and will pay a meaningful amount of money for.
Lots of projects were build with no exact plan on how to monetize them of if there would be customers to buy it. They just had a vision about how X or Y technology should be , and just created something by putting their guts in it.
The idea that you should marketize something before starting to build is coherent but not true for tech especially when Innovation sometimes requires to educate the customers about how to use a technology , Serverless and Docker are good examples of that I think.
>The best way to do this is by asking good questions, and then listening carefully and taking notes
Again I strongly disagree here. This pattern pushes entrepreneurs to create a version++ of something already existing because the customers told them :
"We are using [Insert Tech Name] and it doesn't support feature X"
So the entrepreneurs would rush to it's keyboard create a clone of the Tech and add the feature X.
This is usually called consulting in my opinion and they are already lots of people doing that... Being a "Founder" of something involve taking risk and not just adding a tiny feature because it can brings money on the short term.
It's about having a vision.
As a result , we could quote the hundreds of email startups we have today who basically do the same thing with often one tiny feature of difference...
> that does not mean that you have created enough incremental value for customers to make them willing to pay you a meaningful amount of money for your product
I agree on this one.
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.
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.
I have the honor of making all three mistakes you mention and my project didn't end up well :).
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’.
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.
"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.
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.
You need to succeed in sales if you want to make sales, otherwise not :)
>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.
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.
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 ...
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 :)
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.
And the money for covering expenses and living came from..?
> It's about having a vision.
I have the vision that crap like Hadoop should be rewritten in Go. Shall I dive in and start re-writing?
Where are all the crypto visionaries nowadays?
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.
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.
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.
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.
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.
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!
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.
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.
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.
If this was advice for starting some new initiative at BigCorp I might agree with you.
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 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”.
Great point, though! This is an important topic to consider with marketing and sales strategy development. Thanks for the comment.
Especially in mid to large B2B plays.
Customers just want to have a better picture how it is supposed to work, instead of looking at powerpoints.
#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 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).
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.
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.
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
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.
I was unable to confirm it.
Anyway the advice of sell first build later and talk to customers sound very smart, it's just that it I don't see much of success stories based on that process.
On the other hand, build something basic, put it in front of the people, measure and iterate based on the measurements have so many examples. Like pretty much everything out there.
So yes, the stuff on the article sound smart but is it?
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.
I think I took the "selling" word a bit too literally.
I find this topic to be really sensitive to me as I find that the first impact with the customer is always a big reality check for every idea I have.
I often find myself building what “I think” people/companies want, but I think it’s healthy to try and build what they’re already willing to pay for!
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.
The clean product we currently know came much later.
Keep local data only until you quit your browser.
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. ).
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.
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 wrote about what I learned building and selling a cybersecurity saas here, don’t make my same mistakes: https://ferrucc.io/posts/sales-for-cybersecurity-saas/
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.
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.
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.
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 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?
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.
Also there are some visa restrictions - in some places you could stay up to 60 days, Indian visa is usually just 3 months.
Nevertheless, remote Indian and Nepalese hilly areas are absolutely wonderful.
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.
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.