Comment by kerkeslager

Playing devil's advocate here:

This is basically an attempt to gather more information before you act. In principle, that's an Obviously Good Thing. But you have to question whether that information is actually as conclusive as you want it to be, and whether you're changing the outcome by observing it. There's two problems with the information you gather by making phone calls and showing mockups/designs:

1. Mocks/designs only communicate a fraction of the product, and often the parts that aren't visible in mocks/designs are the most valuable parts of the product. Speaking in vague terms: I'm working on an app where the main value is that it calculates actionable numeric values that users typically calculate in spreadsheets. The UI is certainly a selling point, but users aren't going to easily understand the connection between the new UI and the old spreadsheet formulae without playing with the actual product. Phone conversations are likely even less communicative.

2. Communication is a two-way street: releasing early allows you to get information from your users, but it also leaks information to your users, which may not present the image you want. Kickstarter has shown that with good enough marketing you can get paying customers with literally nothing. But you can also burn customers so they never want anything to do with your product ever again. There are numerous high-profile failures-to-deliver that have killed not only products, but the reputations of individuals and companies. But failure doesn't have to be that catastrophic to lose customers permanently: all that has to happen is for someone to pay for your product, find it a bit lackluster, and decide to cancel their subscription. That user is worse than a non-user, because they are never going to be a user again, and might tell others about their experience. Short term success not only isn't an indicator of long-term viability, it can cause long-term non-viability.

Sure, it's cheaper to validate problem/solution with phone calls and mocks/designs, but you get what you pay for.

The best strategy probably lies somewhere in the middle: code a minimum viable product, but really make sure it's the minimum, and really make sure you think it's actually viable. A good compromise might be to release a discounted beta for select users--that lets you get feedback from paying customers up front, but also sets expectations so that users don't get the wrong idea about your product before it's mature enough for a real release. It also limits the exposure, so even if you burn a few beta users, you don't burn your entire potential user base.