Building for scale – 5 lessons learned on building platform services

I wanted to write about my past 12 months working on Atlassian’s platform team. I’ve been on the both sides of the fence. 12 months on product and 12 months on platform. I was previously a product manager for Confluence Mobile and now I’m a product manager for Mobile Platform.

To set some context, I love working on products. That’s what product managers love to do. When you’re a product manager for a product, you work on one specific product or stream of work. You go deep as you work on product depth. You focus on a vertical. On Confluence, I thought a lot about how customers create content, how they collaborate on content, on the page viewing experience. I could work all day on the design of comments which I still believe is fascinating. Should the comments be stacked, threaded, threaded and teased with a short snipped of text, or threaded capped with only the first and last comment?

When I joined the mobile platform team, I wasn’t sure what to expect. As I’ve only worked on products. By way of background, a platform team builds common services that products consume. The platform provides the building blocks for the products. They can use our login service, UI, analytics, feature flag, developer tools and other standard components. It allows the products to focus on core product value. They can focus on what makes their products unique and differentiated, whilst leveraging the scale of the platform. On the mobile team, we ship an SDK on a weekly cadence. The products integrate with the SDK. I’ve worked on projects such as the new mobile login which 3 of the Atlassian mobile apps use on iOS & Android.

Now that I’ve been on the platform team, I understand that I have to be broader. I must be horizontal as I have to consider how a service will work across various products in our portfolio (JIRA, Confluence, Stride) and also future products.

I recognize that many people haven’t had platform experience or come across the concept of platform. I have a very unique experience having been on both sides. I wanted to share that experience and the lessons learned. As the majority of product folks I know have worked on products. Its when a business is at scale that it invests into building a platform. You leverage scale to build businesses. Its also exciting to be on a platform team because its something I haven’t done before. In my opinion its really hard in the early days and that is also why I wanted to share it. Here is my experience so that it may help you understand what’s involved.

1. Align on product & platform priorities

When you are in a platform team, you’ll get a lot of requests. These come from product teams, platform teams, management and customers (via the first three groups). Its fine to get requests, even lots of them. This is normal in any product team. The same principles apply. Have a way to receive feedback and give feedback. Thats important for customers and stakeholders.

I found that setting the vision and roadmap helped communicate to internal teams why we’re doing something and why we’re not doing something. I said no a lot but I didn’t tell people why. I felt that once people understood the why and where we were heading as a platform team, they understood why we couldn’t do a particular request. Its because we’re building this platform that’s going to help us go to moon/next stage/milestone. That’s why we can’t do this small feature request now or why it doesn’t fit in with the vision. The product teams need to buy into that vision.

I’ve seen that if product and platform team priorities don’t align, this can be problematic. We need to be rowing in the same direction. Building for platform is a tricky game. We’re sometimes behind the product teams as they can move much faster. We need to take into account the needs of various products including future products. We are making changes that affect all products and we may need to work with other platform teams. There are ways to solve this problem which I discuss below.

I believe in this American Indian proverb which one of our Co-CEO quotes: “if you want to go fast, go alone. If you want to go far, go together”. We do a lot of roadmap alignment exercises and check-ins. This helps to have both groups have aligned priorities and that we deliver things in a timely manner. If can deliver platform value to customers, then we’re going to go far.

2. Align on customer value

The way I prefer to work and how i’ve seen it work well is where both groups align on customer value. Our customers are your customers. As in the end user is the customer. The platform team doesn’t serve the product teams. We all serve the end users (long live the users!). This is not the easiest thing to understand as it can be hard to define customer value for internal platform teams. I believe to truly build a platform, you can’t be an order taker. Product teams are an important stakeholder. But a platform is not a consultancy. We’re building something for all the users and for the future of the business. Hence its important to align on customer value. We need to be able to express what we’re doing in terms of customer value. Thats why we get our platform engineers to talk about their work in terms of customer value. Its why we advocate for customer facing metrics. For my team its the activation rate (first time login on mobile login). You might have an internal metric as well which is fine. But its important to have a customer metric if possible to align everyone.

3. Push vs pull strategy

As you mentioned above, you can’t be an order taker. But you can’t build things in isolation either. You need to build things that CUSTOMERS want and products want to adopt. We need to build useful things. We don’t want to have an inventory of stuff that never see the light of day. That’s wasted effort. Hence the alignment of priorities and understanding of customer value is critical.

It needs to be a dynamic of push and pull. We push the platform mission and agenda. The products pull from the platform in the other direction. It can’t be 100% pull or 100% push. Otherwise you’re probably building ad hoc stuff that may not make up a platform and doesn’t truly deliver the value of a platform. Or you have a huge inventory. Like all things in life, its a delicate balance.

4. Build a minimum criticizable product to find product/platform fit

We found that in the past, the product teams are very focused on their mission. Its head down, focused on a particular silo. I was the same. I didn’t know what was happening in platform teams and couldn’t make their meetings. I didn’t have time to read all this documentation coming out of there. Even though I knew it was important. Its tough. Hence the alignment of priorities is critical.

We use to write big upfront documentation. Some people gave input but the majority didn’t look at it closely. Then we would spend months building something. Then throw it over to the fence to the product teams to integrate. When integration started or when we would meet with teams, we’d hear that we’d missed some critical requirement. We may have ended up building it in a way that they couldn’t use easily. Product integration became really painful.

We decided to change this up and work more like a startup looking for product/market fit. We would build a “minimum criticizable product” (aka MCP). Our deliberate intention is to build incrementally and deliver the classic startup “MVP”. I call it “criticizable” because what we’re looking for is feedback from the product teams. We want to give them the smallest piece possible that they can play with to start giving us feedback which we can then iterate on. This has an advantage in that now the product team can actually use it and pay attention to it.

This is the moment when the rubber hits the road. Our aim is to get to this learning moment as early as possible. The earlier we can integrate, the better. We want the integration to be as tight as possible from when the platform delivers to when the product team integrates. This enables us to get feedback early and iterate to get closer to product/platform fit.  It can be tough to co-ordinate because products can have differing priorities and may not be able to test it ASAP.

We changed from doing the heavy upfront documentation which no one paid attention to because it wasn’t tangible. Now we deliver the following:

1. Minimum Criticizable Product with incremental milestones

2. Lightweight tech spec which provides sufficient detail

3. Integration document which is a Confluence page which has details on how to integrate and what they need to do. There’s also checkbox next to each product owner to let us know if they have integrated.

I understand that not all platform services can be built this way. Sometimes these can be journeys that can take a year or years. I’ve found in my experience that breaking it up into incremental delivery milestones and producing the MCP has helped us achieve our goals.

5. After you build a service, you need to run it!

After you release a service into production, products and customers rely on it. This is even more critical for a service like login. Like all new services and products, we had some issues when it was first released. When a service enters into production, there may be new bugs discovered which we hadn’t come across in our testing. We learned that we needed to reserve time for integration AND to harden the service. Your first release is never perfect and you need to keep improving it.

When we learned of some of these issues, we added more analytics into our analytics platform. We also hooked up real time alerts using Pagerduty. This gave us more oversight into what was happening and real time dashboards. There is now a rotating roster of people that get messaged if the service hits a certain threshold. We get early warning signals which triggers us to look into it. When this happens, we diagnose, learn and improve the service. This is the process of hardening and maintenance. Building a service is half the battle. Maintaining it and making it run smoothly is a skill. Ensure you have a block of time for hardening and have plans to maintain the service.

If you have any experience in building for platform or consuming platform services, I’d love to hear your feedback!

I’m out like the Black Panther,

Matt Ho.