What to Learn First When Product-Market Fit Is Unclear

0:00Start With the People Who Stayed

If your product is live but product-market fit still feels slippery, where do you look first? At the people already using it? Or out at the larger market, trying to understand who might want it?

Jonathan Markwell’s team had paying customers. But the product was still hard to sell, hard to onboard, and hard to use. People bought it, then sometimes didn’t use it. So the team interviewed the actual end users. That changed the shape of the product. The customers valued one report more than the CRM workflow required to produce it. As Markwell puts it, “all they wanted was the report.” The team pulled that feature out and turned it into a simpler self-service product. He describes it as “highly profitable, easy to sell.”

What strikes me here is that the most valuable discovery wasn’t a new audience. It was a narrower job hiding inside the product you already had. That’s something a broader market scan can easily miss. People may describe a category or a problem in general terms. Your own users can show you which part they actually make time for, which output they return to, and which layer they’re willing to tolerate to get there.

Noah Greenberg took a similarly focused approach with early customers. He brought on about 50 customers, then studied the 15 who stayed. In his words, the goal was to “figure out what makes them who they are and why they renewed.” He also kept the conversation going. In the early stages, he says, “you’re having 50 conversations a month.” Those conversations helped him refine the product, pricing, packaging, and positioning. The business eventually reached about $300,000 in monthly recurring revenue, or roughly $3.5 to $4 million a year. It reached a million dollars in annual recurring revenue in its first year, then tripled the year after.

I don’t read that as a rule that every small product should interview dozens of customers. I read it as a rule about selection. A signup tells you someone was curious. A repeated core action, a renewal, or a payment tells you someone found enough value to come back. Those people can help you see the difference between a feature that attracts attention and a problem that earns commitment. If I were in your shoes, I’d start by finding the people who crossed that line. Then I’d ask what they were trying to accomplish before they opened the product, what they do inside it, and what would break if it disappeared.

Shruti Kapoor’s team learned why this distinction matters when it watched early customers use the product. These customers came through the founders’ network, so they were friendly and willing to help. But they weren’t using the product in the way the team expected. Kapoor says, “even with these friendly customers early on, they were not using the product the way we would expect them to.” The team observed their workflows and kept changing the product. The goal was to find the first valuable moment, then make it repeatable. That work revealed a less obvious problem with a real-time feedback feature. The obstacle wasn’t necessarily that customers disliked the idea. It was the implementation cost and the time required before they could get value. Kapoor says the team hadn’t accounted for “how the customer is thinking about it in terms of their implementation cost or effort required to get value out of it.”

This is why a discovery call should be tied to behavior. Don’t begin with, “Would you use this?” Begin with, “Show me what you did last time.” Watch the handoffs. Notice the workaround. Ask what happened before the product, what happened after it, and where the process stalled. A user may say the feature is valuable while quietly abandoning it because setup takes too long. The interview explains the behavior. The behavior keeps the interview honest.

So the first internal analysis shouldn’t be a count of logins. Olga Berezovsky recommends defining activity around the product’s main action: “I’d recommend using the main user action as the activity event.” Retention should then be examined by signup cohort, rather than as one blended number. And free users and paying customers should be separated, because, as Brian Balfour puts it, “Your retention will have a different logic for each of these groups.”

In practical terms, the question is not, “How many users do we have?” It’s, “How many people repeatedly complete the job this product is meant to do?” During the next two weeks, that means reconstructing the internal picture. Count total users. Mark active users by the core action. Look at retention by cohort. Separate paying accounts from free accounts. Then check whether the strongest behavior is concentrated in one segment, one workflow, or one use case. If a small group keeps doing the same valuable thing, start there. If the users are scattered, inactive, or only passing through, their behavior may tell you less. The people who stayed can reveal the job. But first, you have to define what staying, and what value, actually looks like.

5:49The Market Can Point You Toward a Hypothesis

The broader-market camp has a strong argument. When the user base is tiny, the people inside it can tell you a lot about one corner of the problem. They may not tell you whether that corner is big enough, urgent enough, or reachable enough to build a company around.

Mikita Mikado took that outside-in approach before building PandaDoc. He spoke with people who had used his previous product, and with people who had looked at it but decided not to buy. Then he built a pipeline of roughly 60 to 90 accounts. The conversations were not just research. He was trying to get feedback and sign annual contracts on the condition that the product would be built. As he puts it, “during those conversations we harvested a ton of insights and feedback and ideas and so forth.”

What I like here is the progression. Start with people who recognize the problem. Learn what they are trying to accomplish. Then ask for a commercial commitment before spending months building. That is much stronger than collecting compliments from a community thread. It turns market research into a list of specific people who might use the thing.

There are quieter ways to do the same kind of work. Look for spreadsheets and Google Docs that people have built to manage a recurring, painful problem. Look for people searching for alternatives to an existing product. Those clues can reveal a problem that people are actively trying to solve, and may point to an existing budget. Talking with users of competing products can reveal the challenges they face and whether those challenges come from the product or from mismatched expectations. Community discussions can help you understand how prospective customers currently work and where a proposed solution might clash with their reality.

