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.
http://www.pathsensitive.com/2015/10/the-prototype-stereotyp...
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.
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.