How did you validate the idea of your current product?

I would start by validating the problem itself and understanding it fully, who is it affecting and why? Making sure there are no personal bias getting on the way. Once you have a solid understanding of how / why / when the problem develops you can jump to ideating a solution (idea) that fits that problem. I like 2 ways of validating the idea before jumping to development: 1. “Build products that don’t scale”. Before developing test the idea by yourself, make something small that helps you prove the interaction. Example: if you are building an app to make restaurant reservations, forget about automating the whole process, allow the user to input the information of the reservation and you execute it in the backend manually. Make it look like it works and check if users engage with your approach 2. Make it look like you already have the product and “pre-sell” it. Measuring the demand and your customer segments willingness to pay is KEY to moving forward into development. Even then, when your solution is validated you should start small, a focused MVP that solves the core pain. It doesn’t even need to be scalable yet, you could build it in a no code tool until the demand pushes you to scale. This is a happy pain, it means you are doing the things right, reducing the risk of building something that your customers wont like. That’s how i see it, but there is no one size fits all solution. Hope it helps :)

I actually built my product around maximizing this very thing. Too many products fail or don't get the traction that they could because it's not aligned closely enough with customer needs. And, those products tend to need to iterate a ton. Iteration is expensive after your launch (in terms of both time and money and confused branding). Plus, any sales and marketing efforts are going to do exponentially worse by not aligning quickly enough. The tried and true method for many entrepreneurs seems to come down to either "follow what you want because somebody else out there probably has the same need" or "talk to a few people and just iterate later." It turns out that a majority of the time, at least according to studies, is that it leads to subpar long-term results. The formula that my software is focused around comes down to a few methods that have been proven through various studies to increase the odds of success. But, it essentially comes down to thorough surveys that ask the right questions and an ability to calculate willingness to buy at a given price point across a variety of potential features. But, for those that don't want to or can't afford to pay for my product, I'd say try this: First, just flat out talk to 100 people and be methodical about it. Then, when doing so, try to find out which pain points bother them the most, see how frequently they feel it, determine what alternatives they use to handle that currently. Use that to determine if you have the skills to provide a set of potential solutions, then look at which solutions at which price points get the most traction. It sounds like a lot. And, it kind of is. But, the time it takes to talk thorough to a boat load of people is going to save you months in the long run when you account for all of the indirect costs.

The comments here cover it quite well. As @alexander_moen pointed to, be methodological about talking to your potential users: Do a few test interviews to begin with, then devise a interview plan and make sure to code responses, so you can do some broad brush strokes, analysis upon afterwards (shows you are willing to get your hands dirty and engage with your end-users, investors love that). It's crucial to keep a set of questions that are VALIDATING THE PROBLEM, and it is a problem that is painful enough for users that they are willing to invest the effort into solving it (with your solution). Think of questions like: When you do [process] do you experience [potential issue]? Is [potential issue] as hassle for you? Why? Have you sought a way to solve it? Why, why not? Could you imagine doing [process] another way? How? These can both be open questions, and more closed ones as you circle in on the pain points. And then if there is a problem, then have set of questions that are HYPOTHESIS-TESTING SOLUTIONS, and more directed towards testing whether your solution is the right one. Here you may present the user different approaches to solving the problem, explaining the user the future to-be with your solution. Think of questions like: Do you imagine doing it this way? Do you think it is a better solution? What do you see of potential issues? What is the maximum you would be willing to pay for it, if any? The latter part should be aided with mock-ups or process-mapping to help the user visualize the solution, and give higher-quality feedback back to you. Hope that helps :)