Builder Bella - JTBD Canvas
| Component | Description |
|---|---|
| Job Statement (Core JTBD) | When building and deploying new features in a distributed service, I want to instrument my code easily and understand its runtime behaviour, so I can ship quickly, debug efficiently, and avoid production surprises. |
| Functional Jobs | • Add OpenTelemetry instrumentation with minimal complexity • Understand performance and errors introduced by new code • Validate that telemetry is flowing and complete • Reproduce and debug customer issues faster • Adopt consistent patterns for logs, metrics, and traces • Use templates and tooling to avoid repetitive setup |
| Emotional Jobs | • Feel confident shipping code without fear of breakage • Reduce stress during debugging and performance investigations • Avoid feeling overwhelmed by tooling complexity |
| Social Jobs | • Demonstrate engineering excellence to peers and leads • Collaborate smoothly with SREs and service owners • Contribute clean, observable services to the wider system |
| Pain Points / Struggling Moments | • High learning curve for observability tools • Inconsistent or missing telemetry in services • No clear examples or templates for instrumentation • Noisy or overwhelming debugging experience • Dashboard + alert fragmentation • Manual, repetitive setup for instrumentation and dashboards |
| Desired Outcomes | • Reliable instrumentation by default • Faster debugging and issue resolution • Clear visibility into how new code behaves • Standardized patterns across teams • Reduced reliance on SREs for support |
| Success Metrics | • Reduction in code-to-production time • Time saved on debugging and instrumentation • % of services instrumented with standard templates • Fewer production regressions • Increased adoption of OTel SDKs and platform tooling |
| Drivers | • Pressure to ship quickly • Need for reliable, maintainable services • Growing complexity of microservices and distributed traces |
| Constraints | • Limited observability expertise • Fragmented ecosystem of tools • Limited time to learn new systems • Inconsistent guidance across teams |
| Opportunity Areas | • Auto-instrumentation defaults • Language-specific OTel starter kits and example repos • Development-time instrumentation validation • Debugger + trace integration • Pre-built dashboards and alert templates • Clear signal naming conventions and best-practice patterns |