Building an Internal Developer Platform (IDP) is an intelligent way to set your organization on track for better alignment and heightened efficiency. But not everyone on your team will see the benefits right away— or ever — unless you’re diligent about promoting feature adoption.
How does this look at a large organization with multiple independent business units and no shortage of opinions on how to do DevOps?
Brian Dorsey, Director of Platform Product Management at Mastercard, shared his experience-driven take in a talk for PlatformCon 2023. Here are the details on how the Mastercard platform team won hard-fought converts with data, some different ways to pitch to product teams, and how to set viable milestones for feature rollouts.
The extent of the problem
According to Brian, Mastercard isn’t just a credit card company. Organizationally, it’s divided into several diverse business services, including units focused on web apps, data products, and consulting.
Brian’s team, the data and services technology foundation group, was responsible for building a unique IDP. The platform needed to supply devs with the foundational services and infrastructure required to build products at speed, bring them to market quickly, and sustain high levels of UX quality throughout.
The example case
Naturally, a mission of this scope takes a lot of doing. Brian chose to focus on just one of the components in this process, Mastercard’s design system, Graphite.
Graphite functions as a kind of internal analog to tools like Material UI. It consists of reusable frontend patterns, processes for creating, consuming, sharing, and maintaining those patterns, and a platform that delivers the infrastructure to accomplish it all.
What makes a design system such a good example of successful platform engineering? Part of it has to do with the project’s expansive goals.
Graphite was intended to ensure the Mastercard product suite looked and felt modern while allowing cohesive design at scale. The company also wanted to create a common front-end design language that project managers, designers, and engineers could all leverage. This would lower learning hurdles for customers and help dev teams boost their rate of progress by eliminating work duplication.
Looking at the bigger picture, the team realized something important: Achieving the stated goals would be impossible without broad adoption of the design system. Brian gave the example of usability — customers would fail to learn independently if the pages they visited were inconsistent, so all of the product teams had to be on one page.
Promoting adoption would also have internal benefits. For example, the team noticed that although incremental progress was possible, network effects could advance the transition. For instance, increased adoption raised the odds that teams would answer each other’s questions and build mutually beneficial cooperative relationships.
The typical path to platform feature adoption
Not all feature adoption journeys are easy. Brian said that in many cases, things unfold following a similar pattern.
First, the platform team does the upfront work. This is everything needed to enable, integrate, and otherwise bring features to life. You know, the magic behind the curtain.
Next, platform engineers must tackle the huge challenge of getting other teams on board. In other words, the roadshow of convincing people that adoption is worthwhile.
Presentation is everything throughout the journey. According to Brian, platform engineering teams need to be simultaneously intentional and cognizant of their messaging. If they don’t, other teams might see their adoption requests and new features as potential hindrances instead of changes that help them speed up.
So what should your platform team expect? Many adoption journeys take the form of a three-phased s-curve:
In phase one, your objectives are to validate, experiment, and prepare to scale. At this point, reaching an internal consensus will be among your biggest challenges. The majority of the promotion you’ll do here will target close collaborators and the teams with the most skin in the game.
During phase two, you’ll expand your horizons. At this point, you’ll have achieved broader adoption, so it’s the ideal opportunity to make progress on your platform-wide outcomes. At the same time, you’ll still have to engender buy-in, scale smoothly, and support more diverse use cases.
In the final phase, you’ll pursue ongoing value — you want to overcome diminishing returns and ensure the feature remains valuable for existing adopters. This is typically where you’ll address the toughest use cases and last resisters.
It’s important to note that adoption s-curves aren’t all the same. As Brian put it, sometimes the 80-20 rule applies: you’ll eventually have to consider whether making a heroic push for the final holdouts is worth the titanic effort. In other cases, like when you’re deprecating old features, getting to 100% is an absolute must.
Phase two challenges
As the s-curve implies, most of your adoption happens in phase two. According to Brian, what you’ll do during this stage is distinct from the other phases, making it worth a closer look.
One of the biggest phase two hurdles is that you’re trying to get people to change their behavior. In other words, technical work is a given, but you also need to leverage your soft skills, like persuasion and communication.
Teams might also stumble here because they’ve got to exchange their engineering hats for their product manager hats. You have to take the time to discover where users’ pain points and concerns lie — otherwise, you’ll fail to communicate how your feature solves them.
The Graphite adoption journey: Phase one
Brian described how Mastercard’s Graphite exemplified the s-curve even though it sometimes deviated from traditional platform lifecycles. For instance, when Graphite started, it was completely grassroots, and no platform team was involved. Three product teams just happened to realize they had something in common — they were all building apps focused on raising UX quality. Why not collaborate?
Eventually, three more teams joined the closed beta. Around this time, the product teams got a platform team involved to centralize effort and implement a dedicated maintenance structure.
Brian also pointed out that adoption wasn’t a concern at this point, validation was the biggest objective. In fact, the platform team actually turned some adopters away because the product wasn’t ready to scale or their needs weren’t aligned with its existing features.
Despite the beta’s closed nature, product managers like Brian would still liaise with other prospective adopters to conduct vital user research. This set the stage for phase two and informed the developers about an important question: What KPIs should they be measuring and periodically sharing?
As development went on, the team shared their KPIs with a wider audience. This both raised awareness and provided feedback indicating when it was time to move to the next phase.
At each measurement stage, the team took others along by explaining the journey. Yes, they’d share what they discovered internally. But they’d also explain the feedback they’d received, the steps they’d taken to improve, and how Graphite was impacting those who’d already transitioned.
One of Brian’s big mantras during this time was: “Don’t change what you work on, just change how you do your work.” In other words, adopters shouldn’t use the new design system just for the sake of using it. Instead, they should layer it into the tasks they were already undertaking in pursuit of workflow improvement.
Phase two of Graphite’s adoption: Picking a pitch style
After getting a handle on user needs and validation, it was time to drive adoption. But the Graphite team had to decide how to pitch their work. There were a couple of viable options:
The Platform-centric Pitch — convincing people to adopt based on platform-level objectives
The first pitch option focused on the platform itself. According to Brian, however, this strategy had its flaws.
Selling the system’s goals — like having a common design language and enhancing customer ease of use — would most likely be easy. But it might not be enough to sell the platform and get teams to prioritize adoption when they could be accomplishing other tasks. Even worse, it could create the perception that the platform (or the platform team!) slows work down by constantly bringing up new factors that push deadlines out of reach.
The Product-centric pitch — convincing people adoption would further their existing goals
The second pitch option centers the focus squarely on the users’ needs. It frames adoption in terms of the things teams care about and then communicates how the transition would bring those goals closer to fruition. In a best-case scenario, users will view migration as a way to accelerate their processes and walk away feeling like their needs are being supported.
Once again, this phase is all about perception and framing. The reality of adoption is complicated, and most journeys land somewhere between the two options. Your messaging needs to adapt realistically.
The tipping point came when the platform engineers found a team that owned the core workflow of Graphite’s flagship products. If they could convince this team to adopt, they’d make a definite impact, but if they failed, it would spell catastrophe for a ton of users.
So what did the platform team’s leaders do? Simple. They talked with the prospects to truly understand their workflows and concerns.
Taking the extra time paid off: When the big prospect adopted Graphite, it self-reported that it decreased its workflow median time by 50% and that the new design system was responsible. As you’d expect, this success story became a selling point in itself!
The final message
Today, Graphite is in phase three, but the team hasn’t slacked off by any means. They’re still taking measurements and working to get the final holdouts onboard. Brian offered a few key conclusions to keep in mind no matter where you are in your adoption.
Always work to present your pitch in terms of customer priorities. Do the user research required to understand what people care about. Communicate that you appreciate people’s priorities using real data that validates your work.
Brian maintained that a solid product mindset can help you determine what to leave on the cutting room floor. You might create a feature that doesn’t fit the framing and isn’t driven by an external force like governance requirements. Be willing to reassess the time you’re spending — and whether you should even be selling that feature to other teams!
Lastly, intentfully break each rollout into its own separate parts. A rollout’s phases shouldn’t just be independent in name. They all entail different types of work, so be proactive and intentional in quantifying how you approach them.
Brian dished out a lot more knowledge in the Q & A section, including how to deal with unexpected use cases and decide what to standardize or leave configurable. Watch the video to discover how these lessons might apply to your next feature rollout, and stay tuned for more from PlatformCon 2023!
.webp)
