Do You Need a Functional Product or MVP Before You Can Start Selling the Value Your Product Promises?Founders often invest months proving that their product works before finding out whether anyone is willing to buy what it delivers.
A founder has an idea, identifies a problem, and begins building a solution. The initial focus is on getting the product right. Features are developed, workflows are refined, integrations are completed, and the user experience is improved. The assumption is often that once the product is sufficiently complete, it can be taken to the market and validated with customers. It sounds logical. After all, how can customers properly evaluate something that does not yet exist? But there is another question worth asking: What exactly are you trying to validate by completing the product? Are you trying to establish that the technology works? That customers find it useful? That they will pay for it? Or that the business can consistently make money by delivering the value it promises? These are different questions. And they do not necessarily require the same level of product readiness. A product that works is not necessarily a business that worksProduct validation and business validation are closely related, but they answer different questions. Product validation examines whether the solution performs as intended. Can users complete the tasks it was designed for? Does it solve the functional problem? Is the experience reliable and usable? Business validation examines whether there is a viable commercial proposition behind that solution. Is the problem important enough for customers to act? Does the proposed value matter to them? Will they pay for it? Can the business deliver that value and capture enough of it to operate sustainably? A product can pass its functional tests and still struggle to attract paying customers. Customers may appreciate its features, find the experience convenient, and even use it during a pilot. But that does not automatically mean they consider it important enough to purchase. Equally, a customer may be willing to pay for a particular outcome even when the technology intended to deliver it is not fully developed. This is an important distinction.
Let the uncertainty determine what you buildBefore deciding how much of the product needs to be built, founders should identify what they actually need to learn. Consider some of the questions a new business might face:
Each question requires different evidence. Customer conversations may help establish whether the problem exists and how people currently deal with it. A concept demonstration or prototype may help determine whether the proposed solution makes sense to prospective users. Testing actual workflows may require a functional MVP. Technical reliability, safety, regulatory, or operational assumptions may require a much more developed product. There is no universal rule that says a founder must build a particular percentage of the product before starting validation.
The question you need to answer should determine what you need to build, not simply what remains unfinished on your product roadmap. Understanding willingness to pay is not the same as sellingFounders often use different forms of market evidence interchangeably. There are at least three ways to assess whether customers are likely to pay for a solution. Each tells us something useful, but they represent different levels of commercial commitment. 1. Asking customers whether they would pay Through interviews, surveys, and conversations, founders can explore whether customers experience the problem, how they currently solve it, what the problem costs them, and what they might consider a reasonable price for a better solution. These conversations are valuable. They help uncover customer priorities, existing frustrations, perceived value, and potential objections.
A customer may genuinely like an idea and express a willingness to purchase. Yet when faced with a real price, a budget decision, competing priorities, or the effort involved in adopting something new, that interest may not translate into a transaction. This is evidence of stated intent, not demonstrated buying behaviour. 2. Looking at customers who already buy similar products Another way to assess demand is to examine what customers are already purchasing. They may be paying for competing products, alternative solutions, or even manual services to address the same problem. This tells us something important: customers recognise the problem and are already allocating money to solve it. There may be an opportunity to offer something better, faster, more convenient or more economical.
The competing product may serve a different customer segment, address a slightly different need, or benefit from an established brand and distribution network. It is evidence that a market exists, not proof that customers will buy your solution. 3. Actually selling the value you promise This is where the nature of validation changes. The founder identifies a prospective customer with a real problem, presents a specific value proposition, agrees on the outcome, price, and scope, and secures a paid engagement. The customer is no longer simply expressing interest in a possible solution.
There is a meaningful difference between a customer saying they would pay, a market showing that people already pay for similar solutions, and a customer actually paying you to deliver the outcome you promise. All three provide useful evidence. But they are not interchangeable. Can you sell the outcome before the product is fully built?This brings us to an interesting possibility that many founders overlook. Selling the value your product promises does not necessarily mean selling access to a finished product. Depending on the nature of the solution, the promised outcome may initially be delivered through a semi-functional MVP, existing tools combined with limited software, manual processes supported by technology, or a founder-led and service-assisted delivery model. For example, a founder developing a solution to automate a business workflow may initially deliver parts of that workflow manually, using existing tools and a limited version of the product. The customer is paying for the agreed outcome, not necessarily for a fully automated system. This can be structured as a paid pilot or an initial commercial engagement, with a clearly defined scope, price, expected outcome, and measures of success. It allows the founder to test whether a specific customer considers the proposed value worth paying for, while also learning what is required to deliver it. The distinction is important:
Of course, this approach is not as simple for every product or industry. Some solutions have technical, safety, regulatory, or operational requirements that make the approaches to this path more complex. The promise must also be realistic, and the founder must be capable of delivering what has been agreed. But at the core of starting a new business, waiting to complete a functioning product may not be necessary to test the commercial proposition. What does a paid engagement actually prove?A customer paying for a pilot even without a functional product is meaningful evidence. It suggests that the problem is important enough for that customer to spend money on, that the proposed outcome has commercial appeal, and that the customer is willing to commit under specific conditions. It may also provide early evidence that the promised value can be delivered, at least in a limited setting. But one paid engagement does not establish that the business model works at scale. It does not prove that demand will repeat across multiple customers, that the product will be reliable at higher volumes, that customers will continue using it, or that acquisition and delivery costs will support a sustainable business. These are questions that require further validation.
What happens during and after that engagement determines what needs to be learned next. Rethinking the next development milestoneBefore committing to another major development milestone, founders could pause and ask three questions:
Sometimes the answer will be to develop additional functionality. Sometimes it will be to put a prototype in front of customers. And in other cases, it may be to secure a paid engagement and deliver the outcome using a combination of existing tools, manual effort, and a limited product. The objective is not to postpone product development or avoid building a complete solution.
A finished product tells you how far you have progressed in building the solution. A paying customer starts telling you whether the value behind that solution is worth buying. Founders need both forms of evidence. The important thing is not to wait for the first before seeking the second.
|
