From 1fcc30299ddd1d948d95947c5452d928f653ea76 Mon Sep 17 00:00:00 2001 From: Peter Macdonald Date: Wed, 25 Mar 2026 10:27:46 +0100 Subject: [PATCH 1/4] preparing for GA Signed-off-by: Peter Macdonald --- .../adoption/006-preparing-for-ga.md | 119 +++++++++++++++++- 1 file changed, 115 insertions(+), 4 deletions(-) diff --git a/docs/golden-path/adoption/006-preparing-for-ga.md b/docs/golden-path/adoption/006-preparing-for-ga.md index 6e9db67d65..eb1a6a36c8 100644 --- a/docs/golden-path/adoption/006-preparing-for-ga.md +++ b/docs/golden-path/adoption/006-preparing-for-ga.md @@ -7,14 +7,125 @@ description: How to prepare your Backstage instance for a company-wide general a We hope at this point that the developers you're working with have read the [golden path on deploying Backstage](../deployment/index.md). Your Backstage instance should be ready for the scale that comes with a full company launch. -## Launch Announcements +## Launch announcements - +Getting the word out is one of the most important parts of a successful general +availability (GA) launch. A good announcement does two things: it tells +developers that Backstage is available, and it tells them why they should care. + +### Use your internal comms channels + +Start with the channels your developers already use. Post in Slack or Teams +channels that reach engineering broadly, share a short write-up in your company +newsletter or engineering blog, and send a targeted email to team leads who can +cascade the message to their reports. Tailor the message for each channel; a +Slack announcement can be shorter and more conversational than a written post. + +Lead with the problem Backstage solves for your developers, not with a list of +features. Developers respond better to "you no longer need to chase down +ownership information across five different tools" than "we have launched a +software catalog." + +### Host an internal meetup or demo + +A live demo builds trust in a way that a written announcement cannot. Developers +can see the product in action, ask questions, and leave with a concrete +impression of how Backstage fits into their day-to-day work. + +Keep the demo short and focused. Walk through one or two high-value workflows, +ideally ones that address the pain points you identified during your stakeholder +feedback sessions. Leave time for questions. If the session is recorded, share +the recording in your comms channels so developers who couldn't attend can catch +up. + +Consider running multiple sessions to reach different time zones or teams. +Smaller, more targeted demos for specific teams can be more effective than a +single large all-hands. + +:::tip +Invite a developer from the teams that participated in your proof of concept +(PoC) to co-present. Peer endorsement carries more weight than a platform team +talking about their own product. +::: ## What to expect in the coming months - +The period immediately after GA is often slower than you expect. This is normal. +Developers are busy, habits are hard to change, and adoption takes time to build +momentum. The goal in these early months is not to force adoption but to remove +the friction that prevents it. + +### Listen to feedback early and often + +Set up a clear feedback channel from day one. This could be a dedicated Slack +channel, a form, or a recurring office hours session. Make it visible in your +launch announcement so developers know where to go. The feedback you receive in +the first few weeks is some of the most valuable you will ever get, because it +reflects the real first-time experience. + +Pay attention to the things developers are struggling with, not just the feature +requests. Struggles point to gaps in documentation, confusing workflows, or +missing integrations that are blocking adoption. + +### Use analytics to guide your decisions + +Backstage does not ship with usage analytics by default, but you can integrate +an analytics provider through the plugin ecosystem. Tracking which parts of +Backstage developers actually use helps you make informed decisions about where +to invest your time. + +Look for patterns: Are developers landing on the catalog but not drilling into +entity pages? Is the search feature underused? Are Software Templates being +triggered but not completed? These signals tell you where the experience is +breaking down and where it is working well. + +### Talk to your users directly + +Analytics tell you what is happening. Conversations tell you why. Schedule +regular check-ins with developers across different teams, especially those who +were early adopters. Ask them what they use, what they avoid, and what would +make Backstage more useful in their daily work. + +Short, informal conversations are often more revealing than formal surveys. +A five-minute chat with a developer who almost never opens Backstage can give +you more actionable insight than a month of dashboards. ## How to keep iterating - +GA is not the finish line. The most successful Backstage instances are the ones +that keep improving after launch, driven by a clear process for taking feedback +and turning it into changes. + +### Make decisions based on feedback + +Prioritize work that addresses real developer pain points over work that feels +interesting to build. When you receive recurring feedback about the same issue, +treat that as a strong signal. When feedback is mixed or unclear, go back to +your users and dig deeper before committing to a direction. + +Document the decisions you make and the reasoning behind them. This helps your +team stay aligned and gives you a record to reference when revisiting past +choices. + +### Look for processes that could be improved + +As Backstage matures in your organization, you will start to notice patterns in +how developers interact with it. Some of those patterns will reveal manual steps +that Backstage could automate, or workflows that exist outside Backstage that +would benefit from being brought in. + +Review your catalog regularly. Are entities going stale? Is ownership information +drifting out of date? These are signs that the processes around Backstage need +attention, not the product itself. Work with teams to build the habits and +automation that keep the data accurate. + +### Keep stakeholders informed + +Your leadership and key stakeholders backed this investment. Keep them updated +with regular progress reports that connect Backstage's impact to the outcomes +they care about: developer productivity, reduced toil, faster onboarding, and +improved system reliability. + +Share wins, but also be transparent about what is not working and what you plan +to do about it. Stakeholders who trust your judgment are more likely to continue +investing in the platform over time. From 65f3aa7c3d119df152944078b916997575774516 Mon Sep 17 00:00:00 2001 From: Peter Macdonald Date: Wed, 25 Mar 2026 10:34:33 +0100 Subject: [PATCH 2/4] don't use comms use communication Signed-off-by: Peter Macdonald --- docs/golden-path/adoption/006-preparing-for-ga.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/golden-path/adoption/006-preparing-for-ga.md b/docs/golden-path/adoption/006-preparing-for-ga.md index eb1a6a36c8..1f6daf182d 100644 --- a/docs/golden-path/adoption/006-preparing-for-ga.md +++ b/docs/golden-path/adoption/006-preparing-for-ga.md @@ -13,7 +13,7 @@ Getting the word out is one of the most important parts of a successful general availability (GA) launch. A good announcement does two things: it tells developers that Backstage is available, and it tells them why they should care. -### Use your internal comms channels +### Use your internal communication channels Start with the channels your developers already use. Post in Slack or Teams channels that reach engineering broadly, share a short write-up in your company @@ -35,7 +35,7 @@ impression of how Backstage fits into their day-to-day work. Keep the demo short and focused. Walk through one or two high-value workflows, ideally ones that address the pain points you identified during your stakeholder feedback sessions. Leave time for questions. If the session is recorded, share -the recording in your comms channels so developers who couldn't attend can catch +the recording in your communication channels so developers who couldn't attend can catch up. Consider running multiple sessions to reach different time zones or teams. From 5848bc40e807a08eca1e3cd49e3062ce9b1ebb8c Mon Sep 17 00:00:00 2001 From: Peter Macdonald Date: Wed, 25 Mar 2026 13:35:03 +0100 Subject: [PATCH 3/4] add adoption to the golden paths sidebar items Signed-off-by: Peter Macdonald --- microsite/sidebars.ts | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/microsite/sidebars.ts b/microsite/sidebars.ts index 871fbe09e9..0c290ad6d8 100644 --- a/microsite/sidebars.ts +++ b/microsite/sidebars.ts @@ -86,6 +86,14 @@ export default { ...(process.env.GOLDEN_PATH ? [ sidebarElementWithIndex({ label: 'Golden Paths' }, [ + sidebarElementWithIndex({ label: '000 - Adoption' }, [ + 'golden-path/adoption/getting-started', + 'golden-path/adoption/leadership-buy-in', + 'golden-path/adoption/setting-up-a-poc', + 'golden-path/adoption/first-stakeholder-feedback', + 'golden-path/adoption/customizing-your-instance', + 'golden-path/adoption/preparing-for-ga', + ]), sidebarElementWithIndex({ label: '001 - Create an App' }, [ 'golden-path/create-app/index', 'golden-path/create-app/npx-create-app', From 1b8d4be5df137ccbbed9180f47a96a3862488964 Mon Sep 17 00:00:00 2001 From: Peter Macdonald Date: Wed, 25 Mar 2026 13:56:48 +0100 Subject: [PATCH 4/4] reference analytics docs in prepping for ga and remove the dead links to ga from analytics plugin docs Signed-off-by: Peter Macdonald --- docs/golden-path/adoption/006-preparing-for-ga.md | 2 +- docs/plugins/analytics.md | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/golden-path/adoption/006-preparing-for-ga.md b/docs/golden-path/adoption/006-preparing-for-ga.md index 1f6daf182d..0c6b820dbb 100644 --- a/docs/golden-path/adoption/006-preparing-for-ga.md +++ b/docs/golden-path/adoption/006-preparing-for-ga.md @@ -70,7 +70,7 @@ missing integrations that are blocking adoption. ### Use analytics to guide your decisions Backstage does not ship with usage analytics by default, but you can integrate -an analytics provider through the plugin ecosystem. Tracking which parts of +an analytics provider through the plugin ecosystem, you can find more information on this in the [Analytics](../../plugins/analytics.md) section of the Backstage documentation. Tracking which parts of Backstage developers actually use helps you make informed decisions about where to invest your time. diff --git a/docs/plugins/analytics.md b/docs/plugins/analytics.md index a758d63ebe..784895ef49 100644 --- a/docs/plugins/analytics.md +++ b/docs/plugins/analytics.md @@ -42,7 +42,6 @@ choice below. | Analytics Tool | Support Status | | ------------------------------------- | -------------- | -| [Google Analytics][ga] | Yes ✅ | | [Google Analytics 4][ga4] | Yes ✅ | | [New Relic Browser][newrelic-browser] | Community ✅ | | [Matomo][matomo] | Community ✅ | @@ -53,7 +52,6 @@ To suggest an integration, please [open an issue][add-tool] for the analytics tool your organization uses. Or jump to [Writing Integrations][int-howto] to learn how to contribute the integration yourself! -[ga]: https://github.com/backstage/community-plugins/blob/main/workspaces/analytics/plugins/analytics-module-ga/README.md [ga4]: https://github.com/backstage/community-plugins/blob/main/workspaces/analytics/plugins/analytics-module-ga4/README.md [newrelic-browser]: https://github.com/backstage/community-plugins/blob/main/workspaces/analytics/plugins/analytics-module-newrelic-browser/README.md [qm]: https://github.com/quantummetric/analytics-module-qm/blob/main/README.md