Product Data Interview: Rashmi Hegde

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.

Rashmi Hegde is a Staff Product Manager at Harness, where her work has spanned the internal developer portal, developer environments, and other developer-facing tools. She works with developers and enterprise platform teams on decisions across the roadmap, pricing, positioning, and bringing new capabilities to customers.

In this interview, Rashmi explains how she combines product usage, customer conversations, and market signals to shape the roadmap as the product moves toward a more product-led growth experience. She also discusses why telemetry coverage does not always mean reliable data, how usage across a product portfolio can reveal new opportunities, and why instrumentation belongs in every product specification.

Connect with Rashmi on LinkedIn.

1. What kind of product decisions are you personally responsible for at Harness?

My role at Harness has spanned several areas of the developer experience, including the internal developer portal, developer environments, and other developer-facing tools. The primary persona we’re solving for is the developer, although I work closely with platform teams, particularly at enterprise customers, who build and manage these experiences for their developers.

A big part of my role goes beyond managing the product roadmap. I’ve been involved in decisions around what we build, how we price and position our products, and how we take new capabilities to customers.

More recently, as we move toward a more product-led growth (PLG) experience, understanding how customers discover our products, where they get stuck, and what helps them reach value faster has become increasingly important.

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

I think it really depends on the question you’re trying to answer.

If I’m evaluating whether we should enter a new product area, I look at market signals, customer conversations, and competitive intelligence. For example, are existing customers talking about a particular problem? Are they already solving it using another tool? Is there evidence of a need that we’re not addressing today?

When I’m evaluating whether an existing product or capability is working, I take a much closer look at the customer journey. I want to understand what it takes to get started, explore the product, begin using it meaningfully, and eventually become a retained customer.

The signals I look at change depending on the decision. For a new opportunity, I want to establish whether there’s a genuine problem and a market for it. For an existing product, I want to understand where customers are succeeding, where they’re struggling, and what’s preventing them from realizing value.

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

A recent example was re-evaluating our near-term and medium-term roadmap as we moved toward a more PLG-oriented experience.

I approached this from three angles.

First, I looked at how existing customers were using the product. I didn’t just look at the number of customers or which features they were actively using. I also wanted to understand the use cases behind that activity. For example, if a customer was using orchestration pipelines to enable developer self-service, were they using them for infrastructure provisioning, service onboarding, or other workflows? Understanding that context helped me see where the product was delivering value and where there were opportunities to expand it.

Second, I looked at prospect conversations. We have an internal tool that captures customer conversations, and I used it to explore relevant keywords and phrases around orchestration, developer self-service, and related workflows. I wanted to understand how often these needs came up, what prospects were looking for, and whether there were barriers preventing them from adopting our existing capabilities.

Third, I looked at broader industry trends, competitive offerings, and market research.

Bringing these sources together helped clarify our priorities. In the near term, we needed to make onboarding easier, reduce the learning curve, and help customers reach value faster. Beyond that, there were opportunities to make orchestration more dynamic and AI-native, moving toward more intent-driven experiences.

What mattered was looking beyond individual metrics and combining actual product usage with customer conversations and market signals to make a more informed roadmap decision.

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

My confidence in data has varied quite significantly across organizations and products, particularly in enterprise B2B.

One challenge is that enterprise customers may restrict the data they’re willing to share. In other cases, telemetry and analytics simply become an afterthought during product development, leaving us with very limited information.

I also think it’s important to distinguish data coverage from data quality. I’ve seen situations where telemetry was available from upwards of 70% of customers, but the data came only from non-production instances. While the coverage looked good on paper, it didn’t necessarily represent how customers were actually using the product in production.

Another challenge is inconsistent data models and definitions. Different teams may create their own tables using common identifiers, only for those tables to produce conflicting numbers. When that happens, it becomes difficult to know which data to trust.

In B2B, we often have the opportunity to speak directly with customers and use those conversations to validate our findings when quantitative data is incomplete.

However, with the pace of product development increasing, particularly in AI, we can’t always wait for customer feedback. That’s why I believe measurement needs to be built into the product from the very beginning, rather than added later.

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

For me, the biggest challenge is often getting the data in the first place.

As we build new features and capabilities, we need to ensure that the right events are being captured so we can understand how those capabilities are used. This requires coordination across product, engineering, and data platform teams to define what needs to be measured and get that data flowing into a common warehouse.

It’s a practice that sounds straightforward but can be difficult to establish consistently across an organization. When instrumentation isn’t part of the standard product development process, every new capability can require a separate effort to determine what to measure and how to collect it.

AI is making data discovery and analysis much easier. You can increasingly use natural language to find and explore information rather than having to know exactly where everything lives.

But there’s a fundamental limitation: you can make data easier to find and analyze, but you can’t analyze data that was never collected. That’s why I think establishing a repeatable instrumentation process is just as important as investing in analytics tools.

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

