How to Build a Product Analytics Stack Before PMF

A founder spends INR 3 lakh building an MVP, gets 200 sign-ups, and still cannot answer one basic question: where do serious users first get value? Product analytics before product market fit gives you that answer before you spend more on features, hiring, or acquisition. Before PMF, your job is not to report growth. Your job is to identify the user behaviour that proves a painful problem is being solved often enough to matter.

Why product analytics before product market fit matters

Pre-PMF companies do not fail because they lack charts. They fail because founders confuse activity with evidence. Downloads, page views, waitlist sign-ups, and demo requests can look encouraging while the product itself creates no repeat behaviour. You need an analytics stack that shows what users do after the initial curiosity fades.

For an early-stage company in India, every engineering sprint has an opportunity cost. If your team spends two weeks shipping a feature without knowing which existing workflow users value, you are making an expensive guess. Instrumentation turns product usage into a decision system: which user segment to pursue, which workflow to improve, and which feature requests to reject.

PMF is not a badge you announce after a good month. It is a pattern of sustained behaviour among a defined customer group. Research on pre-launch market research makes the same distinction: active inputs such as interviews and concept tests should sit alongside passive signals from observed behaviour. Read the research.

We see founders collect data because a tool makes it easy. Start instead with the decision you need to make next week. If a metric cannot change a product, customer, or go-to-market decision, it can wait.

Define the value event before tracking everything

Your analytics stack needs one anchor: the value event. This is the action a user completes when they receive the core benefit your product promises. It is not account creation. It is not a landing-page visit. It is not an app open unless opening the product itself delivers the outcome.

A B2B SaaS product may define value as a team completing its first recurring workflow. A consumer product may define it as a user completing a transaction, booking, contribution, or repeat action that solves the original need. The exact event changes by business model. The standard does not: it must represent customer value, be observable in product data, and occur early enough to guide product work.

• Acquisition event: a user arrives from a known source or campaign.
• Activation event: a user completes the minimum setup needed to try the product.
• Value event: a user receives the promised outcome.
• Retention event: a user returns and receives that outcome again.
• Commercial event: a user pays, renews, upgrades, or refers another buyer.

Write these definitions in plain language before an engineer adds a single tracking call. Include the event name, triggering action, required properties, and owner. If two people on your team define activation differently, your dashboard will create arguments instead of clarity.

Keep the first version narrow. You can add detail after you know which workflow deserves attention. A clean record of five meaningful events is more useful than 80 events nobody reviews.

Build a minimum analytics stack, not a data project

Before PMF, your stack should answer four questions: who used the product, what they did, whether they returned, and what they said about the experience. You do not need a large data team or an elaborate warehouse to answer those questions. You need consistent event definitions and one place where the founder can inspect behaviour every week.

Layer	What it should capture	Pre-PMF use
Event collection	User actions, timestamps, account IDs, product context	See the path from sign-up to value
User and account records	Segment, acquisition source, plan, geography, company type	Compare the users who return with those who leave
Behaviour dashboard	Funnels, cohorts, repeat actions, feature paths	Find drop-offs and retention patterns
Feedback record	Interview notes, support issues, reasons for churn	Explain why the numbers changed

Use stable identifiers from day one. A person may sign in on a phone, then return on a laptop. A B2B buyer may invite several teammates into one account. If you cannot connect those actions to a user and, where relevant, an account, you will overcount usage and misunderstand adoption.

Track event properties only when they help a likely decision. For example, role, city, company size, onboarding path, or referral source may reveal a meaningful segment. Do not collect sensitive personal data merely because you can. Define access rights, retain only what your team needs, and make product telemetry part of your operating discipline.

Instrument the first user journey end to end

Your first funnel should follow one customer through the shortest route to value. Start with the first product session, not your whole roadmap. Map every required action between entry and the value event, then track completion and abandonment at each step.

For each event, record enough context to diagnose friction. If a user fails to complete onboarding, you need to know whether they stopped after entering data, inviting a colleague, selecting a category, or waiting for an approval. “Onboarding completed” is too blunt to guide the fix. Small product steps are where early retention is won or lost.

1. List the first job the customer hired your product to do.
2. Write the minimum actions required to complete that job.
3. Mark the moment when the promised outcome appears.
4. Track each action with a user ID, timestamp, and relevant context.
5. Test events yourself before releasing a build.
6. Review a sample of raw event records after release.

Do not leave instrumentation entirely to engineering. The product owner must verify that an event fires at the right moment and that its properties mean what the dashboard says they mean. A tracking event called project_created is misleading if users create empty projects and never use them.

At Nebula, we work alongside founders across validation, product, fundraising, and go-to-market. Our three-phase process treats evidence from real users as an input to product decisions, not a reporting task after a release. Build the measurement habit while your product is still small enough to change quickly.