How to Validate Product Market Fit Without Asking Users to Predict the Future

01

Product-market fit is behaviour, not a compliment

Imagine a team planning a software product for commercial maintenance companies. The idea is a customer portal where facilities coordinators report faults, attach photographs and track an engineer visit. Everybody shown the idea says it sounds useful. A few people even say they would definitely use it.

That is encouraging, but it is not product-market fit. People are often generous when an idea costs them nothing. They can like a prototype and still return to email the following morning. A manager can praise the product while the procurement process, budget or existing contract makes buying it unlikely.

User research is still one of the best ways to reduce that uncertainty. Its job is not to collect permission to build. It helps the team understand the problem, identify the people who feel it, expose the risky assumptions and design the next test.

Product-market fit becomes stronger evidence later, when a defined group repeatedly chooses the product, gets the promised value and provides a sustainable route to revenue. Interviews open that journey. They do not finish it.

02

Write down the assumptions before choosing a method

The first research task is not writing interview questions. It is listing what must be true for the product to work as a business.

For the maintenance portal, the team may assume that facilities coordinators regularly struggle to report faults, missing information causes expensive delays, maintenance companies want a customer-facing product, staff will change their current routine and an operations director has budget for the result.

Those are different assumptions. An interview can explore the current problem and buying process. Observation can expose missing information and workarounds. A prototype can test whether the proposed journey makes sense. A pilot can show whether people return and whether the business will pay.

Rank assumptions by damage and uncertainty. Test the belief that could make the whole product pointless before polishing a feature that only affects one screen.

03

Research the people who experience, support and buy the product

A business product often has several users. The facilities coordinator reports the fault. A call handler checks it. An engineer needs access details. A manager watches performance. An operations director may approve the purchase. Researching only one role creates a very tidy but incomplete picture.

Recruit people who have recently experienced the problem and represent the range the product intends to serve. Include people with access needs, lower digital confidence and awkward working conditions when they are part of the market. Friends who like the idea are not substitutes for people who live with the current process.

Keep the proposed segment narrow enough to learn from. A small maintenance provider with one dispatcher may have a different buying process and operating problem from a national contractor. If every participant comes from a different market, the findings can become interesting but impossible to act on.

04

Ask about the last real event

Questions about a hypothetical future invite hopeful answers. Ask what happened the last time instead.

A useful conversation might begin with: Tell me about the last fault you reported. How did you know who to contact? What information did they ask for? Where did the request slow down? What did you do next? Who else became involved? What happened when you needed an update?

Listen for behaviour, frequency and consequence. A problem that happened once and caused mild irritation is different from one that appears every week, delays an engineer and creates a contractual risk. Ask what the person already does to solve it and what that workaround costs in time, money or attention.

Do not pitch the portal halfway through the answer. The most valuable finding may be that the assumed problem is wrong. In our example, customers may not mind making a call. The damaging part may be missing site references, access details and reliable status updates after the call.

05

Observe the current work and use existing evidence

What people remember and what happens during a busy day are not always the same. Interviews become stronger when the team also observes the task and reviews evidence already produced by the operation.

Sit with a call handler while a fault arrives. Follow the request through the inbox, job system, engineer diary and customer update. Review support tickets, incomplete forms, call reasons, abandoned journeys, service reports and any spreadsheet used to repair the official process.

This can change the product boundary. The visible customer form may be a small part of the problem. The real opportunity might be structuring site data, carrying the same reference into the job system and giving staff one reliable status to communicate.

Research should cover the end-to-end service, including offline steps and support work. A product that makes the customer screen faster while moving more admin into the back office has not necessarily improved the outcome.

06

Turn findings into a testable problem statement

After several sessions, the team needs more than a wall of quotations. Look for repeated patterns in who experiences the problem, the situation that triggers it, the outcome they are trying to achieve, the current workaround and the consequence when it fails.

The original statement might have been: maintenance customers need a portal because they do not want to phone. The research may produce something more useful: facilities coordinators need a reliable way to send complete fault and site information because missing details delay attendance and make status updates hard to trust.

That statement does not prove a market exists. It gives the team a clearer problem, segment and outcome to test. Record contradictory evidence too. If some companies already solve the problem well with an existing platform, understand what makes the remaining segment different.

