Skip to content
HomeWorkProcessAboutBlogContact[email protected]
← Back to blog

How to Find Product-Market Fit for Software Products

How to Find Product-Market Fit for Software Products. product-market fit Insights from The Proper Motion Company.

Product-market fit is the most overused and least understood concept in startup vocabulary. Everyone agrees it matters. Almost nobody can define it precisely enough to measure it. Marc Andreessen’s original description — “being in a good market with a product that can satisfy that market” — is directionally right but operationally useless. You cannot build a roadmap around a feeling.

The practical reality of finding product-market fit is messier, more iterative, and more data-dependent than the mythology suggests. It is not a single moment of revelation. It is a series of small signals that accumulate until you realize that something is working, and then a period of intense focus to amplify whatever that something is.

Signals That Are Stronger Than Survey Responses

The most cited PMF measurement is Sean Ellis’s survey question: “How would you feel if you could no longer use this product?” If 40% or more of respondents say “very disappointed,” you have product-market fit. This metric is useful as a trailing indicator but terrible as a leading one. By the time you have enough users to run a statistically meaningful survey, you have already spent months building. You need earlier signals.

Organic word of mouth is the strongest early signal. If users are telling other people about your product without being prompted — sharing it on social media, mentioning it in Slack communities, recommending it in conversations — something is resonating. You cannot fake this. Referral programs can amplify it, but if the underlying behavior does not exist, no incentive structure will create it.

Retention curves tell you more than acquisition metrics. A product with high signup rates and a flat retention curve has a marketing problem to celebrate and a product to fix. A product with modest signups but a retention curve that flattens above zero — meaning some percentage of users stick around indefinitely — has something worth building on. Pull your retention data by weekly cohort: what percentage of users who signed up in week 1 are still active in week 4, week 8, week 12? If that curve flattens (rather than declining to zero), you have a cohort that finds genuine value. Understand who those users are, what they are using, and why they stay.

Usage depth within retained users matters. A user who logs in daily but only uses one feature is less engaged than a user who logs in three times a week but uses four features. Track feature adoption breadth (what percentage of key features does each user engage with) alongside frequency. When you find users who adopt multiple features and use them consistently, interview them. Their use case is your product-market fit signal.

Revenue willingness is another hard signal. If people pay you money — especially without being asked, as in “can I pay for this?” — that is unmistakable. If you are pre-revenue, ask users in interviews whether they would pay, and watch their face more than their words. A genuine “yes” sounds different from a polite one. Better yet, put up a pricing page before the product is built and see if anyone enters their credit card information.

Related: Why Speed Beats Scale in Early-Stage Software

Running Experiments That Actually Resolve Uncertainty

The biggest waste in pre-PMF companies is building features that do not test a hypothesis. Every feature you build should be explicitly tied to a belief about what will drive retention, conversion, or expansion. If you cannot state the hypothesis, do not build the feature.

The experiment format is: “We believe that [user segment] has [problem]. If we build [feature], we expect to see [measurable outcome] within [timeframe].” The measurable outcome is critical. “Users will like it” is not measurable. “Retention at day 7 will increase from 22% to 30% among users who engage with this feature” is measurable.

The cheapest experiments test demand before building supply. A landing page describing a feature that does not exist yet, with a “notify me when this is available” button, tells you whether users want it. A concierge MVP — where you manually perform the service your software will eventually automate — tests whether the value proposition resonates before you write code. A Wizard of Oz prototype — where the user interacts with what appears to be an automated system but is actually a human behind the scenes — tests the UX assumptions without the engineering investment.

When you do build, build the minimum version that can test the hypothesis. This is not about shipping ugly software — it is about limiting the scope to the smallest feature surface that answers the question. If you are testing whether users want automated reporting, ship a single report type with a single delivery schedule. If engagement is strong, expand. If it is not, you have spent two weeks instead of two months learning something valuable.

Time-box every experiment. If you cannot detect a signal within 4-6 weeks, either the experiment is too small (not enough users to generate statistical significance), the metric is wrong (you are measuring the wrong outcome), or the hypothesis is wrong. All three are useful findings.

