Some questions about a startup idea can be answered with a conversation or a cheap web page. Others need a working product. A lot of wasted effort ...
For further actions, you may consider blocking this person and/or reporting abuse
cheapest test that could come back negative. most validation plans skip the part where no is an allowed answer.
Yeah, and I think that's the part people struggle with most. It's easy to keep tweaking an idea until the feedback looks positive. Harder to accept that the idea itself might need to change.
tweaking until feedback looks positive is the trap. changing the idea itself is the harder call.
True. Sometimes we're so focused on making the idea work that we forget to question whether it's worth pursuing in the first place.
yeah, the worth-pursuing question comes before the tuning. most threads skip straight to tuning.
Yeah, and by the time you realize the idea itself might be the problem, you've already spent weeks trying to make it work.
The split between customer risk and product risk is the useful frame here. Most founders who come to us with a full feature list have product risk in mind, while the thing that usually fails first is whether anyone will change their current workaround.
Odinaka's line about the cheapest test that could come back negative is worth keeping. A landing page with a real call to action, or a manual pilot run by the founder for three customers, can answer that before any code exists. Revenue Operator's distinction between market proof and language proof also matters: if customers describe the problem in different words than your page uses, the page test will undersell a real need.
Where a build does make sense first is when the product itself is the test, for example a workflow nobody can judge from a mockup. Even then, one narrow workflow is enough to learn from.
The Buffer example, where a pricing page sat between the two pages so a visitor had to click a plan before leaving an email, is a good model for the cheap test. Before building, I'd check three things: market proof (are similar products selling, with review counts as a rough proxy), language proof (collect 10 posts where people describe the problem in their own words and reuse those words on your page), and one behavior test such as a fake-door pricing page or an honest pre-sale. If two of the three are weak, change the buyer or the problem before you build. If the risk is mostly in whether it can be built, the Figma route makes more sense, but for most solo makers it's customer risk.
I like the distinction between market proof and actual behavior. Seeing similar products sell is a useful starting point, but it doesn't tell you whether your specific buyer has the problem badly enough to pay for your solution. That's where the behavior test becomes important.
Exactly. Similar products selling tells you the category is real, not that your version is the one people pick. The cheapest behavior test I know is a page with the price on it and a real checkout or a waitlist button, then counting clicks from people who don't know you. Have you run one of those on anything you've built?
Haven't tried that exact test yet. The part about using people who don't know you makes sense, though. It's easy to get positive feedback from people who already know you, but that doesn't tell you much about whether a stranger would actually pay for it.
thinking a product is an MVP from pen and paper, in my humble opinion, is a road heading for demise. there is no place for arrogance in the world of product, at least not at a small scale. at the same time that you build it, there can be someone in the world other then you preparing to already publish it. an mvp MAY become an mvp after several people have tested a pilot functional enough to provide feedback, and when you receive their feedback it should be more than decent to merely start to believe you have an mvp. an mvp becomes an mvp after it had provided best usage in it's area. Nadia Comăneci was the first gymnast to earn a perfect 10.0 in Olympic history and became at her time the only MVP in her department, but she still had to firstly run her routine to prove she actually is an MVP. Same with product. Be humble in your journey.
I agree that real users need to test it before you can know if it actually works for them. I see an MVP a little differently, though. I don't think it has to prove it's the best in its category. It needs to solve one real problem well enough for people to use it, so you can learn what to improve next. That's where their feedback matters.