Tactics to Validate Product-Market Fit

Product – market fit concept origin and definition 

The term “Product-Market Fit” was coined by Marc Andreessen and simply means establishing that a product has strong demand in a market. While the concept is simple, the process of determining if a product has product-market fit is challenging and risky. The challenge lies in the difficulty of determining if a market will buy a product before the product is built. And the risk lies in the product manager’s inherent desire for the product to succeed, which leads to frequent false positives and subsequent wasted investment in product development. ​

The three most common ways that entrepreneurs and intrapreneurs can establish product market fit are: Proof of Concept (PoC), Prototype, and Minimum Viable Product (MVP). Other related concepts include Proof of Value (PoV), Pilot, Alpha, and Beta. Each of the approaches is used at a different stage of product maturity to justify the investment needed to reach the next stage of maturity.​

The purpose of this article is to reduce confusion about which approach to use based on your validation goals and stage of product development. First, let’s define the concepts. ​

How do you validate product-market fit?

Proof of Concept (PoC)

A PoC is used to validate the technical and functional feasibility of key components of the product. This stage should be implemented before the product development process starts. The goal is the establish that the product can indeed be built, and that it will solve the stated problem for the target customer group. A PoC is usually not shown to the public because it is not yet a functional product. Rather, it is tested internally or with a small number of sympathetic customers. 

A PoC answers questions such as:

  • Will the product meet the needs of target customers?
  • Will the core technology perform as we expect?
  • Will the users accept changes to processes or user interfaces that the product requires?

Proof of Value (PoV)

Unlike the PoC, a PoV approach focuses on what that solution means from a business perspective. The goal is to better understand the anticipated value the product will bring to your customers and to your business so you can justify development and measure success. A PoV is more likely to be useful in a B2B scenario where the product’s success in the market is dependent upon acceptance from multiple stakeholders and where sales must prove a strong business case. 

A PoV answers questions such as:

  • In what specific ways will product adoption benefit customers?
  • What is the expected ROI of adoption, and how will our customers measure it?
  • Are there any stakeholders in the buying process that will reject the product? How can we address their concerns?

Prototype (Alpha & Beta)

Prototypes show how a completed product looks and works before the components are entirely functional. For example, a software prototype may be an interactive wireframe will show how an app flows from screen to screen. And a hardware prototype may be built from off-the-shelf components to demonstrate how they integrate. In both cases, prototypes are used to obtain early feedback on a product and to identify potential  challenges in design and development.

The Alpha prototype is the first attempt to design and fabricate the product to meet the product requirements specifications. It should look and work like the final product. The Beta prototype is the first version which represents the design and materials of the final product. It should be close enough to the final product that regulatory and user testing can be done with little risk that there will be changes when the product is released to market.

A prototype answers questions such as:

  • Do users understand how to use the product? Does it meet their expectations?
  • Where are the most likely failure factors?   
  • How do alternative designs or technical architectures compare to each other? 

Minimum Viable Product (MVP)

An MVP is used when you want to check market demand and analyze the preferences of target customers before investing significantly in the ideal product. This is done by releasing the product in a short time with minimal features. The MVP is market-ready but basic. As famously put by LinkedIn founder Reid Hoffman, “If you are not embarrassed by the first version of your product, you’ve launched too late.” 

Many corporates are not comfortable launching MVPs due to the potential brand risk. This can be overcome by launching to a small market, launching under a shadow brand, or by clearly communicating to first customers that this is an MVP and will be flawed. 

An MVP answers questions such as:

  • How strong is actual demand for the product? 
  • What features do customers use or ignore?
  • Do customers use the product in the way you imagined, or is there unexpected user behavior?


The intent of a pilot is to measure the real benefits of implementing the product or solution in an operational environment. A pilot project is used exclusively for complex solutions in a B2B environment. Ideally there is an understanding that the customer will purchase the solution if the pilot is successful. Pilots may last for weeks or months, and data collected during the pilot can be used to support solution customization.

Since pilots typically require support from the vendor to deploy the solution, the customer will often make a limited purchase to cover vendor expenses. However, vendors may offer a free pilot if the solution maturity is low or if they are very confident that it will convert into a large-scale deployment. 

A pilot answers questions such as:

  • How does the solution architectural need to be structured for this customer?
  • Does the solution provide the expected value to the end users? 
  • What is the expected ROI of the full-scale deployment?

Common Questions & Answers

Q: When should you build a prototype? 

  • When you want to visualize how the product will function. 
  • When you have limited money and time but want to demo the solution.
  • When there is limited technical availability. 

Q: When should you build a PoC or PoV? 

  • When you need to convince investors or decision makers to finance development.
  • When you have to validate that the technical elements work. 
  • When you want to assess the likelihood of market success before product development. 

Q: When should you build an MVP? 

  • When you need to test the value of the core features. 
  • When you have to show investors that customers will pay for the product to finance further development. 
  • When you want practical customer feedback to guide feature development. 

Q: What is the difference between Prototype and MVP?

  • An MVP is ready to sell to early adopters while a prototype is used to test the idea with the internal stakeholders or a customer focus group.

Q: What is the difference between a Prototype and a Proof of

  • A PoC is a highly incomplete solution that is used to check the feasibility of key functions and technologies. A prototype is a rough mockup of the entire solution that gives stakeholders a perspective into how customers would use the final product. 

How do you validate product-market fit?

Key Takeaways

New product development is like experimenting with a target vision. It requires commitment, accountability, awareness, and  understanding how you need to proceed with the process. The process starts with a foundation, i.e., creating the POC, the prototype, followed by the MVP.

Verifying the feasibility of an idea with a POC can contribute in gaining support and investment, and ensure that organizations are not just spinning wheels and wasting resources. Prototypes help to refine ideas, facilitate communication among stakeholders, and get first hand feedback. MVP is the start of the product’s life outside the development nest — applying a validated learning will let your project mature to product - market fit.

Use metrics to measure the product’ progress, but don’t focus solely on product market fit label. Instead, focus on consistently improving the solution, and getting more users to pay for it.

Related Insights.

Contact us

Let's talk!
* Required
* Required
* Required
* Invalid email address
By submitting this form, you agree that IoT ONE may contact you with insights and marketing messaging.
No thanks, I don't want to receive any marketing emails from IoT ONE.

Thank you for your message!
We will contact you soon.