Product Mindset for Internal Platforms

Introduction

A platform is a business that connects people through technology, making an ecosystem that allows value to be created and exchanged. Platform provides resources for a variety of producers & consumers to interact & transact with each other. A platform is adopted. A product is an object or system made available for consumer use; it is anything that can be offered to a market to satisfy the desire or need of a customer. A product is consumed. Platforms scale better and due to the network effects it builds up, there is enough value generated. Eg - Meta, Amazon AWS, Google GCP, Shopify etc. The difference between an external platform vs an internal platform is the monetization aspect. External platforms are sold as products whereas internal platforms are not tangibly monetized. The goal and scope of this article is to dive deeper on the Internal platform.

Internal Platforms

An internal platform connects internal producers with internal consumers making an ecosystem that allows value to be created and exchanged. It is a set of technical components & softwares that provide a service to other developers as users to build their business logic and modules to address the business needs. Since a service is provided, there has to be an obvious SLA for the service. As we think of an internal platform, we would focus more on the product mindset, technical architecture, design, operations and user benefits of the platform as a whole. As a platform we should aspire to hit the gold standards of the external platforms so that the internal users can reap all the benefits and build the best of products to show the right ads, feeds or whatever may be the use case.

Product Mindset

While commercialization is not the goal, there are significant benefits of having a product mindset to an internal platform. It helps deliver digital products faster and more efficiently which directly addresses the business needs of the company. Thinking about the platform as a product for internal customers, can help us accelerate innovation, and more systematically handle the tradeoff decisions internal platform teams face - (a) new features versus robustness, (b) operations/documentation, SLAs, (c) abstraction vs exposing internal details to users.

A product mindset would take a proactive approach, builds customer empathy, involves the customers in design and decision making, instruments a long term development strategy, device an incremental execution approach, constantly evaluate product-market fit, avoids reactive work, evangelize and market the platform to the users and keep the execution in the right direction at the right pace and provide the necessary progress visibility to the development team and users. This model can be successfully achieved if a PM, Development lead and tech lead operate in unison and co-own the platform. They are accountable for the vision, execution, success or failure of the platform.

Guiding principles of a successful (internal) platform

A platform is an open, self-served and flexible framework on which products can easily be built. The user is a developer who builds products using platform services. The platform should enable the developer to build and test its products as quickly and accurately as possible. This is similar to how Platform-as-a-Service (PAAS) operates. For that the platform should provide the following capabilities,

Value Creation

1. Core Capabilities : A platform should primarily offer a core set of capabilities which will be used by the developers to build their products. For eg - In case of Machine Learning feature exploration space, we are looking at batch and stream processing, serving, privacy etc. In case of Cloud Computing we are looking at the compute, networking, storage and many more core capabilities.
2. Ecosystem enablement : A platform should foster exchange of code or products amongst users so that they can benefit from each other's innovations and leverage their work instead of re-inventing it.
3. Co-development : An internal platform should foster a co-development model where a user would have the ability to contribute certain platform enhancements

User Experience

1. Abstraction : A platform should shield the user from the downstream complexities of the infrastructure. There are various ways to abstract in high-code (C++), low-code (DSL) and no-code (GUI wiziwig) modes of user interaction. Infrastructure complexities and management is shielded from the users. For eg - The users should not care about the available capacity or the infrastructure cost or pipelines etc. For instance in the ML feature engineering domain, their focus should be to run the hypothesis on the features to explore and quickly iterate on them so that they can be taken to production and improve the ad score. In case of pure cloud computing, the service owners would purely focus on the business logic and minimally get involved on the infrastructure side.
2. Simplicity : A platform should be self-served such that a new user can read the documentation or a starter kit and productionize the product without a lot of human interaction.
3. Robustness : A platform should be highly scalable, available, secure, performant, resilient, latency sensitive and accurate such that the users never have to worry about the robustness of the platform.
4. Visibility : A platform should provide the right level of visibility to the users as well as the platform owner such that any real time debugging while building or in production can be handled as well as support historical analysis on usage and other parameters.
5. Openness & Extensibility : A platform should be completely API driven such that the users or the owners themselves can customize certain scenarios based on their needs or evolve the platform to future needs.

Operations

1. Optimizations : A platform should optimize the use of backend infrastructure to save operational cost.
2. Automation : A platform should ideally have no human interaction and should be fully automated.
3. Monitoring : A platform should have instrumentation of all the right alerts and alarms to monitor, manage and debug the platform services.
4. Metrics & SLA : Since we now have a platform which will need adoption, each aspect of the platform must have metrics and SLAs to abide by. SLAs need time to be defined. First you need to define your service portfolio, then you measure performance and come with baseline measures then you define the SLAs based on these baselines.

Operational Challenge of an (Internal) Developer Platform

Over Indexing problem

A successful platform would give equal weight to all the three categories over a period of time- Value creation, user experience and Operations. Over indexing on Value would translate into a lot of short term wins. Over indexing on User Experience and or operations would translate to a less capable amazing platform which would hurt the business in the short term.

