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