Product Data Interview: Rami Pinku

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.

Rami Pinku’s product work has spanned customer-facing applications, developer platforms, and cloud infrastructure. Across those roles, he has helped teams prioritize customer problems, scope new products and major redesigns, and balance usability with technical complexity and enterprise requirements.

In this written interview, Rami explains how he connects usage data with customer conversations, why shared metric definitions matter, and what support requests can reveal that a dashboard alone cannot. His answers draw on experience across several companies and roles; they do not describe practices specifically at JFrog.

Connect with Rami on LinkedIn.

1. What kinds of product decisions have you been responsible for across your career?

I’ve worked on decisions about which customer problems to prioritize, what a new product or major redesign should include, and how to balance usability, technical complexity, and enterprise requirements. That has included customer-facing applications, developer platforms, and cloud infrastructure.

These decisions are rarely made by one person. My role is to bring customer needs, usage evidence, and technical constraints together, make the trade-offs explicit, and help the team decide what to build and how we’ll know whether it worked.

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

The signals depend on what the product is meant to help customers accomplish. For each product, I try to define a north star metric that reflects that outcome, supported by metrics that show whether customers adopt the product and get value from it.

Usage matters, but I look at the relevant behavior rather than activity in the abstract. Are customers reaching the information they need? Can they complete the workflow? Do they return to use it again? I also define guardrail metrics so we can see whether improving one outcome is making another part of the experience worse.

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

In a previous role, we rebuilt a client application from scratch, including a new backend. We wanted the new experience to reflect what customers actually needed, so we examined which data they accessed through both the old client and the API. We also analyzed the old client’s user funnel to understand how people navigated it and where they got stuck.

That evidence helped us simplify the new client substantially and focus it on the information and workflows customers used. After launch, we continued to monitor usage to see whether customers were getting stuck or looking for capabilities or information we had left out. The data shaped the initial design and helped us evaluate it once customers started using it.

4. How confident do you generally feel in the data available to you? What increases or reduces that confidence?

I rely on product data to understand what customers do. My confidence in a decision increases when I can connect that data to other evidence: conversations with customers, input from teams who work with them, and the requests and problems customers raise.

For example, low usage of a capability does not explain itself. Customers may not need it, may not know it exists, or may be unable to use it in their workflow. When the data and those other sources point in the same direction, I’m more confident. When they conflict, I have a clearer idea of what to investigate.

5. What’s the most frustrating or time-consuming part of getting the insights you need?

Usually, it is figuring out what data exists and what it means. Even in companies where I could not access the data directly, I could generally get what I needed quickly from the people who could.

The harder questions come before the analysis: What does this data point represent? How was it measured? Does its definition match the product question I’m trying to answer? Once those things are clear, getting and analyzing the data is often the easier part.

6. How self-serve has data access been for you as a product manager?

It has varied by company. In some roles, I could explore the data directly; in others, I worked with people who could retrieve or analyze it. I’ve generally been able to get the information I needed quickly either way.

Direct access is useful, especially when you need to explore a question as it develops. But access alone does not tell you what data is available, how a metric was defined, or whether it answers the question you have. Clear definitions and people who understand the data make a substantial difference.

7. What’s the hardest thing about turning data into action rather than more dashboards?

Identifying which lever we can actually move to improve the outcome, then checking whether moving it harms something else. A dashboard may show where a metric is weak, but it cannot tell you by itself which product change will improve it.

That takes an understanding of the product, the customers, and the market. Sometimes the relationship is subtle, so we make a change, watch both the target metric and our guardrails, and adjust. It often requires experimentation and iteration.

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

Yes. Across different products, I’ve seen people use the same metric name while calculating different things. Change the denominator, the time window, or which customers are included, and the number can tell a very different story.

A shared dashboard is not enough. The team needs to agree on what each metric means, how it is calculated, and which decision it is meant to inform. Otherwise, people can look at the same chart and leave with different conclusions.

9. What’s an overlooked source of product insight?

Customer support. Support teams hear from customers every day, but those interactions are often treated as individual issues to resolve rather than signals of a broader product problem.

I look for patterns across requests and conversations. What are customers repeatedly trying to do? Where do they need an explanation or a workaround? Which problems create frustration that usage metrics alone might not reveal? Those patterns add context to the quantitative data.

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

Build measurement into the product from the beginning. Decide what you need to learn, instrument the relevant behavior, and create the dashboards as you build, rather than trying to reconstruct the data later.

Keep the set of metrics small. Choose a few that reflect the real problems your product is meant to solve, include guardrails for unintended effects, and review them consistently. If a metric does not help the team understand customer value or decide what to do next, reconsider why you are tracking it.