That is useful information. But each clue answers a different question, and none of them, by itself, shows that someone will switch, keep using a new product, or pay for it. They are signals to investigate, not proof of adoption or retention.

The difference becomes clearer when teams move from research into a sales conversation.

Shruti Kapoor’s team had a sales consultant arrange 40 meetings with companies that fit its intended customer profile. The result was not a promising funnel. It was zero sales. “He set up 40 meetings with our ICP companies and we sold exactly zero to those 40 customers.” The effort showed that the team could arrange conversations with companies in its intended profile, but it did not produce a purchase.

The same team then spoke with people using competing products. That surfaced a more useful question: were the problems caused by the product itself, or by setting the wrong expectations? Competitor research can therefore examine the challenges people face with the products they already use, rather than simply asking whether they like the category.

There is a sharper warning in Justin Kan’s story about Atrium. The company got in touch with many customers through partnerships and investor channels. But that contact did not rescue the product. Churn stayed high because the product did not provide enough utility to make people stick around. Distribution created conversations. It did not create lasting value.

So a large audience can mislead you in two ways. It can make a weak product look promising because many people are reachable. Or it can make a narrow niche look like the whole market because that niche is unusually vocal. The correction is simple, though not easy: every market signal needs a next step where a specific person uses the product or pays for it.

April Dunford saw a different version of the same trap. A product was treated as a kind of desktop productivity software. Some people bought it, but almost nobody used it. “We thought it was was like a souped-up spreadsheet. ... and it failed. Like some people bought it, but nobody really used it.” The eventual answer was not just a new slogan. The team repositioned it as an embeddable database for mobile devices, aimed at a different market. That changed the sales model, the pricing, and the roadmap. They had to build the capabilities to support the new use case.

This is why I would treat purchases as evidence of interest, not the finish line. The more revealing question is what happens after the transaction. Does the customer complete the core job? Does the job recur? Does the customer renew, expand, or bring someone else in? If not, the market may be signaling that the category is interesting while rejecting the product’s actual use.

10:59A Two-Week Choice: Measure, Then Test

So the choice isn’t really users or the market. It’s the fastest way to answer the biggest unknown. First, find out whether the product already has a meaningful pocket of repeat behavior.

Start with measurement. Define an active user by completing the product’s main action, not by logging in, opening the app, or viewing a page. Olga Berezovsky argues that this gives you “the cleanest sample of truly active users.” Then look at free users separately from paying customers, because retention has a different meaning for each group.

At the end of day three, use behavior rather than raw user count as your guide. Look for a cohort that comes back and a workflow that repeats. A concentrated pattern gives you a clearer basis for the next test than scattered signups or one-off usage.

That classification gives you the first branch in the plan.

For the two-week test, choose five to eight people from that retained or paying cohort. Include a couple of users who stopped, if you can reach them. Watch them complete the core workflow. Ask what they were trying to get done, what they used before, what nearly stopped them, and what would happen if your product disappeared. Don’t ask whether they like the idea. Look for the job they repeat and the friction they tolerate.

Make one small change during the second week. It might simplify onboarding, remove a step, or make the valuable action easier to reach. Continue down this path only if the change produces repeated use, stronger retention, a referral, or another payment. A good conversation explains behavior. A changed behavior tells you whether the explanation was useful.

Now take the other branch.

If the user base is tiny, scattered, or mostly inactive, keep the market research narrow. Pick one proposed segment. Study the alternatives those people already use, and read community discussions where they describe the problem. Then speak with people who currently use a workaround, focusing on the context they are in now rather than asking them to predict the future.

For a two-week market test, choose one segment, map the competing solutions, and run a concrete use-or-payment test. Ask each person to show the current workaround, then offer the smallest version of your product that could replace one step. Set a threshold before you start, and treat actual use, payment, a dated trial, or a clear switch from the existing alternative as stronger evidence than positive comments alone.

Broader research can help reveal people’s language, current alternatives, workarounds, and possible budget signals. Existing-user analysis can help reveal repeated behavior and how different groups retain. Use the two tracks to answer different questions about adoption, payment, and whether the pattern can extend to more people.

What if both sides look weak after the first few days?

Run both tracks in parallel, but make them answer different questions. Internally, recruit and observe the few users who show any repeat behavior. Externally, study one segment and test one workaround. Don’t average the results together. Narrow the product around the strongest repeated job, then test actual use, payment, and whether the pattern can be repeated with more people.

That sequence reflects the practical distinction made by one SaaS team: first ask whether people will use the product, then whether they will pay, and finally whether enough people will use and pay for it to scale. Luc Levesque makes the same point from the growth side: “make sure you have a product that users love” before putting more people into the funnel.

A practical decision rule is to start with user analysis when repeated use or payment is concentrated in a cohort. If behavior is limited, start with one-segment market research and a concrete use-or-payment test. If the evidence is mixed, run both briefly and follow actual behavior rather than enthusiasm. At the end of two weeks, use what you observed to choose the next customer, job, and test to investigate.