We have tools like Mixpanel and Metabase that make it relatively easy to analyze data independently. I’ve found Mixpanel particularly useful for understanding user flows and identifying where people drop off, while Metabase is great for building custom dashboards, joining tables, and exploring data based on specific questions.

The main limitation is that this self-serve experience depends on the data already being available in the warehouse. When it is, I can explore it fairly independently; when it isn’t, getting it instrumented and made available requires coordination with engineering.

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

I think the completeness and context of the data play a big role in whether stakeholders and leadership trust the insight enough to act on it.

If 90% of customers are dropping off at the same point in an onboarding funnel, the next step might seem obvious: fix that part of the experience. But in B2B SaaS, customer behavior is rarely that uniform.

You often need to dig deeper into the data. Which customers are experiencing the problem? What’s the commercial value of those customers? Is the issue genuinely blocking them, or is it just a point of friction? Are there other factors that explain their behavior?

I also find it useful to bring qualitative information into the analysis. For example, combining funnel data with in-app feedback can help establish whether a drop-off reflects a serious product problem or something less consequential.

A dashboard might tell you where something is happening, but you still need to understand its significance before deciding what to do about it.

A lot of the PM’s work happens in that deeper investigation: connecting the numbers to customer context, understanding the severity of the problem, and determining which intervention is most likely to make a difference.

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

Yes, and I’ve seen this across organizations.

In an ideal world, metrics would have clearly documented definitions that are shared across teams and available directly in analytics tools. You could look at a metric, understand how it’s calculated, and drill down into the underlying data.

In practice, partial data, inconsistent instrumentation, and differences between products make that difficult.

For example, in a previous organization, the definition of an active user differed between cloud and on-premises products because the data we could collect was different.

I also see challenges with concepts like onboarding completion and time to value. What does it actually mean for a customer to have completed onboarding or realized value? They might have explored the product or completed a task once, but that doesn’t necessarily mean they’ve found lasting value or will continue using it.

Even something like a returning user depends on the definition. Does returning three times in a month count, or do we want to see someone coming back every week for three months?

There are established best practices, but I don’t think every metric can be defined universally. The definition needs to reflect the product, its intended value, the customer’s usage patterns, and what the organization is ultimately trying to measure.

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

I think one overlooked opportunity is combining qualitative customer conversations with quantitative usage data across an entire product portfolio, particularly when looking for new revenue opportunities.

Teams often focus on signals within their own product: who signed up, who explored a feature, who converted from a trial, and who dropped off. Those are useful signals, but they don’t necessarily reveal every customer who could benefit from the product.

Consider a customer who is already using a CI/CD product to build pipelines and give developers direct access to those pipelines. Their usage patterns might suggest an opportunity for an internal developer portal, which could provide developers with a single self-service entry point rather than requiring them to interact directly with the underlying CI/CD pipelines and deal with that complexity.

That opportunity might not be obvious from the developer portal’s own sign-ups or funnel data. But if you combine usage patterns from the CI/CD product with customer conversation transcripts, you may be able to identify the need and validate whether the portal would solve a genuine problem.

AI is making it easier to analyze large volumes of customer conversations and correlate them with quantitative signals. This creates an opportunity to identify potential cross-sell customers based on what they’re already doing with related products, rather than waiting for them to explicitly express interest in another product.

I think this is particularly valuable for companies with multiple products serving related customer needs. Some of the best opportunities for growing a product may be hidden in how customers use other products in your portfolio. Connecting those signals to customer conversations can make cross-sell decisions more informed and help sales teams approach customers with a much clearer understanding of the value they could get.

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

I’d say two things: start measuring early, and look beyond the numbers.

The role of data depends on the kind of product you’re building and the stage it’s at. B2C products often have much larger volumes of user activity, whereas B2B products may have fewer customers and more limited telemetry. In B2B especially, collecting data needs to be an explicit priority rather than something that gets pushed to the back burner.

I’d make instrumentation part of every product specification. When defining a feature, think about how you’ll measure whether it works, what events need to be captured, and how that information will be made available. It’s much easier to build measurement in from the beginning than to retrofit it later.

I’d also change the focus of analytics as the product matures.

At zero to one, combine market signals with qualitative and quantitative data to understand the opportunity and validate the problem.

At the MVP stage, focus on the onboarding funnel and user behavior to understand where customers get stuck.

As the product scales, look more closely at feature-level usage, how customers are applying different capabilities, and which use cases are emerging.

That last point is especially important. Customers sometimes use a product in ways you didn’t originally anticipate, and those patterns can reveal new opportunities for the roadmap.

Ultimately, data should help you make better decisions, not simply produce more dashboards. Start measuring early, adapt what you measure as the product evolves, and combine quantitative signals with customer context to understand what’s really happening.