The Journey of Transforming an Internal Tool into a Business Operations Platform
As Square grew from one credit card reader into a platform of products, what started out as a simple admin tool also grew organically into a behemoth monolith. After 10 years, this internal tool supported thousands of daily internal users across countless teams, but nobody could explain exactly what the tool was providing.
The system provided different functionality for different customers and the total scope was far greater than the internal team’s staffing capacity. The system into a shared codebase to allow product teams to self-build integrations faster. However, working in this legacy codebase was an arduous experience and product teams continued to view any integration as a major drawback. This led to great amounts of confusion and frustration from both sides. This was the state of the team when I inherited it.
In addition to bringing engineering management strategies to help the internal team organize and execute, I also leveraged product management frameworks to drive alignment internally and externally. This included the following:
- Clarify the problem statement(s)
- Establish the mission, create a vision, and determine the strategy to solve these problems
- Differentiate the customers and tailor the communication
- Define goals and metrics based on the mission to measure progress and success
Following these steps helped me streamline and motivate the internal team and drastically improved our communication, collaboration, and recognition across the company. These frameworks (coupled with efficient engineering management and execution) helped our ambiguous internal tools team grow from being a reactive group that struggled with keeping the lights on/meeting customer demands into a proactive, forward-looking platform.
What is the problem?
First and foremost, start by identifying the problem. Coming from an engineering background, my team has a tendency to jump to solutions. The problem with this approach is the lack of empathy with the listener. Everyone is coming from a different perspective. In order to communicate effectively, both sides must be on the same page and the best way to do so is by aligning on the problem. If the customer does not feel any pain around the same problem area, this would be a good time to pivot.
When my team described our platform in the past, we would jump directly to talking about a shared codebase that all engineers contribute to in order to enable operations teams in their jobs. Even though this description is not wrong, this communication approach made very little sense to most people. Engineers were lost in conversation because they were not familiar with how business operations teams function. Operations agents (ie customer success, risk, compliance, legal) who use the tools didn’t understand the codebase and what parts were shared so they had no idea which engineering team to engage to help them set up their customizations on the platform.
Ideally, each team has one problem statement. What complicated my team was the fact that we were simultaneously tackling two separate but related problems. (I ultimately split the team along these problem areas, but more on this later.) Square’s Business Operations Platform solves 2 problem areas for the company:
- Connecting the ecosystem of Square product data: Square’s data is decoupled and decentralized across hundreds of services. It is extremely challenging to retrieve data that span multiple product lines and understand the connection between them.
- Enabling Business Operations: Business operations have numerous orgs that support products in all aspects of their lifecycle. Agents need (1) a place to view prioritized data, make sense of it, and make decisions, and (2) a way to organize and streamline workflows to increase the capacity of their teams.
What is the mission, vision and strategy to solve the problem?
Once there’s agreement on the problem(s), The first step in our platform journey was to achieve internal alignment. Before we figured anything out, the team knew they were doing important work, but it was unclear what the impact was. I used the Mission/Vision/Strategy framework to analyze our work. This brought the team together and gave everyone motivation to collaborate towards a north star:
The Mission answers the question of why does the team exist? What problem(s) are being solved?
The Vision illustrates an image of what that solution looks like in X years. There are different visions at different time intervals.
The Strategy answers the question of how does the team go about achieving this vision?
Even though the original team tripled in size, the platform was doing too many different things. This isolated engineers on their own project and compromised cohesion. With better clarity around our mission, vision, and strategy, we used our newly-formed boundaries to split the team into two — each to focus on one problem area and one set of customers. This change allowed each sub-team to prioritize and focus on their respective problem and customer, therefore ameliorating collaboration, communication, and execution. Our externally-facing story is an abridged and illustrative narrative of what we came up with using this framework!
All of our offerings empower product engineers to focus on building great external-customer experiences while we support back office teams to keep Square safe, work more efficiently, and scale our business lines.
Our mission is to help Square make decisions. We created a vision that broke down into specific solutions that addressed each of the problem statements listed above.
- To solve the data connectivity problem, we provide engineering patterns to help product engineers model their product data and relationships in the Square ecosystem and expose it through one unified API.
- To support Business Operations, we have two product offerings built on top of the API. One for viewing data and making decisions and another for organizing and streamlining team workflows. These products require product engineers to build some customizations to tailor the solution for their target ops teams.
The strategy we landed on is to partner with product engineers to customize the platform for end-user operations customers. A different, but also valid strategy, would be to build all business operations customizations from one centralized team reducing the need of customizations. The reason we chose our strategy over the latter is to focus internal team time on multiplier improvements. Using a platform strategy allows us to scale more effectively with the rest of the company.
As a tip — make sure to talk about timelines and roadmaps as the solution space encompasses not just the end goals but also the immediate improvements. It’s important to note that both the problem space and their equivalent solutions are constantly evolving and changing. Update and share your story often and frequently!
Who are the customers and how do you communicate with them?
With our story figured out, we needed an effective way to communicate this information to our customers across the company. Different customers have different challenges and needs. As previously mentioned, aligning the listener to the problem area they’ve struggled with is a great place to start. While the underlying content may be the same, the messaging can be wildly different.
One problem my team ran into in the early days was not communicating effectively with any type of customer. The internal team told the same complete platform story to everyone regardless of their role and function. This led to situations where operations customers started using technical terms to describe the changes they wanted to see in the product, leading to their actual pain points being overlooked. Product engineering partners would be confused by which part of the codebase they owned and what ownership entailed. The direct line of management knew the team was “keeping the lights on” but had trouble seeing any progress and direction.
Distinguishing the different customer groups and defining how they interact with the platform helped us scope down and tailor targeted, comprehensible messages to each individual. On our platform, we have:
- Engineering partners include product engineers who build with us in 2 ways:
(1) connect their product data and define the relationships, and
(2) build customizations on top of our generic operations-focused products for a specific task (ie, a compliance bad-actor screen)
- Operations customers include agents who use our operations-focused products on a day-to-day basis, as well as leads who use our tools to analyze and improve team efficiency.
- The direct line of management includes leaders who fund and support our teams with people, guidance, and love.
While our story stays the same, how we framed this story with different people varied greatly. We tailored the content to these customers based on what helps them:
- For the engineering partners, we described the architectural direction of the platform (i.e. which functionality was broken out of the shared monolith to achieve better clarity around ownership).
- For the operations customers, we focused them on product-usage information such as release dates for new features and advantages of using the tools.
- For the direct line of management, we shared our execution roadmap, timelines, and metrics for how we measure progress and success.
Telling everyone the whole story is time-consuming, extremely confusing, and buries the relevant information. Defining the different customer groups and finding the most effective way to communicate with each group makes sure the messages are well-received by all parties.
What does success look like and how do you measure it?
Last, but not least, we needed a way to measure success. Being an internal platform makes this quite challenging; we are several hops away from any profit channel. I was still able to use Mission to Metrics to help my team measure and demonstrate the effectiveness of our work. There are a number of articles written by fantastic product managers on how to apply this framework. If I had to describe it in one sentence: it’s a recursive process that distills down to deeply understanding the key values the product provides to its biggest customers.
For us, some examples of our top metrics are
- For the engineering partners — our top metric measures ease of integration because the easier it is for engineers to build on our platform, the more willing they will be to expose their data through our APIs or to help operations customize new functionality. Both of these actions add additional value and more users to our platform.
- For the ops customers — our top metric measures cost saved to Square because the more efficient we can help an operations team become, the faster an agent can work or the fewer agents the teams need to hire which can directly translate to $ saved.
These top metrics recursively break down into more-specific metrics which can be tied to individual features or work we do on a daily basis.
In addition, We keep a pulse on various engineering system health & reliability metrics (ie uptime, SEV occurrence, performance), and take quarterly CSAT (customer satisfaction) surveys from both types of customers. CSAT is deliberately not a top-line metric because user satisfaction and user efficiency have a correlation not causal relationship. It can be dangerous to conflate the two.
These metrics help our leaders not only see, but quantify our impact and progress. Measuring success for a platform is a full journey of its own and I’m not confident we’ve found the best ways yet. I may write a followup post in a few months with additional learnings =)
The journey continues…
This journey is long, filled with challenges, and never ending. It’s also very different for every team and every situation. We were able to craft a narrative that helps our stakeholders and customers understand not only the value the team is providing today, but also its vast future potential. I highly encourage everyone to leverage these frameworks to help internal and external members stay organized, communicate, and unlock new potentials!
