Hacker News Reader

Comment by daenz | Hacker News Reader

I've been in your shoes many times. I worked for many months, solving a problem that I thought needed solving, and then sought users to pay for it. All of those attempts never resulted in success. My most current project though, I am doing things differently. I talked to people and listened to what they needed. I saw an opportunity in what they were asking for, so I started building, while letting them use it as soon as it was even a tiny bit functional. I only invested my time building when there was a positive signal that people would pay for it.

I know this probably isn't what you want to hear, and you've probably heard this advice before. I was like that too, and I ignored it. But it really does seem to work.

View on HN

Good advice and something I wish I would have been told earlier.

I went through a YC Startup School session a while back and there was a session about how to get your first customers - I can’t remember who it was (maybe Seibel?), but he (paraphrasing) answered it with something like “why are you building something if you haven’t talked to your customers”. It’s really stuck with me along with the “build something people want” thing.

> why are you building something if you haven’t talked to your customers

* because it's a secret and you don't want competitors to get advantage

* because customers won't get the idea without a mvp

* because revealing your idea might reduce your impulse

* because customers will ask for all kind of features and change your idea into something else, more practical, like "get a job" instead of dreaming in your great idea

> because it's a secret and you don't want competitors to get advantage

Talk to your customers about their problems and their needs, not the solution itself. The solution can remain a secret.

> because customers won't get the idea without a mvp

Again, figure out the customers problems first.

> because revealing your idea might reduce your impulse

Don't reveal it until it's ready to be revealed.

> because customers will ask for all kind of features and change your idea into something else, more practical, like "get a job" instead of dreaming in your great idea

If customers are asking for features, then there's your demand right there. Strategise on how you want to address it.

because, depending on the customers, they do not know the technologies to help them exist, or they mistakenly believe are only available to their big kahuna, deep-pocketed competitors.

> because it's a secret and you don't want competitors to get advantage

If it's that easy to replicate then what's to stop them from copying you and eating your market share once you've launched?

> because customers won't get the idea without a mvp

If that's true then you have to ask yourself if you're actually solving a problem people have or designing a solution in search of a problem. Which then comes back to the GPs advice about speaking to your customers.

> because revealing your idea might reduce your impulse

I guess that's possible but often I see the reverse: engineers spending forever refining their idea because they're scared to release anything until it's perfect. At least by revealing your idea you're committing to a release early and often model that would see actual users on your platform.

> because customers will ask for all kind of features and change your idea into something else, more practical, like "get a job" instead of dreaming in your great idea

Sorry but I don't really understand the point you're making here.

If you're saying customers will ask for more practical features then surely that's a good thing? The opposite of that problem is spending months building something users don't want nor need. Which again, comes back to the GPs advice about speaking to your customers.

If you're concerned that people will tell you to "get a job" then that could happen regardless of whether you announce your project or not. I don't really see how secrecy would affect the opinions of those kind of narrow minded individuals. Plus why should those comments even matter in the first place when they're clearly not relevant to your task at hand?

+1. I used to take the same position as ffhhj on this and I learned the hard way to talk to customers first before doing anything. I'm not saying that building in stealth mode without talking to customers can't work, I just believe it greatly reduces your chances of success.

Incidentally, I think the equally common advice of "solve a problem that you have yourself" is coming from the same place: you can't solve a problem without understanding your users.

> Incidentally, I think the equally common advice of "solve a problem that you have yourself" is coming from the same place: you can't solve a problem without understanding your users.

So does this mean that it's okay to start developing a product if you yourself have such an (acute) problem even if you don't check for/with external customers first?

Sure, but don‘t expect anyone else having the same problem and as such being prepared to pay for it.

" what's to stop them from copying you and eating your market share once you've launched?"

Nothing. So the only defense would be, having a good headstart, by having a working product by the time of release. Just presenting ideas and sketches does not give this edge.

> Nothing. So the only defense would be, having a good headstart, by having a working product by the time of release. Just presenting ideas and sketches does not give this edge.

