Setting Up Your First Analytics Stack as a New PM

The minimum set of tools, events, and habits a new PM needs to start reading product data without drowning in it.

What You Were Actually Handed

You joined. Someone scheduled a dashboard walkthrough. A data analyst or a senior PM opened a tab full of line graphs and said something like, "This is our North Star metric, these are our weekly actives, and this funnel is where we track conversion."

You nodded. You took notes. You left the meeting not knowing whether any of it was true.

This is not imposter syndrome. This is the correct response to inheriting an analytics setup you did not build. The dashboard you were handed is not a product truth - it is a record of what was easy to instrument at the time someone first cared enough to add tracking. Engineers built it for engineers. The events that fire are the events that were convenient to fire, not the events that answer product questions.

Your first job is not to get fluent in the tool. Your first job is to find out whether the tool is measuring what you think it is measuring.

flowchart TD
    A[Analytics Stack] --> B[Layer 1 Event Collection]
    A --> C[Layer 2 Storage]
    A --> D[Layer 3 Visualization]

    B --> E{Company Stage}
    E --> F[Early Stage\nMixpanel or Amplitude SDK]
    E --> G[Mid Stage\nSegment or Rudderstack]
    E --> H[Scale Stage\nCustom CDP or Snowplow]

    F --> I[Storage in tool itself]
    G --> J[Redshift or BigQuery]
    H --> K[Snowflake plus dbt]

    I --> L[Built-in dashboards]
    J --> M[Metabase or Looker]
    K --> N[Looker or Tableau]

The Three Layers Nobody Explains Together

Every analytics stack - from a two-person startup's Mixpanel free tier to an enterprise data warehouse with a dedicated analytics engineering team - has three distinct layers. Confusing them is how bad decisions get made.

Layer 1: Event Collection

This is where data is created. A user taps a button, completes a purchase, or abandons a form - and code running on the client or server fires an event with a name and a set of properties. Tools at this layer include Segment, Amplitude SDKs, Mixpanel SDKs, Rudderstack, and raw server-side logging.

The quality problem lives almost entirely here. If an event fires with the wrong property, fires twice, or is named differently across platforms (iOS calling it purchase_completed, Android calling it order_success, and the web team calling it checkout_done), every layer downstream inherits that error invisibly.

Layer 2: Storage

This is where events land and are organized for querying. Small teams often skip this layer entirely and query from the collection tool's own database. Larger teams route events into a data warehouse - BigQuery, Redshift, Snowflake - where analysts can join product events with payments data, CRM data, or support tickets.

The failure mode here is schema drift: nobody governs what an event is supposed to look like, so over six months the same event accumulates slightly different property names across multiple tables, and no query can reliably aggregate them.

Layer 3: Visualization

This is what you were shown in the walkthrough. Looker, Metabase, Superset, Amplitude dashboards, Tableau - all of them are displays built on top of whatever is in layers one and two. They look authoritative. They have color and titles and percentage signs.

They inherit every error made upstream, silently, with no warning label.

Many PMs spend their first months learning to navigate layer three. The actual work - the work that determines whether those dashboards are usable - happens in layers one and two, and most PMs never look there until something breaks badly enough to force it.

Starter Stacks by Company Stage

The right stack is not universal. A seed-stage company with one engineer running experiments should not be architecting a warehouse. An enterprise team with fifteen engineers should not be making product decisions from a free-tier Mixpanel with ad-hoc event names.

The judgment call the table does not make for you: most companies sit between stages, which means their stack is usually a patchwork of choices made at different headcounts by people who have since left. You are not inheriting a stack that was designed. You are inheriting a series of decisions made under deadline, none of which were coordinated.

What Razorpay Learned the Hard Way

Razorpay - one of India's largest payments infrastructure companies - went through a reported analytics rebuild that illustrates exactly what happens when event collection is left ungoverned across multiple teams.

As Razorpay scaled across multiple product lines (payment gateway, payroll, banking), independent teams were instrumenting events for overlapping user journeys with no shared naming convention, no event registry, and no ownership model. The same merchant action was recorded under different event names depending on which team's SDK fired first.

The cost was not a failed product launch or a missed metric. The cost was months of engineering time spent reconciling events after the fact - rebuilding event schemas, running deduplication pipelines, and manually auditing which naming patterns were most reliable for which date range.

Months. Not of product work. Of cleanup.

The lesson is not that Razorpay made unusual mistakes. The lesson is that this is the default outcome when analytics is treated as an afterthought across team boundaries. The pattern repeats in almost every product organization that scales past three or four independent teams without establishing a shared event taxonomy first.

Your Week Two Audit Checklist

Do not spend week two optimizing anything. Spend it auditing. The audit takes less time than you think, and it will tell you more about the organization's data maturity than any onboarding document will.

Event integrity check

• Pick one core user action - the most important thing a user can do in your product - and trace it from UI trigger to dashboard display. Does the event name match what you expect? Does it fire once? Does it fire on all platforms?
• Ask the data team: is there an event dictionary or schema registry? If the answer is "sort of" or "we have a Notion page but it is out of date," that is your answer.

Naming convention audit

• Pull the last 30 distinct event names from your collection tool. Look for the same action named two different ways. Count how many naming patterns exist (verb-noun, noun-verb, camelCase, snake-case, inconsistent platform prefixes). More than two patterns means nobody owns this.

Dashboard provenance check

• For every metric on the dashboard you were handed, ask: who built this, when, and what event does it query? Dashboards outlive the people who built them. The definition of "active user" may have been changed twice and neither change was documented.

Coverage gap check

• Write down the three product questions you most need answered in your first 90 days. Then check whether the data exists to answer them. Not whether a dashboard exists - whether the underlying events fire with enough fidelity to support the answer. If two of your three questions cannot be answered with existing data, that is your roadmap, not a backlog item.

The Judgment Turn

Here is what nobody says in the dashboard walkthrough:

The analytics setup you inherited was not built for you. It was built by engineers who needed to debug production issues, satisfy an investor data request, or prove that a feature they built was being used. Those are not product questions. They are engineering and business questions, and they produce engineering and business instrumentation.

The events that fire on your product today are optimized for those answers. If your product questions are different - and as a PM, they almost certainly are - then the stack is not broken. It is correctly built for something other than what you need.

This means your audit is not a fault-finding exercise. It is a gap analysis. You are mapping the distance between what was built and what you need, so that when you eventually ask engineering to instrument new events, you can justify the request in terms of specific decisions it will enable, not in terms of general data quality improvement.

There is one more thing worth saying plainly: most PMs take the dashboard at face value and never find out what they were actually deciding without. By the time the gap becomes visible - a product bet made on bad event data, a feature cut based on a metric that was double-counting - the decision is already made. The data does not fail loudly. It fails quietly, inside a number that looked right.

Related Articles

• The Three Levels of Product Analytics Maturity
• Shifting Analytics Instrumentation Left in Agile Sprints
• The First 90 Days as an Associate Product Manager