As a Product Manager, you probably won't use Backstage to manage your product backlog the way you'd use Jira, Azure DevOps, or GitHub Projects. Its value to you is different: it shows how the product you manage maps to the actual technology being built and operated.

Think of it as:

  • GitHub Projects / Jira = what are we building?
  • Backstage = what actually makes up the product, and who owns it?

A worked example

Suppose you manage a customer portal. In Backstage, that product might be modeled as:

CUSTOMER PORTAL
│
├── Website
│   └── Azure Web App
│
├── Customer API
│   ├── Customer Details API
│   ├── Billing API
│   └── Investment API
│
├── Market Data Service
│   └── Stock Price API
│
├── Database
│   └── Azure SQL
│
└── External Dependencies
    ├── Billing Provider
    └── Market Data Provider

As a PM, you can open any of those components in Backstage and see who owns it, which repository contains it, its documentation, its APIs and dependencies, its deployment/CI status, its operational health, and — depending on which plugins your organization has installed — its security posture.

Why this matters when planning work

Imagine a feature: "Allow customers to see the current value of their investments."

Your backlog and user stories still live in GitHub Projects. But Backstage lets you trace the dependency chain:

Feature → Customer Portal → Investment API → Market Data Service → external stock-market provider

That turns into a much sharper conversation with engineering: "This feature touches the portal, the Investment API, and Market Data Service. The Investment API is owned by Team A, Market Data by Team B." That's a powerful capability for a PM operating in a large organization.

Beyond planning: spotting technical debt

The same visibility that helps with feature planning also helps with platform-product management. You can surface things like services with no documentation, components with unclear ownership, APIs still on older frameworks, missing monitoring, failed builds, or services that haven't adopted your organization's preferred deployment process.

If you're a Platform PM

If you're a Product Manager for an Engineering Platform specifically, Backstage becomes even more relevant — you're no longer just using it, it can become part of the product experience you're responsible for. Your customers are developers, and you can measure things like onboarding time, adoption of golden paths/templates, documentation coverage, service ownership coverage, deployment experience, and developer self-service.

What Backstage actually is (a quick correction to myself)

I'll admit I went into this half-expecting Backstage to be about OS versioning or patch management — it isn't. Backstage is an open-source developer portal framework, originally built at Spotify and now hosted by the Cloud Native Computing Foundation (CNCF) as an Incubating project. It's not a SaaS product you log into — it's a Node.js/React application that platform teams deploy into their own infrastructure and configure with plugins.

At its core is the Software Catalog: a centralized repository of every software building block in an organization — services, APIs, websites, libraries, data pipelines, even ML models — along with their ownership, lifecycle, and relationships. Two other core pieces build on top of that catalog:

  • Software Templates, for spinning up new projects in a standardized, self-service way
  • TechDocs, for keeping technical documentation close to the code using a "docs like code" approach

Everything else in Backstage — scorecards, dashboards, plugins — ultimately reads from that catalog. Which is also why catalog hygiene (accurate ownership, up-to-date entity data) tends to be the single biggest predictor of whether a Backstage rollout actually succeeds.