Last updated 18 Nov 2020

Effective storytelling for internal platform teams

Camille Fournier wrote a post a few months back about the challenges of product ownership for internal platforms. Her observations resonated with me a lot after four years working within an internal platforms organization at Indeed — how hard it can be to establish viable success metrics, how easy it can be to overestimate your understanding of your customers, how challenging it can be to serve a plausibly captive audience.

The post wrapped up with this (emphasis mine):

Great platform teams can tell a story about what they have built, what they are building, and why these products make the overall engineering team more effective. […] Without a clear strategy for showing impact and value, you end up overlooked and understaffed, and no amount of cool new technology will solve that problem.

Effective storytelling turns out to be one of the most important competencies for a platform team to develop. But how do you put it into practice? The exact implementation is going to vary a ton based on the communication norms of your company, but at a high level, here’s what’s worked for me and my teams.

Know your audience #

Effective storytelling starts with knowing your audience, and for an internal platform team, that audience can be broad. You might think about breaking it down like this:

Current users. These are the people who use your product today. They need to know about upcoming changes, and they’re your best partners in identifying new opportunities for your product and sharing your stories with others.
Future users. These are the people who have or will soon have the need your team is charged with meeting, but who haven’t started using your product. You want to make sure they know what you’re working on and how others are benefiting from your current offering.
The leadership that current, future, and former users answer to. Even the most fanatical user base will only get you so far — if you want to avoid the “overlooked and understaffed” fate, it helps to have your users’ leadership singing your praises too. To make that happen, they need to understand how you’re making life better for their teams.
Former users. These are the people who have used your product in the past, but they aren’t using it today. You probably don’t need to communicate with them en masse, but it’s good to be able to reach out to them as needed.
Your organizational leadership. Don’t forget to manage up — your own leadership needs to understand the value you’re creating and the problems you’re solving.

Ascertaining and segmenting the members of your audience — and then keeping those membership lists up to date — can be a challenge, especially in a large and/or rapidly growing organization. As an internal platform team, you should find yourself highly motivated to support efforts to create and maintain machine-readable org charts. You should also invest up front in instrumentation that lets you analyze who is using your tools and how often.

Barring a detailed understanding of who you need to communicate with, there’s always the all-hands mailing list or Slack channel, but at a certain size, communicating this way is about as effective as shouting into the void — even if almost everyone on the list is actually a user. You might be able to achieve results if your message is urgent and broadly applicable, but it’s no way to convey a nuanced, non-urgent update.

Communicate value, not effort #

About once a month for the last year, I sent out an newsletter to stakeholders and users of the platform my team owned. Every month, as I was preparing the newsletter, I would review the tickets that the team had worked on since the last newsletter went out. Every month, I would find myself a little bit surprised that the newsletter’s contents rarely ended up focusing on the work the team had completed.

Platforms, by their nature, tend to have a long tail of value delivery, and the value delivered can be annoyingly difficult to trace back to any single piece of work the team completed. A platform we started building in 2018 radically transformed the iteration speed for a business-critical team in 2020 — allowing that team to achieve some big experimentation wins faster as a result — but we did hardly any work in 2020 that was specifically in support of that team.

So while it’s important that your platform’s users know about new features, communicating about new features isn’t sufficient. In the worst case, it can stir up “what have you done for me lately?” feelings among users who don’t immediately benefit from the new features. Your storytelling strategy needs to put at least as much emphasis on the wins your users are achieving with the help of your platform. Those wins could be operational, like reductions in build times or outages; or business wins, like a set of winning experiments that a team was able to run and analyze faster thanks to your product.

When you’re communicating value, tell stories at the macro and the micro scale, and don’t be too reluctant to focus on outliers. “The business” cares that you reduced build times by 10%, or an average of 1 minute, but the AcmeWidget Team cares that, due to a peculiarity in their setup, your efforts actually cut their build times in half, by 15 minutes. Tell both stories. Get a quote from a dev on the AcmeWidget Team and feature it in your next newsletter.

Get creative in how you communicate #

Slack and email are the obvious candidates for communicating your team’s value story, but they’re just the start. The right venues for communication will depend heavily on your company culture, but here are some things I’ve tried that might give you new ideas:

Newsletters. Don’t just write an email: put in the effort to format your newsletter so it has a clear title, headings, and even images. Make sure it’s readable on mobile devices. Use a consistent subject line across “issues” of your newsletter. Anticipate forwarding: include a footer that tells readers where to subscribe to future issues. Use a mailing list so people can see past issues.
Slack. Have a public Slack channel for customer support. Forward your newsletters there using Slack’s email feature. Use consistent emojis to call attention to important announcements.
In-office advertising. Pre-pandemic, Indeed had large displays throughout the physical workspace, and we ran branded, multi-week campaigns to share platform success stories and invite future users to learn more about our platform.
Internal video podcast. I only did this once, and the primary audience was the team itself, but it was a unique storytelling tool. I can see using this venue a couple-few times a year to interview users, demo new features and use cases, and share your team’s future plans.
Internal presentations. This could be anything from a big tech talk to an ad hoc lunch and learn with a cobbled-together invite list. My experience is that there is enough hunger for understanding what platform teams are working on that I never needed much “permission” to set something up as long as attendance was optional.
Performance calibrations. This is a weird one, but I often found myself sharing my team’s value story during calibration conversations with other managers during the performance review cycle. Obviously this isn’t a primary purpose of calibrations, but it’s a good reminder to be prepared for unexpected opportunities.
Stakeholder conversations. The same artifact that you create for an internal presentation can serve you well for structured conversations with user teams and stakeholders, but it also never hurts to just drop them an email congratulating them on a win you heard about — and to gently connect the dots back to your platform.

Know your lines #

Telling your team’s value story requires having a consistent way of describing 1) why your team exists (your mission), and 2) what’s plausibly at the end of the long arc your team is traveling (your vision). Will Larson does a good job of defining the component parts of a vision and the steps you can take to create a vision document, but you’ll also want a short, pithy version that you can include in communications to your users. At Indeed, my team’s vision boiled down to this:

Product teams building user interface can focus on the unique business value they are trying to deliver; everything else just works.

Our mission was equally simple:

We provide crucial capabilities that allow product teams to build and iterate on user interface — successfully, autonomously, and without regret.

We weaved these words, or echoes of them, through every communication about the work we were doing and why it mattered. They featured in every presentation to the team, to leadership, and to the broader organization. While it’s unlikely that anyone outside of your team will be able to recite your mission and vision verbatim, the constant repetition of the words and themes should serve to establish an ambient understanding of the value you’re providing.

A relentless repetition of your mission and vision also helps your team stay connected with the why of the work they’re doing, which brings us to the next part …

Everyone has a part to play #

Even if you’re so lucky as to have a person whose full-time job is internal marketing — and let’s be honest, what we’re talking about here is certainly a flavor of marketing, and certainly time-consuming — everyone on the team should be able to explain why the work the team is doing is valuable. Engineers, QA, product managers, project managers — everyone should be on the lookout for stories to tell about the value the team is creating. Everyone should be attuned to opportunities for the platform to create new value, in line with the team’s mission and vision.

Succeeding on a platform team will frequently require direct engagement with a larger portion of users than one might encounter on a traditional product team — especially at a company big enough to require a platform team in the first place. The best of these are centered in understanding the value that user is trying to achieve, and in turn help the user understand the part the platform is playing in delivering that value.

Direct user interactions — via support channels, office hours, fireside chats, user research, or any other situation where you’re talking directly to a user or a team — are golden opportunities. Well executed, they cultivate evangelists for your product, people who will help the broader organization understand your product’s value with little effort on your part. Poorly executed, these interactions can do damage to even the best value story.

Make sure your team members see the straight line that connects their users’ success with their own. Highlight user success in team channels, and encourage individual team members to follow up on the usage of the things they build.

Wow, that’s a lot. #

Yes, and I also feel like this barely scratches the surface of the work of telling your team’s story. Unless you do find your team staffed with a person who’s directly responsible for this type of communication, it really does need to be a team effort, and your team’s value story needs to be a regular part of planning and retrospective conversations.

It could be tempting to point at your team’s product manager (if you have one) as the person who should carry most of this weight. Their role here isn’t small, but it’s also not sufficient — especially on a team where other engineers are the product’s customers. Engineers and engineering managers all need to be looking for ways to engage in telling their team’s value story. That doesn’t mean they each need to be a public face of the team, but it does mean they need to be thinking about the why, the measurement, and the communication needs for the initiatives the team is working on. (Relatedly: A platform team might not be a comfortable home for an engineer who just wants to be heads-down in the code.)

If all of this feels overwhelming and you’re looking for somewhere to start, it’s here: make your team’s value story a part of your team’s everyday conversations. Incorporate customer engagement into your planning and development cadence. Encourage your team to ask challenging questions — about the expected value of the work they’re doing, about which customers are expected to benefit, about how customers are thinking about the product. As your team starts to understand how its success is connected with the answers to those questions, the rest will start to follow.