Typically, the over indexing happens on Value Creation as it impacts the business directly and management duly focuses on this category. One overarching opportunity for the management teams for internal platforms is to give equal weight and focus on all three categories - Value creation, user experience and operations. This would not only help the platform but also help the morale of the teams working on these vectors and the ultimate beneficiary would be the end user. This problem should be dynamically managed depending on the lifecycle stage of the platform. In early stages there could be more weight on value creation to ensure product - market fit. Over a set defined period of time the balance should reach perfect equilibrium.

1. Value Creation

Challenge 1: Understanding Value

Often the internal platforms struggle to showcase their value to the business. The business goals are heavily tied to the success of the products. This affects funding, head count allocations, project approvals etc. However the success of the products depends on the success of the platform. Short term wins are always possible when the products try to do some amount of platform work on their own. But this is not scalable, not repeatable, hard to maintain and will not work in the long run. Hence, there is an invaluable amount of in-tangible value provided by the platform for the success of the products to meet the business needs.

Challenge 2: Lack of Prioritization

Often there is p2p communication on capabilities which at times conflict the holistic work and goals of the teams. At times there are conflicting requests from customers and scope creeps.. Piecemeal development of the platform, compromises the overall vision and design of the platform and creates technical debt and snowflakes.

Opportunity : Define Value for prioritization

A return on investment based approach works great here. An ROI metric that will help the business achieve its goals can be used to determine which core capabilities need to be supported by the platform by what time frame. Since the number of users are many, the ROI metric such as Ad Score, can be coupled with the number of users requesting a capability and the implementation cost in terms of head counts or engineering weeks can be used to determine the overall priority and the value created.

2. User Experience

Challenge 1: Customer onboarding

Products get consumed but Platforms get adopted. Often organizations get trapped by under-valuing the cost of customer onboarding. Consumption is usually binary. Adoption is more dynamic and hence it needs a lot more hand holding & effort. The users have to learn the platform and innovate on top of the platform. So there is a huge learning curve involved. It is the responsibility of the platform owner to make this journey as smooth as possible.

Challenge 2: Building platform capabilities while customer onboarding

Often the platform user and platform builder teams are roadmapping at the same time. This creates a late influx of requirements on to the platform team. Which turns into a situation where the development needs to be expedited, design gets compromised and the quality is questionable.

Challenge 3: Lack of Marketing & Education

Often the users are not aware of the latest and greatest features of the platform. Which in turn causes more churn.

Opportunity : Treat users (developers) as customers

This can be achieved via,

1. Proactively building simple products by shielding the unnecessary complexities for the users.
2. Providing starter kits / code snippets or cookie cutter templates for common scenarios.
3. Right level of documentation.
4. Training & education. Build a community and customer champions who will in turn promote the platform.
5. Proactively sharing roadmaps & taking user feedback.
6. Streamlining the roadmapping timelines and involving the customers as consultants on the roadmap.

Opportunity : Define a customer satisfaction score

This score factors in the technical and non technical experience of the platform and provides a reflective pulse check which can then be used for improvements in the following quarters.

Opportunity : Define end to end latency score

This score will highlight the technical effectiveness of the platform as it measures the time taken by the user from ideation to completion. The entire technical stack is put to test under this score.

Opportunity : Leverage Technical Product Management

A more effective way to build internal platforms is to treat them in the same way as an external product offering. Applying a product management approach to internal platforms means building empathy with internal users and working with them on the design and getting the users involved. PMs should be empowered and enabled to focus on vision and strategy.

3. Operations

Challenge 1: Resource and Infrastructure management

The users often get looped into resource and infrastructure related topics which they do not really appreciate. It takes away valuable time and effort which they could have channeled in delivering a good product for the business need. A good platform should own the resource and infrastructure management constructs and provide a firm shield for the users to innovate.

Challenge 2: Production and Operations

Often the Operations and Engineering team are different and in separate organizations. The challenges faced in production if not solved for the long term can translate to repeated escalations which would further impact user experience and adoption of the platform. There are also times when operations and engineering is handled by the same platform team. In that case if the operational load is high it impacts the productivity. The oncall load can truly hamper the progress of the team towards a particular goal and can cause several delays.

Opportunity : Embrace operations as the third pillar of a successful platform.

We have the opportunity to lay out the technical projects that help ease out the production and operational load. While they may not directly translate to the ROI, they can be prioritized based on the number of SEVs raised, number of hours spent on call. Building out a user facing resource and infrastructure facing capabilities, production debugging and visibility would truly ease out the load for the customers and platform owners. Analyzing all the SEVs and production issues and solving them can be another approach to take.

Metrics & SLAs

In a way, internal platforms provide service to internal developers to build their products on top of. Hence, SLAs are very important to maintain a high standard and quality of the product. SLAs are typically derived from key metrics. The Following section tries to capture the categories of metrics that an internal platform should care for and provides from high level metrics for each category.

Summary

It is extremely important to embrace a product mindset for internal platforms for long term success. There is a golden opportunity to take a step back and look through the lens of an internal platform. Companies would benefit in the long term and will confidently scale up.

Treat the interval developer or a user as a customer and build a holistic internal platform that helps achieve the long term business goals. The line of abstraction and level of service that a platform should provide the users should be well defined, acknowledged and accepted by platform owners, consumers and the management team.