Platform Value Attribution in Large Organizations
This text discusses the problem of how organizations, particularly large corporations, perceive value of platforms. They are often seen as a cost center that does not generate revenue, making it difficult for platform teams to justify their value and secure funding. I propose an alternative solution to this problem, which is to “charge” teams and organizations that build on the platform. This would make the platform a revenue-generating organization, making it easier to understand and justify its value. The text also notes that this approach has several positive side effects, such as making it clear that everyone is a customer of the platform and allowing platform teams to self-fund their initiatives.
Hard problems should not be avoided, they should be surfaced and resurfaced until there is a solution. What happens when a problem no one wants to talk about is ignored? Actually, nothing may happen in our lifetime, or things could blow up, causing havoc. The truth is it really depends on the circumstances. But hard problems should be solved on the principle of “if not us then who?” because this is what forces us to question the status quo. When it comes to platforms, I feel compelled to question the status quo of “platforms are hard to quantify in terms of the business value they provide”. I’ve said it myself and heard people make this claim more often than I care to remember . The truth is… it is very hard to justify…
We often found ourselves petrified when a new exec rolled in to become the head of an organization, including the platform we were working on. Almost always, this would be an executive not familiar with the platform business. And here we are, over and over again - proving the value of the platform. After many hours of presentations, meetings, and talks, we come to some kind of balance where they let us do our thing, pretending they care. But when a push comes to shove; when there is a question of what work do we need to cut in the light of limited resources. The answer is almost always the same - teams that are shown as an expense line on the ledger…
Problem and Definitions
Definitions
What do we mean when we say “platform”? Here is a dry and very long definition:
Platform, in its broadest sense, is a collection of tools, application programming interfaces, frameworks, user experience builder tools, infrastructure, or any collection of other tools that are used for building user experiences and that are not directly exposed to users. In more specific terms, a platform can refer to a specific technology or set of technologies that enable the creation and deployment of software applications. Examples of platforms include operating systems such as Windows or Linux, web development platforms like Ruby on Rails or Django, and mobile development platforms like iOS or Android. These platforms provide developers with a set of pre-built tools and frameworks that can be used to create and deploy software applications, making the development process more efficient and streamlined. Additionally, a platform can also refer to a specific service or set of services that are used to host, distribute, and manage software applications, such as cloud computing platforms like Amazon Web Services or Microsoft Azure. These platforms provide developers with the infrastructure and resources needed to build, deploy, and run software applications in a scalable and reliable manner. A typical consumer of a platform at Salesforce is a developer, admin, or any piece in the tech stack that powers some experiences.
Put simply, a platform is a key element in the software development process, providing developers with the tools and resources they need to create and deploy high-quality software applications without rewriting things from the ground up.
Problem
During my work on platforms, I had an opportunity to observe the recurring problem of how organizations, especially in large corporations, perceive platforms. While knowing that their platform is a building block in whatever solution they are building, the senior LT team, oftentimes, treats it along the lines of it being a “necessary burden” which has to stay there but it would be great if it didn’t exist. This again stems from the fact that a platform doesn’t “earn” anything. In other words, it is a cost center. The question then becomes what can be done to bring a balanced approach where the senior leadership in corporations across the industry starts to recognize the value of platforms and adequately interact with them. Not having to address this problem causes all sorts of organizational issues where people who work on platforms often find themselves having to prove their value, over and over again, to every new Senior LT. This results in affecting how the talent is being nurtured because the budgets, naturally, go to teams that have “sales” or “closed deals” to show. To add to the problem, there are long-term effects on the success of a business which is hard to diagnose and pivot early before the problems become systemic due to the technical depth of a platform and very few who understand it. We could go further and compare the platform to a country having strong fundamental sciences which are capable of building innovation and affecting mid to long-term trends in its respective fields, thanks to the talent and expertise that is being built up over the years. Having to ignore the required investments in the platform is detrimental to businesses, long-term.
Proposal
So, what can be done? I’ve studied a number of approaches but it really comes down to just two kinds. The first one, listed in the “Alternatives” section below is basically a “do nothing” approach, and the “Solution” section covers one variation of the principle of value attribution.
Alternatives
In my experience, we tried a couple of approaches to increase awareness and show the value of the platforms we worked on in the eyes of the senior leadership. We did a combination of bringing awareness to the leadership through presentations, and begging the product teams who we supported to call out that their success would not be possible without the platform’s help. While they are useful ways to increase the subjective but nevertheless value and awareness about the platform, they don’t solve the fundamental problem of tying the platform’s work to “real” quantifiable business metrics, aka dollars made or saved.
Solution
An alternative or an amendment to the other solutions we talked about above is to “charge” teams, and organizations that build on our platforms. It doesn’t need to be an account-to-account type transfer but rather a line item in the corporation’s accounting ledger. This way, the platform becomes a revenue-generating organization, rather than an expenditure line item in the ledger. It is common knowledge that the way businesses measure their performance is usually done by calculating their profits with a simple high-level formula: P = R - C (profit equals revenue minus costs). It is a very simple metric that is easy to understand and can be reasoned about at any level of an organization. In addition, measuring in a currency allows for consistent model outputs month-over-month, quarter-over-quarter to year-over-year. Thus, measuring the impact of a platform should be done in the same way.
The platform should be offered as a service to any team or organization with a recording of revenue. There are many examples on the web where frameworks are offered to engineering organizations at a cost. Doing so within a company shouldn’t be any different.
This approach reveals interesting side effects.
- EVERYONE is a customer of the platform, be it internal developers or external.
- It is very easy to gauge the business performance of teams developing the platforms.
- Platform teams that have revenue can self-fund their mid to long-term initiatives, which would otherwise be hard to get approval for. This is because it is more straightforward to put a price tag on prioritization items.
Pricing
This section is probably one of the harder ones to figure out and we will see why shortly.
At a high level, the pricing options can be further simplified into three models.
- Cost-plus pricing: Price = [Cost + Expense] + Profit.
- Demand pricing: Profit = Price - [Cost + Expense].
- Competitive Pricing: The price is determined based on what the competitor is charging.
- Donation-based: the platform provides frameworks and services and organizations within the company act as sponsors.
Given that the platform in an organization is usually a local monopoly and doesn’t operate in pure market conditions, we think, the most appropriate model is either the cost-plus model where a profit variable could vary between zero and some markup value or, on another spectrum, a donation-based where we get formalized sponsorship from partner organization where they allocated certain headcount towards the platform. The markup value in the cost-plus model can ultimately be controlled at the executive level.
What the pricing itself should be is the question for a business unit, responsible for price formation. But in general, pricing for Platform as a Service (PaaS) can vary depending on the provider and the specific services offered. Some common pricing models for PaaS include:
- Subscription-based: Customers pay a monthly or annual fee for access to the platform and its features.
- Pay-per-use: Customers are charged based on their usage of the platform, such as the number of users or the amount of data processed.
- Tiered pricing: Different levels of service are offered at different price points, with more advanced features and capabilities available at higher price tiers.
- Free trial: Some PaaS providers offer a free trial period to allow customers to test the platform before committing to a paid plan.
Ultimately, the pricing of a PaaS will depend on the specific features and capabilities offered by the provider, as well as the target market and competitive landscape. It’s important to compare different providers and carefully consider the features and pricing that best meet our needs.
There are a lot of considerations to be taken into account, some are not even known now but I believe, it is the right overall direction in determining the value of the platform, explicitly.
Closing Thoughts
While I see the platform-as-a-service model as addressing the fundamental problem of how platforms are perceived within organizations, it could and should be used in combination with approaches I called out earlier in the “Alternatives” section. But the key takeaway should be that the platform product teams in collaboration with business units should find a way to price platform offerings and use it as a tool in priorities discussions. There are a few considerations to take into account with this approach.
- The platform is on the hook to provide competitive value.
- The platform has to deliver features “faster”. We have witnessed deliveries of features that took years to deliver. This is unacceptable - there has to be a process that allows a faster idea-to-product timeline.
- The hard decisions around tech stack maintenance have to be done at the platform level.
- Easier to track platform metrics for everyone interested.
THE END.
