Applying Product Thinking to Slack’s Internal Compute Platform

Platform Engineering Needs Product Thinking

Industry guidance from Thoughtworks and Team Topologies increasingly points to a simple truth: internal platforms only deliver value when they are treated as products with clearly defined customers. Platform teams, as Skelton and Pais put it, exist to provide “a compelling internal product” that accelerates delivery for stream-aligned teams.

At Slack, applying that product mindset to our internal compute orchestration platform — code-named “Bedrock” — has been a multi-year effort. The platform lets developers build code, package it into Docker containers, and allocate compute resources, all configured through a single bedrock.yaml file.

Bedrock intentionally curates Kubernetes features and layers on guardrails and automation to make production-grade service launches simpler and more productive. It abstracts Slack’s broader infrastructure ecosystem — including CD pipelines, container build and deploy, service discovery, secret management, and an encrypted mesh network — so developers don’t need deep expertise in Kubernetes, Jenkins, Consul, Vault, Envoy, or Nebula. Configuration drops from hundreds of lines to tens, feedback loops shorten, and guardrails cut down on configuration errors.

Staying Close to Internal Users

Treating Bedrock as a product means continuously engaging with the developers who build on it. We’ve used several mechanisms to stay close to their needs.

User Experience Interviews

Our user base and its usage patterns have evolved as the platform has matured, so we conduct regular UX interviews to learn how engineers actually work. The first round asked a deceptively simple question:

“Show us how you add a line of code to your service and release it all the way to production.”

The answers dismantled our assumptions. Teams vary widely in their workflows depending on experience with the platform, containerized applications, and the technologies they use. A Java team works very differently from a team deploying a third-party application. Dependencies matter heavily: teams dependent on other internal or external services, or on where data is stored, face meaningfully different friction points.

Some teams can test a single-line change in minutes. Others spend hours every week standing up dependent services. We heard everything from “I’ll open an SSH tunnel to our integration database from my laptop” to “I’ll fire up a docker-compose that brings up a database that takes 35 minutes to boot and load a test data set from S3.”

Those interviews directly shaped our roadmap. One resulting feature was a new flag in our CLI that lets developers spin up any number of dev environment copies using local code — saving hours on initial tests and enabling quick prototyping.

Surveys and NPS

We also rely on periodic surveys. Using Polly, we sent a Bedrock survey to everyone in the #announce-bedrock and #devel-bedrock Slack channels.

Regular survey responses help set priorities. While pushing adoption from older deployment systems, we used surveys to find the most common blockers and then prioritized platform changes to remove them. Surveys also surfaced low-effort fixes that engineers could knock out quickly, giving users fast visible responses to their feedback. One such fix addressed a logging deficiency that made the service bootstrap process fail silently; we also added hints to configuration error messages, pointing users to dashboards or log aggregation with guidance on fixes.

Our NPS journey brought a key lesson: the devil is in the details. Initially, we surveyed everyone in the organization. That produced responses colored by perceptions of the platform team or other services — or by a simple lack of interest in containers. The feedback on what would entice people to try the platform was valuable, but once we narrowed the survey to actual users — people who had attempted to build or deploy something — the signal changed entirely.

Dogfooding

To grasp the highs and lows of your own product, you should use it constantly. Slack-the-product has “Dogfood,” an internal-only alpha release every employee uses. Bedrock lacks that polished dogfooding vehicle, but we do run our own internal services on top of the platform for firsthand experience. A development tier lets us roll changes out to dev and pre-production clusters before touching production.

Bedrock Advisory Group

Many external products lean on a customer advisory board to shape direction. Ours is the Bedrock Advisory Group — a subtle rename to avoid confusion with Change Advisory Boards.

We asked teams across the organization to nominate representatives who attend monthly meetings, voice their team’s perspective, and share information back. We deliberately reserved spots for specific voices:

• Someone new to the platform
• Someone who has voiced concerns or was hesitant about the platform
• A senior technical leader (principal or architect)
• Executive sponsors, including our SVP of engineering and Senior Director of Product

Each meeting follows a loose structure, with room for members to propose their own items:

• News: what the platform team is working on, new features, adoption and NPS tracking
• Roadmap: what’s in the pipeline and whether priorities are right
• User stories: one or two teams share how they use the platform — success, friction, and what would have made things easier
• Feedback and questions: open debate on topics like slowing deployments to maintain Service Discovery consistency

Recordings of each session are shared broadly so anyone can consume the content on their own time and channel feedback or questions through their representative.

Training and Documentation Gaps

Slack’s engineering org is distributed, so classroom training isn’t practical. We instead created a self-guided “hello world” example covering the most common platform tools, plus a video set introducing core concepts and walking through use cases.

Documentation is a known area for improvement. It works well for people with some domain expertise, but it can be hard to navigate and hard to discover for newcomers. We’re exploring Backstage as a way to centralize developer tooling and documentation, and we recognize the value of creating content that functions like the marketing pages of commercial products to accelerate onboarding.

Promote New Features Inside the Product

Visibility is critical in a platform like this. We built a web portal called “Gaz” where engineers check on services, see where they are deployed, and review status. New Bedrock functionality gets reflected there, but we also push features proactively: an engineer created a prompt when users work with a particular pod to try Debug Actions. These are approved commands defined in bedrock.yaml, runnable from the Gaz interface itself.

We’ve seen similar prompts from the command line prove effective, reinforcing that the product mindset is not just about the interfaces we build but about how we invite people to use them.

Treating Engineers as Customers

Building an internal platform is as much about adoption as it is about architecture. At Slack, the team behind the internal compute platform found that applying product management principles to their internal offering was key to its success. This meant shifting focus from simply shipping infrastructure to actively listening to the engineers who use it every day. By treating these developers as customers, the platform team could better prioritize features, improve usability, and ultimately increase satisfaction.

The approach relied on a mix of qualitative and quantitative feedback loops to understand user needs. Key among these were user experience interviews and user surveys, which were used to track the platform's NPS (net promoter score). To provide a structured channel for ongoing dialogue, a user advisory group was established. This group serves as a forum for the platform team to showcase new capabilities, align on the product roadmap, and for users to voice concerns or suggest improvements.

From Development to Adoption

Before a new feature reaches a wider audience, internal dogfooding proved to be a valuable validation technique. This process allows the platform team to identify and fix bugs without disrupting workflows for the broader engineering organization. Once a feature is stable and ready, a more effective path to wider use is to promote it from other parts of the product. This contextual introduction helps users discover functionality naturally as they interact with the platform.

Strong adoption also hinges on how easy it is for users to learn the system. Investing in good documentation and marketing materials significantly lowers the barrier to entry. For Slack's globally-distributed engineering teams, self-paced training and video materials have proved especially effective, allowing developers in different time zones to onboard at their own pace.

This initiative is still evolving, and the team plans to apply the same level of product thinking to more internal tools moving forward. The aim is to enhance the overall developer experience and make the day-to-day work of engineers across the organization better.