What User Behaviour Suggests You Have Product-Market Fit?

Most founders wait for a chart to tell them if the product has found its market. That chart takes weeks to become trustworthy, and by the time it does, the honest answer was already visible in how a handful of people were actually using the product — not in what they said about it, and not in a percentage on a dashboard.

Behaviour is harder to fake than an opinion. A user who tells you the product is “great” has spent nothing to say so. A user who spends twenty minutes configuring a settings page, or explains your product to a colleague without being asked, has spent real effort — and people don’t spend effort on things they don’t expect to keep using. This post is a field guide to that second kind of evidence: the specific, observable patterns in how people behave that suggest product-market fit, independent of whether you have enough users yet for the numbers to mean anything.

If you haven’t yet looked at the metrics side of this question, Early Product-Market Fit Signals covers the quantitative-adjacent version — unprompted return visits, referral patterns, and what to watch for in the first weeks after launch. This post goes narrower: the qualitative behaviour patterns themselves, the kind you’d notice in a support inbox or a session recording before they ever show up as a metric.

Why Behaviour Beats Opinion

Ask someone what they think of your product and you’ll usually get a polite answer. Watch what they do with it and you get something closer to the truth, because behaviour carries a cost that opinion doesn’t.

This isn’t a new idea — it’s the same logic behind why Y Combinator’s Startup Library repeatedly tells founders to talk to users and watch what they actually do, not just what they say they’d do. The gap between stated intent and real behaviour is one of the most common ways early founders talk themselves into a false positive.

The behaviours below are grouped by what they cost the user to produce — time, effort, or emotional investment — because that cost is exactly what makes them trustworthy.

Behaviour 1: Users Build Workarounds Instead of Leaving

When a feature is missing or something breaks, there are two ways a user can respond: quietly stop using the product, or find a way around the gap so they can keep using it.

Watch for people who:

• Export your data into a spreadsheet to do something your product doesn’t support yet.
• Chain your tool together with two or three others to complete a task you haven’t built for.
• Keep a manual checklist alongside the product to cover a step it doesn’t automate.

A workaround is an investment. Nobody builds a spreadsheet bridge for a product they’re about to abandon — they just leave. If you’re seeing users engineer their own patches around your gaps, that’s a strong vote that the core of what you built is worth the extra effort.

Behaviour 2: Users Teach Other People How to Use It

Unprompted teaching is one of the clearest behavioural signals available, and it’s easy to miss because it usually happens outside your product entirely — in a Slack message, a screen-share, or a hallway conversation you never see.

Look for signs like a user forwarding a saved link with their own instructions attached, or a support ticket that opens with “my colleague showed me this and I can’t get the same result.” Each one implies the first user cared enough to walk someone else through it without being asked, and thought the product was worth spreading.

This is also why word-of-mouth growth without a formal referral program is worth paying close attention to — see Product-Market Fit vs Early Traction: What’s the Difference for how to tell durable word of mouth apart from a short-lived spike.

Behaviour 3: Frustration Shows Up Fast During an Outage

Downtime is an uncomfortable but genuinely useful test. If your product goes down and nobody notices for a day, that tells you something. If someone emails within the hour asking when it’ll be back, that tells you something very different.

The signal isn’t the complaint itself — it’s the framing. Compare these two reactions:

Reaction during downtime	What it usually means
“When will this be back? I need to finish something.”	The product is part of an active workflow they rely on.
“No worries, let me know when it’s sorted.”	Mild interest, low urgency, replaceable.
Silence, then a cancellation later	The product wasn’t load-bearing in their day.
A support ticket with screenshots and specific error details	High engagement — they were actively trying to work around it before reaching out.

Urgent, specific frustration is a cost the user pays because the outage is actively blocking something they wanted to do. That’s a much stronger signal than a generic compliment ever is.

Behaviour 4: Deep, Unprompted Customization

Users who go beyond the default setup — renaming fields, building custom views, setting up notification rules you didn’t advertise — are telling you the product has earned a place in their routine specific enough to be worth tailoring.

