[bambax]

> Sales Mistake #1 - Building Before you Start Selling (...) If you’re wrong, you’ll save time and money by not building something people don’t want.

I fell into this trap often, so I know it well. The reason why we don't ask first is, we want to build something. Anything. If we're "wrong", we won't "save" time and money, we will delay the moment we start making, maybe indefinitely. What if we never find something people want?

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

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

[Fergi]

(Jeff from PipelineDB & post author here)

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.

[adonnjohn]

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.

[Fergi]

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

[mygo]

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

[heavenlyblue]

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

[gitgud]

>"maybe they don't understand it yet, so I should spend a bit more time on it".

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

[jeremyjh]

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.

[TheOtherHobbes]

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.

[Darmani]

Prototype. Make a pen-and-paper version, pantomime the game, tell the story -- do something to test the game's excitement power before building it.

http://www.pathsensitive.com/2015/10/the-prototype-stereotyp...

[king_phil]

Not sure if angry birds would have made a great pen & paper game ;-)

[wastedhours]

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)

[darkerside]

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.

[jcadam]

True. Especially when I build something that solves one of my own problems. I think it's great and maybe others would like it too.

Then I discover that amongst all of humanity, I have problems which are absolutely unique and shared by no one else, anywhere.

[stanleydrew]

Don't be so hard on yourself. Someone else somewhere probably does have each problem that you have.

But finding them is prohibitively costly.

[teachrdan]

And they're poor.

[jcadam]

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.

[dreix]

I am poor therefore I write my own software.

[thrownblown]

I don't understand down votes.

I often will see the price of an API (cough Google maps) and roll my own solution.

[sokoloff]

An independent developer capable of making a replacement for the entire Google maps API on their own probably isn’t likely to remain poor for long.

[z3t4]

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.

[mpweiher]

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.

[bambax]

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.

[almostarockstar]

I have also been here too many times to count.

My take on it is that it's not a failure as long as you've learned something.

In my case, for the first number of projects I built that nobody bought/wanted, I didn't learn to find the market first (sadly), but I did learn a huge amount about how to build things.

Now I can build better things faster - but I'm actively learning to find the market.

[Aaargh20318]

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.

[cstejerean]

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.

[nobody271]

Well how is my audience supposed to know what I have to offer until they have it in front of them? Before that it's just me telling them an idea. Even after it's done I would not expect users to start using it on their own. Then you have to play a whole different game of getting people to use it.

[lbotos]

A few years ago I wanted to make a niche marketplace to sell/trade tabletop miniatures. Instead of actually building the thing, I made a few mockup interfaces pages, and then just made a responsive HTML page. None of the buttons actually worked. I then put a modal that said "launching soon, sign up now for news and a special bonus on launch".

I spent $100 on ads on reddit and targeted forums with the goal to get 100 emails. If I got 100 emails, I would actually try and build the thing.

I got ~57.

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

[Baeocystin]

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

[lbotos]

I knew it was a small niche market, and I set it as really a "reasonable" goal.

"If 100 people in 30 days are interested with this ad spend, then I'll reach out engage them and build the thing."

Depending on your app/market, you can change that number accordingly, but I think 100 is just a great "feel good" number thats hard enough to hit as evidenced by my test.

[JumpCrisscross]

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

[quest88]

As one of the points in the article: listen, don't talk!

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.

[avinium]

I don't entirely agree.

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.

[sobani]

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

[naasking]

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.

[curun1r]

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.

[FiveSquared]

See YouTube

[starbugs]

AFAIK, YouTube started as a dating site and then pivoted based on actual usage patterns. See https://www.cnet.com/news/youtube-started-as-an-online-datin....

The whole thing wasn't built to become what it did. That's why you shouldn't build (too much) before starting to sell.

[new12345]

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.

[osrec]

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.

[lozzo]

Very lucid comment. I would just object to your harsh "it's irrational and probably stupid..." final remark. It's not irrational and stupid. Building something allows you to sharpen your skills, validate your abilities, engage you to the problem you want to solve for real. cheers

[jononor]

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.

[starbugs]

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.