Identifying Your Beachhead Market

Trying to serve everyone is the surest way to find product-market fit with no one. The strongest PMF signals come from a specific segment — a beachhead market — where your product solves a problem that is urgent, specific, and underserved by existing solutions.

The characteristics of a good beachhead market: the problem is painful enough that people are actively searching for solutions (or actively cobbling together workarounds using spreadsheets, email, and manual processes). The segment is identifiable — you can describe who they are and find them in specific places (communities, publications, events, job titles). The segment is small enough that you can dominate it with limited resources but large enough that dominating it generates meaningful revenue and learning.

A practical exercise: list every user segment that has shown interest in your product. For each segment, rate (1-5) the urgency of their problem, your ability to reach them, their willingness to pay, and the density of their network (how easily one customer’s adoption leads to others in the same segment). Multiply the scores. The segment with the highest composite score is your beachhead candidate.

Basecamp (originally 37signals) found their beachhead in small web design agencies who needed a simple project management tool. Not enterprise project management, not construction project management — specifically small creative agencies. That focus allowed them to build an opinionated product that resonated deeply with a specific group, and that group’s recommendations drove expansion into adjacent markets.

See also: Transitioning from Services to Product: A Strategic Guide

Pivoting Versus Persisting: The Hardest Decision

The pivot-or-persist question paralyzes founders. There is no formula for it, but there are signals that help.

Persist if: a specific user segment retains well even if the broader user base does not, users are giving specific feature requests (indicating they are invested in the product’s future), and your activation rate is improving with each iteration of the onboarding flow. These signals suggest that the core value proposition is right and the execution needs refinement.

Pivot if: retained users cannot articulate why they use your product (suggesting they are not getting clear value), churn interviews consistently cite the same fundamental gap (not a missing feature but a missing value proposition), and you have iterated on the core experience three or more times without meaningful movement in retention metrics.

The most productive pivots are not wholesale reinventions — they are pivots within the problem space you already understand. You keep the market and the relationships you have built, but you change the product to address a different (or more specific) problem within that market. Slack pivoted from a gaming company to a messaging company, but the insight that drove the pivot — internal communication tools were terrible — came from their experience building the game.

Before you pivot, exhaust the adjacent possibilities. Talk to your best users — the ones who retained the longest and used the product the deepest. Ask them: what problem were you trying to solve when you found us? What were you using before? What almost made you leave? Their answers often reveal a positioning or feature adjustment that is more productive than a full pivot.

Scaling Before and After PMF Are Different Games

Pre-PMF, every dollar spent on marketing and sales is a dollar spent learning. You are not trying to acquire customers at scale — you are trying to find the right customers who give you the strongest signals. Growth spending before PMF is burning money to acquire users who will churn, which teaches you nothing except how fast you can burn money.

The appropriate pre-PMF growth strategy is high-touch and low-volume. Direct outreach to potential users in your beachhead segment. Participating in communities where your target users congregate. Content that demonstrates domain expertise (which attracts the right audience). Free tools or resources that serve the target market and drive awareness. The goal is 50-200 highly engaged users, not 10,000 signups.

Post-PMF, growth becomes about amplifying the signal you have found. The retention curve is flat, the activation rate is healthy, and the beachhead market is showing organic growth. Now you invest in the channels that scale: paid acquisition (with a clear understanding of customer acquisition cost versus lifetime value), product-led growth mechanics (virality, network effects), sales if the deal size justifies it, and content marketing optimized for the keywords your target market searches for.

The transition from pre-PMF to post-PMF is not a switch you flip. It is a gradual increase in confidence, supported by data, that the product is working for a specific audience. The biggest mistake is declaring PMF prematurely and scaling a leaky bucket. The second biggest mistake is never declaring it and iterating forever on a product that is already good enough to grow.

If you are building a software product and wrestling with whether you have found fit — or what to build next to find it — we help founders answer these questions.

// Related posts