How to Run Cohort Analysis Before Product-Market Fit

INR 50,000 spent on acquisition can look like traction until you separate the users who arrived in week one from those who arrived after your latest product change. Cohort analysis before product market fit gives you that separation. It shows whether users return because the product solves a repeat problem, or whether growth is being held up by fresh sign-ups, founder follow-ups, discounts, and one-time curiosity. Before you raise capital or expand channels, you need to know which of those is true.

What cohort analysis before product market fit actually answers

A cohort is a group of users who share a meaningful starting point. The most useful starting point is usually the week or month of first value, not merely the date they created an account. For a B2B SaaS product, first value may mean inviting a teammate, uploading data, or completing a workflow. For a consumer product, it may mean completing a first order, booking, payment, or session.

Cohort analysis before product market fit asks a narrow question: after users experience the promise of your product, do enough of them come back and repeat the behaviour that creates value? It does not prove that you have product-market fit by itself. It stops you from mistaking acquisition activity for user demand.

The method also makes product changes easier to judge. When you launch a new onboarding flow in May, compare the May cohort with April at the same point in its lifecycle. Reading a cohort table horizontally shows how one cohort behaves over time; reading it vertically lets you compare cohorts at the same lifecycle point, such as month one or month three.Source: CFO Pro Analytics

• Acquisition cohort: users grouped by first signup, install, lead source, or campaign.
• Activation cohort: users grouped by the date they completed the first value event.
• Behaviour cohort: users grouped by a shared action, such as creating a project or placing a first repeat order.

For most early-stage teams, activation cohorts are more honest than signup cohorts. A signup is interest. A value event is evidence that the user crossed into the product.

Choose one repeat behaviour before you open a dashboard

Founders often start with a dashboard and then search for a metric that looks good. Start in the opposite direction. Write one sentence: “A user receives recurring value when they do this action at least this often.” That sentence defines the behaviour your cohort table must track.

Your action should sit close to the customer’s job, not your vanity metric. A creator-tool user returning to edit and publish is stronger than a user opening a notification. A procurement SaaS customer approving a purchase request is stronger than logging in. A marketplace buyer completing a second transaction is stronger than browsing listings.

Set the interval to match the natural frequency of the problem. Daily cohorts suit a product built around daily work. Weekly cohorts suit recurring operating tasks. Monthly cohorts suit products with longer buying and usage cycles. Do not force daily retention on a product whose customer only needs it once a month; you will manufacture a false failure signal.

Then define a minimum meaningful return. You are not looking for perfect usage. You are looking for a pattern that says users pull the product back into their lives without a founder chasing them. Our venture-building process treats this as a validation problem before it becomes a scaling problem.

Build a cohort table you can act on

You do not need expensive software to run the first version. A spreadsheet, product-event export, and clean user identifier are enough. The hard part is not calculation. The hard part is deciding which events count, removing duplicate records, and keeping the definition unchanged long enough to compare cohorts fairly.

Put cohort start dates in rows and periods since activation in columns. Each cell should show the share of that cohort completing the repeat value event in that period. Use percentages for retention and show the underlying user count beside or beneath the table. A cohort of six users can move sharply because one person leaves; that is a conversation starter, not a verdict.

Cohort	Activated users	Week 0	Week 1	Week 2	Week 3
1–7 June	12	100%	Users returning	Users returning	Users returning
8–14 June	15	100%	Users returning	Users returning	Users returning

Keep the first table deliberately plain. Segment only after you can see a basic pattern. Once you have a few cohorts, split by customer type, acquisition channel, city, plan, use case, or onboarding path. In India, this often exposes differences hidden inside a broad user category: a small business owner, a student, and an operations manager may sign up for the same product but return for entirely different reasons.

Document every definition beside the table. If “active user” changes halfway through the analysis, your trend line becomes theatre.

Read the shape, not one retention number

Early retention usually drops after the first experience. The question is what happens after that drop. If later periods keep collapsing, the product has not become part of the user’s routine. If the curve begins to flatten, you may have a group of users receiving repeat value. Your next job is to understand who they are and what they do differently.

Compare cohorts at the same lifecycle stage. Do not compare a January cohort in month four with a March cohort in month one and call the later group stronger. A vertical comparison asks whether newer cohorts retain better at the same age. That is how you evaluate a product release, onboarding change, pricing shift, or tighter customer segment.

1. Flat but low: a small group may care deeply. Interview them before changing the core product.
2. High early use, steep drop: users understand the first interaction but do not find a reason to return.
3. Newer cohorts improve: identify the exact change, segment, or channel behind the improvement.
4. Paid users retain while free users do not: check whether payment filters for stronger intent or whether the paid workflow creates more value.

Do not read a cohort table in isolation. Pair it with customer conversations, support tickets, cancellation reasons, sales-call notes, and session recordings where appropriate. The table tells you where the problem appears. Customer evidence tells you why.

Useful leading indicators are often product-specific behaviours rather than revenue targets. One cited example describes companies tracking repeated core actions, such as sending messages, backing up devices, or adopting multiple product features, as indicators of product usage depth.Source: Vasco Your version should be tied to your customer’s recurring job.