This matters more for products with any configurability at all: dashboards, project tools, CRMs, internal admin panels. A user who spends an hour on day three setting preferences most people never touch isn’t casually trying the product — they’re settling in. If you’re building this kind of configurable product, MVP Metrics for Product-Market Fit: A Founder Scorecard has a useful companion framework for turning usage patterns like this into something you can track over time once volume allows it.

Behaviour 5: Feature Requests That Extend, Not Replace

Not all feature requests carry the same weight. The distinction that matters is whether someone is asking you to do more of what you already do, or asking you to become a different product entirely.

• Extending requests — “can this export to CSV,” “can it notify me on Slack too,” “can I add a second team member” — assume the core workflow is already working and the user wants to push further into it.
• Replacing requests — “can you also do invoicing,” “can this become a full CRM” — often signal the core alone isn’t enough to hold the user, and they’re hoping the product grows into something else to justify staying.

A stream of extending requests from active users is a genuinely encouraging sign. A pattern of replacing requests is worth investigating before you read it as enthusiasm — it can just as easily mean the core hasn’t landed. Can You Have Users Without Product-Market Fit? digs into this exact trap, where usage and requests keep coming in but none of it reflects real reliance on what you actually built.

Reading These Behaviours Together

No single behaviour on this list proves product-market fit on its own, and you shouldn’t treat one enthusiastic workaround or one fast support ticket as the whole answer. What matters is whether these patterns show up together, and whether they come from more than one person independently.

A useful habit: keep a running note — not a dashboard, just a document — every time you notice one of these five behaviours in a support ticket, a call, or a session recording. After a few weeks, patterns tend to become obvious even with a small number of users, well before they’d be measurable in the traditional retention-and-revenue sense.

If instead you’re seeing the opposite — quiet churn, generic praise with no follow-through, requests to become something else entirely — treat that as useful information too. It usually means the problem or the audience needs another look before more building happens.

Turn What You’re Observing Into a Clear Next Step

Behaviour like this is easy to notice and easy to lose track of if it’s scattered across support tickets, calls, and half-remembered conversations. The founders who act on it fastest are the ones who write it down consistently and revisit it as a group, not as isolated anecdotes.

If you’re seeing these patterns and want help turning that evidence into a clear MVP roadmap — or you’re not sure whether what you’re observing is a real signal or wishful thinking — a second opinion from a team that’s seen this pattern across many early-stage products can save months of guessing.

Frequently Asked Questions

What user behaviour is the strongest sign of product-market fit?

Users building workarounds to keep using your product when something is missing or broken is one of the strongest signals. It means they have already decided the product is worth the effort of adapting to its gaps, rather than switching to an alternative.

Can I trust behaviour over survey answers when checking for product-market fit?

Behaviour is generally more reliable than stated opinions because it carries a cost. A user who spends time customizing a settings page or teaching a colleague how to use your product is spending real effort, while a survey answer costs nothing to give and is often shaped by politeness.

How do I actually observe these behaviours if I don't have much usage data yet?

Watch session recordings, read support tickets and in-app messages closely, and talk directly to your first handful of active users. With a small user base, a few detailed conversations reveal more than an analytics dashboard that doesn't yet have enough volume to be reliable.

Is user frustration during an outage really a positive signal?

Yes, within reason. Frustration that arrives quickly and is framed around wanting the product back, rather than simply asking for a refund or vanishing quietly, tells you the product has become part of someone's routine. Silence during downtime is usually the more worrying outcome.

What is the difference between this and tracking product-market fit metrics?

Metrics like retention curves or a Sean Ellis survey score summarize behaviour into numbers, and they need a meaningful sample size to be trustworthy. Watching behaviour directly works even with a handful of users, and it often surfaces the story behind a metric before the metric itself is statistically solid.

Should feature requests always be treated as a good sign?

Only certain kinds. Requests that extend how someone already uses the product, such as asking for an export option or an integration with a tool they use daily, suggest genuine reliance. Requests that ask you to become an entirely different product are a weaker signal and sometimes point to a mismatch.