How would you define the success of New Relic's Distributed Tracing capability?

Introduction

Defining the success of New Relic's Distributed Tracing capability requires a comprehensive approach that considers multiple stakeholders and metrics. To address this product success metrics challenge effectively, I'll follow a structured framework covering core metrics, supporting indicators, and risk factors while considering all key stakeholders.

Step 1

Product Context

New Relic's Distributed Tracing is a feature within their observability platform that helps developers and operations teams understand and optimize the performance of complex, distributed systems. It provides end-to-end visibility into requests as they flow through microservices and other components of modern applications.

Key stakeholders include:

1. Developers: Seeking to identify and resolve performance bottlenecks
2. Operations teams: Aiming to maintain system reliability and efficiency
3. Business leaders: Focused on improving overall application performance and user experience

User flow typically involves:

1. Instrumenting application components with New Relic agents
2. Configuring tracing settings and sampling rates
3. Viewing trace data in the New Relic UI, analyzing performance, and identifying issues

Distributed Tracing aligns with New Relic's broader strategy of providing comprehensive observability solutions. It complements their other monitoring tools and helps differentiate them in the competitive APM (Application Performance Monitoring) market.

Compared to competitors like Datadog and Dynatrace, New Relic's Distributed Tracing offers similar core functionality but aims to differentiate through ease of use and integration with their broader platform.

In terms of product lifecycle, Distributed Tracing is in the growth stage. It's a well-established feature but continues to evolve with new capabilities and integrations to meet the changing needs of modern, cloud-native applications.