Product Data Interview: Joel Rego

This is part of our Product Data Interviews series, where we ask product managers across the industry the same set of questions about how they use data, what slows them down, and what helps them make better product decisions.

Joel Rego is a Product Manager at Cockroach Labs, where he works on the monetization and billing journey: pricing, packaging, metering, and the billing platform. His work connects product usage to the rate cards, quotes, and invoices customers see.

In this interview, Joel explains why repeated customer questions can expose a product problem, what makes him trust a number, and why turning evidence into a decision still takes judgement. He also shares a practical habit for working with AI: ask for the counter-case, then check the source.

Connect with Joel on LinkedIn.

This interview draws on Joel’s written answers and our conversation. It has been edited for clarity and flow.

1. What kind of product decisions are you personally responsible for in your day to day work?

I work on the Monetization and Billing journey: pricing, packaging, metering, and the billing platform. In practice that means working out how a product becomes a rate card. What the unit of consumption is, which parts of the bill are a commercial fee and which are infrastructure passed through from the cloud provider, how usage gets metered, and how it all appears on a quote and an invoice. Unglamorous plumbing, but it tends to stay in place once contracts are written against it.

2. When you're evaluating whether something is working (or worth building), what signals matter most to you?

Convergence. A single complaint is an anecdote. When several customer calls and support tickets independently point at the same hypothesis, that's worth acting on.

In billing the recurring theme is cost-to-value. Customers rarely dispute the total in the abstract. They ask what a particular line represents and whether the value justifies it. When that keeps coming back from different accounts, the bill isn't explaining itself, and that's a product problem rather than a support problem.

3. Walk me through a recent product decision you made that involved data. What did the process actually look like?

Invoice granularity. We saw a steady stream of tickets and customer questions about transparency: what sits behind a given line, and which part is our service versus underlying infrastructure. The spend data lined up with it, since the line being queried most was also the largest share of the bill. Making the invoice more granular was the natural hypothesis, and the two inputs together made it an easy call.

4. How confident do you generally feel in the data available to you when making product decisions? What tends to increase or reduce that confidence?

Reasonably confident, though it varies by area.

Billing and usage data is what I trust most, because it's the system of record. If it were wrong, customers would notice, so it gets corrected quickly.

Confidence drops when a question spans several systems. Billing, the control plane, the CRM, and the support tool each hold part of the picture, and stitching them together is manual. What increases my confidence is being able to trace a number back to something a customer would recognise on their bill. What decreases it is a number that only exists in a dashboard.

5. What's the most frustrating or time-consuming part of getting the insights you need to make a decision?

Working out what question I'm actually asking, before going near the data. And the fact that numbers tell you what is happening but never why, so there's always a round trip to customers that you can't compress.

6. How self-serve is data access for product managers at your company today?

It's improved quite a bit. A lot of operational tasks that used to need an engineering ticket are now self-serve through internal tooling. We also have an internal AI assistant called Mica, which has been mentioned publicly, and it's made day-to-day information retrieval noticeably easier.

7. What's the hardest thing about turning data into action rather than just more dashboards or reports?

Building the narrative. Most decisions have several levers behind them, each with its own data pointing its own way, and none conclusive alone. The work is assembling them into one story that explains why this change and why now. A dashboard gives you the inputs; connecting them is judgement, and that's where things slow down.

8. Are there product metrics or definitions that people at the company regularly interpret differently?

Growth metrics are where we see the most disagreement, especially conversion and churn. For example, if a cluster is deleted within 24 hours, does that count as churn? The answer depends on the definition people are using. Billing and payment metrics are much better defined and rarely disputed.

That ambiguity also matters when you're using AI to query data. Having access to hundreds of tables doesn't mean the tool knows which columns correspond to which business metrics. Our data team is building a semantic layer to make those relationships explicit, so the AI has a clearer understanding of what a metric means.

9. What's a surprising or overlooked source of product insight that you think more teams should pay attention to?

Old Slack messages. Most organisations treat Slack as something that scrolls past and is gone, but with semantic search over the history you can reconstruct how a decision was actually made: what was considered, what was rejected, and why. It's most useful for decisions made quickly, which are the ones with the least documentation and often the ones you most need to understand later.

10. What advice would you give another PM at a startup trying to make better product decisions with data?

Double-check any analysis you get from AI. These tools are genuinely useful and I use them a lot, but they amplify whatever direction you came in with. Ask a question that implies a hypothesis and you'll often get evidence for it back.

The bias is yours, not the tool's. The tool just magnifies it. Ask for the counter-case explicitly, and verify against the source before you act.