Trying to get validation on a product before it’s built is a classic chicken-and-egg scenario. Customers want the product to be finalized before using it, but you need validation that they will purchase it or commit to a partnership before you invest the time to build it.

Many founders get stuck here, feeling the need to build a fully functioning product before signing a single customer. However, staying in the validation phase before writing a line of code can ensure you deepen your understanding of the customer and that your initial product hits the mark in solving their pain points.

So, how do you sell something that doesn’t exist?

In many cases, your MVP can be much less than a fully built product, and you can get the paid validation you need without writing a single line of code. Customers don’t care about the product itself; they care about getting their problem solved.

With this in mind, when speaking to customers, consider whether the problem requires an immediate software solution, or if you could manually take over a painful process for the customer that you will later automate. Can the customer bring you on as a consultant to solve the problem, understanding that you are building a software solution to address it down the road? Can you use existing tools to patch together a solution for their current problem? Can you create mockups of what the product will look like and get them to pre-commit to purchasing it when it’s built?

Not being tied to a product that’s already developed allows you to be more nimble in your feedback and iteration. If you are simply editing mock-ups or changing no-code solutions versus pushing full product changes, the feedback you get from customers will be much richer.

So what does this look like with a customer?

You still need to start by quantifying the pain point. Before you pitch any solution, you should know from your prospect how much the pain costs them in hours, time, or lost revenue. This will help you frame your solution.

Then, instead of going straight into a product pitch, stay with their problem. Ask, "If I was able to solve this pain point, what would that mean for you? What else would you be spending your time on?"

Next, present the solution, focusing not on the features and what the product will do, but on how you can solve their pain point. For example, let’s say you have a software tool that analyzes data to find hidden sources of correlation. Your product is not built yet, but you know that using the framework of the tool you want to build, you can manually take over the process for the customer and solve their pain point. Pitch them on that. This will help you validate that the pain point is significant enough to pay for and gain valuable insights into the process from your customer’s perspective.

By focusing on solving customer pain points rather than pushing product features, you can secure early validation and build stronger relationships with your customers. This approach not only reduces development risk but also ensures that your product, when built, truly addresses the needs of your market.

‍

If you found this helpful, consider sharing it with a fellow founder or sign up right here to get the next one directly in your inbox.

See you next time - happy building 💪

‍