Product Analyst

While a team is small, whoever owns the product pulls the numbers themselves. The product manager writes a database query in the evening and reads last week's figures off it. With few people and few questions, that holds up well enough.

Past 40 people and a dozen features, two things break at once. The first is time. When a question takes two days to answer, people stop asking and move on, and decisions drift back to whoever argues hardest in the room. The second is that the numbers stop agreeing with each other.

That second failure showed up at a Pagedeck quarterly review. Mia said last month's active users were 42,000. Ravi said the same month was 38,000. Both had pulled the figure themselves. Mia had counted anyone who opened a document at least once; Ravi had counted only people who edited one. Neither was wrong, and the remaining 40 minutes of the meeting went to arguing about which number was real.

The role exists because one person now owns both halves: getting numbers out quickly, and fixing once and for all what each number counts.

The day usually starts with yesterday's figures. You open the dashboard, the screen that collects the main metrics in one place, and look for values that moved noticeably. If signups came in at 60 percent of normal, the first job is separating a real drop from a failure on the side that writes the logs, which simply stopped capturing them. The second turns out to be the cause more often than people expect.

After that, incoming questions. The work on each one tends to run through five steps.

1. Rewrite the question into something answerable. "Why did checkout conversion drop?" has no answer as asked. Split into which month it is being compared against, by what percentage, and whether everything dropped or only one acquisition channel, and data can reach it. Until that split exists, any figure you pull answers a different question than the one that was asked.
2. Check whether the data can be trusted. If event tracking, the practice of recording what users do, is misconfigured, everything built on top of it is wrong. If taps on the payment button were being recorded in the app but not on the web, that fact has to be reported before any figure is.
3. Pull the numbers. A funnel analysis showing how many people drop out at each step finds the stage where they disappear, or retention, the degree to which existing users keep coming back, gets split by group and compared.
4. Design experiments and rule on them. For an A/B test, where two versions are shown to randomly divided groups and the results compared, the sample size, the number of days, and the chance that a difference is coincidence are all set in advance.
5. Hand the result over. Not the query output, but a single page: what was asked, what came back, and what to do about it. Handing over a spreadsheet instead moves the interpreting onto whoever asked, and it usually stops there.

The step that eats the most time is not the third one, the one that looks like the job from outside. Writing the query takes half an hour. Agreeing on what is being counted and confirming the records are sound takes two days.

The most frequent partner is Mia, who owns the product. The analyst supplies the evidence while candidates are being chosen, and afterward rules on whether the product metrics actually moved.

The other four relationships have different purposes.

1. Theo plants the records. Before a feature is built, the two of them decide which events it will emit and under what names. Decided after launch, the feature has no data for its first month, and that early response is gone permanently.
2. Ravi runs the most experiments. He is often changing signup copy or email subject lines, so the conversation about settling criteria in advance happens with him more than anyone.
3. Sofia asks, ahead of a contract, whether a customer is genuinely using the product. One enterprise account whose usage has slid for two months is a signal worth acting on before the renewal date arrives rather than after it.
4. Grace takes the whole picture once a quarter. Not the figures for individual features, but where the one headline metric the whole team is pointed at has been heading across the quarter.

This is not the only seat that handles numbers. As a company grows, it separates from the data analyst, who also covers figures from outside the product, and a separate seat appears for preparing analysis-ready data.

"Send this to the analyst first. We need to know whether it's even a question numbers can answer."

A request to turn the question into a form data can reach.

"That figure is unusable — the event is only planted on half the surfaces. Let's look again after the next deploy."

The recording itself is incomplete, so the number on hand differs from reality.

"Let's set the criteria before we run it. Which number are we looking at, and after how many days?"

Pinning the threshold down so nobody picks it after seeing the result.

At Pagedeck this seat tends to close meetings rather than open them. When a discussion about feature candidates splits, Mia asks for numbers, and the next meeting starts by reading that one page. The numbers do not make the decision. When it turns out that two of the three candidates target a group of only 300 users, the discussion narrows to the remaining one on its own.

The most common misreading is treating the role as a query service. The output is tables and charts, so pulling them looks like the whole job. The part that actually creates value is rewriting the question. Someone asking why conversion fell usually needs to know which step lost how many people rather than a reason, and naming that step changes the next conversation. Used purely as a query service, the requests pile up while decisions still get made on instinct, which is the situation the seat was created to end.

The second is assuming the data supplies the answer. Numbers say what happened; they do not say why. That 40 percent of people left on the payment screen comes out of the data. Whether they left over price or over the hassle of registering a card does not. This is why the seat runs in tandem with asking users directly. Draw conclusions from figures alone and you end up choosing whichever cause is easiest to fix.