07

Use a prototype to test the riskiest interaction

A prototype helps when a conversation has reached the limit of what words can explain. It lets a participant attempt the proposed journey and gives the team behaviour to observe.

For the maintenance product, the prototype could cover one complete route: identify the site, describe the fault, attach evidence, confirm access information and see the first status update. It does not need billing, a polished dashboard and every future report.

Give the participant a realistic task and avoid teaching the interface. Watch where they hesitate, what they expect and whether the result matches the job they were trying to complete. Follow with questions about what they understood and what would stop the journey fitting their work.

A successful usability test shows that people can use the proposed approach. It does not show that enough companies will buy it. Usability, desirability and commercial viability need related but separate evidence.

08

Ask for a proportionate commitment

Polite interest becomes more useful when somebody chooses to give up something with value. The commitment should match the stage of the idea and remain honest about what exists.

A participant might introduce the team to the operations director, share anonymised examples, bring colleagues to a second session or agree to a structured pilot. A buyer might review a price range, explain the approval route or sign a non-binding letter describing the conditions of a pilot. A later test may ask for a paid trial or deposit where that is appropriate and clearly explained.

One commitment does not prove a market, and a refusal does not always reject the product. Timing, authority, procurement rules and risk can all affect the answer. The useful part is comparing what people do with what they previously said, then understanding the reason for the gap.

09

Define the evidence ladder before seeing the results

Teams can make almost any result sound positive after the test. Set the evidence needed for the next investment decision in advance.

An evidence ladder might move from repeated problem stories, to observed workarounds, to successful prototype use, to a pilot commitment, to repeated use, to willingness to pay and renewal. Each step answers a different question and costs more to test.

Define what would cause the team to continue, change the segment, alter the proposed solution or stop. The thresholds do not need fake precision, but they should prevent three enthusiastic interviews from quietly becoming approval for a six-month build.

Also record what the test cannot tell you. A prototype session cannot measure long-term retention. A waitlist does not prove active use. A pilot with a friendly existing customer may not reveal how difficult acquisition will be in the wider market.

10

Use a pilot to measure value in real work

A small pilot moves the product from stated intent into real behaviour. Give a narrow group enough of the product to complete the valuable task, then measure whether it becomes part of their normal work.

For the maintenance portal, useful evidence might include whether customers submit complete reports, whether staff need to re-key information, whether people return for the next fault, whether status checks move away from calls and whether the buyer still values the result after the novelty has worn off.

Choose a value event that reflects the product promise. Sign-ups and page views are easy to count but weak if the promise is faster, more complete fault handling. Retention must also match the expected frequency. A product used only when equipment fails should not be judged by daily activity.

Product-market fit is rarely one magic percentage. Look for a pattern where the intended segment repeatedly reaches value, misses the product when it is unavailable and supports a credible way to acquire and serve more customers.

11

Do not let one customer become the whole market

A pilot customer will teach the team a great deal, but their requests can pull the product towards a bespoke system. Every new feature may be valuable to that customer and irrelevant to the next ten buyers.

Separate repeated market needs from account-specific configuration. When a request appears, ask whether the same problem has been observed across the chosen segment, whether it strengthens the core value and whether the product can support it without becoming a collection of exceptions.

The honest outcome may be that the opportunity is better as bespoke software for one operation rather than a repeatable product. That is not failed research. It is a commercial decision discovered before the business builds a product model around the wrong shape of demand.

12

Make research part of the investment rhythm

User research should change the next decision. At the end of each round, state what the team learned, what remains uncertain, which assumption changed and what evidence the next test must produce.

The maintenance product might continue with a narrower segment and a smaller workflow. It might change from a customer portal to a structured intake service that integrates with existing job systems. It might stop because the pain is real but buyers will not replace their current supplier. Each can be a responsible result.

After launch, combine ongoing conversations with support themes, product analytics, retention, sales objections and reasons for cancellation. The market, buying process and user expectations will move. Research keeps the product connected to that change.

User interviews do not hand over a certificate marked product-market fit. They give the business a disciplined way to replace assumptions with evidence, one investment decision at a time. If you are deciding whether a software idea deserves a prototype, pilot or full build, I can help structure the discovery and make the next test visible.