Nobody is suggesting you should publicly disclose all your preliminary ideas and sketches. It's more about researching your users problems and having discussions there.

Plus you could argue doing this actually aids in your "headstart" rather than hinders it:

1. You can approach the project with a better understanding of the problem domain and thus can tweak your solution to the captive market (rather than having to repeatedly pivot your product until you chance upon that market).

2. You already have contacts of potential customers before you launch.

Anyone working in secret has to figure those two problems out after they launch.

'Everything' is stopping them from copying the idea.

Doing a startup is a huge amount of work. Like the shipping coordinator for the warehouse you're selling into is going to just 'do a startup'? Or the lady who supports customers in the field on dialysis machines is going to go from middle aged customers service support to CEO?

There are other things to worry about.

1) Forget about competitors ripping you off. It could happen, but probably won't at the start.

If you're building an SaaS for some company/client that needs, it there's almost 0% chance of them ripping you off. A bank that needs some specialized HR software is not going to start making HR software.

2) It's absolutely reasonable that customers have a hard time grasping abstractions. 'Seeing It' is a huge chunk of the story.

3) It's very valid that 'early users' will pull you in a bunch of different directions - many of them are rabbit holes, not generalizable, poorly thought out.

They will literally ask for things they don't even actually need. It happens all the time customer XYZ demands some feature, then they don't use it.

This is why it usually helps to have faced the problem yourself, you can get to an MVP that has some 'coherence' and then go from there.

> Forget about competitors ripping you off. It could happen, but probably won't at the start.

That was the point I was making. If competition is your concern then the problem is either too simple or your solution doesn't meet the customers requirements.

> If you're building an SaaS for some company/client that needs, it there's almost 0% chance of them ripping you off. A bank that needs some specialized HR software is not going to start making HR software.

Depends on the problem you're solving. Not every problem requires a building a SaaS, for example.

> It's absolutely reasonable that customers have a hard time grasping abstractions. 'Seeing It' is a huge chunk of the story.

I'm sure there are instances where that's true but the problem is if it's hard to grasp then it's harder to sell. This is particularly true when you factor in that spend is usually signed off by non-engineering managers. So if you're building something that is hard to grasp then you better be damn sure that you're solving a problem that is easy to conceptualise as important (like security tooling).

> It's very valid that 'early users' will pull you in a bunch of different directions - many of them are rabbit holes, not generalizable, poorly thought out. They will literally ask for things they don't even actually need. It happens all the time customer XYZ demands some feature, then they don't use it.

Nobody is suggesting you should implement each and every suggestion raised in your market research. However not doing any prior research means you're essentially taking a shot in the dark.

> This is why it usually helps to have faced the problem yourself, you can get to an MVP that has some 'coherence' and then go from there.

It helps but you shouldn't blindly assume your problem is identical to everyone else's. You made an earlier point about early users pulling you in a bunch of different directions, not all of them being well thought out. Well there's nothing stopping you going down your own rabbit hole of poorly thought out assumptions even when you have faced the problem yourself.

The moment you try to go to market is when you realize that your IPO is probably not happening any time soon.

For me, the heavy lifting here is being done by you having a network of people that recognize you as the right person to build the thing they need (productivity tool in this instance).

Based on my (limited) experience with startups I would rather have this than a network of funders or great developers or almost anything else you can accumulate before you start.

The people who'll appreciate and tolerate your MVP, are a very small subset of your target market that have serious pains to address and/or substantial gains to be made.

Unless you are solving your own problem, and have pains/gains that strongly match with that small subset you will be struggling on the wrong beachhead. You are likely to solve an aspect of the wider problem but with little chance of getting much further.

If you don't listen to people you'll need to be very lucky with loyal supporters, or a very rare visionary with incredible talent and commitment.

People generally won't or don't reveal their deep pains and needs (gains) until you probe and engage in direct research through conversation.

re: The people who'll appreciate and tolerate your MVP, are a very small subset of your target market that have serious pains to address and/or substantial gains to be made.

I guess the real problem is how to find these small group of potential passionates for your mvp

Reply on news.ycombinator.com