Platform as a product & portal as a product - why you should use both

Platform as a Product & Portal as a Product - Why You Should Use Both

Platform as a Product is all the rage right now; the concept is gaining traction within the Platform Engineering movement, because it focuses on principles that sound fairly obvious but are easy to overlook when you’re excited about connecting all the platform pieces.

The key principle is that just because you build something doesn’t mean someone will use it; what you build has to be worthwhile or of value to the people you’re building it for - and that can’t just be something that you think will be valuable; it has to be based on genuine communication and feedback from the intended users - who are in this case developers. Obvious, right? 

Sure. But putting this into practice within platform engineering isn’t always as straightforward as the principle would have you believe. 

The reason is that it’s all too easy for platform engineers to solely focus on the engineering and architecture of the platform, rather than applying product thinking as to what they want to offer in it. 

The stakes are high: if developers aren’t convinced that your platform is worth using, you’ll have trouble gaining adoption, and the likelihood is you’ll not only be hindering developer productivity but business outcomes. 

What is a Platform anyway?

Your internal developer platform incorporates all things built into your software development lifecycle; from the infrastructure and cloud to your git provider, third party tooling, CI/CD pipelines, microservices architecture, and more. An internal developer platform means that a developer does not need to work directly within a third-party tool (e.g. incident management, Appsec, observability, cloud resource, CI/CD, container management). Instead the developer accesses these tools through the platform and consumes reusable self-service actions (as defined by Gartner) or gains visibility through the software catalog..

This makes it easier for the developer to use what they need, and helps streamline processes and operations.

The (intended) end result is happier engineers and devs. 

Why Platform as a Product?

Internal Developer Platforms are built with the right intentions. But the reality is that organizations often struggle to make these platforms accessible, intuitive and scalable. This leaves platform users - among them developers and ops teams - frustrated.

The reason is a failure to treat the platforms as products. 

The first step should be determining what developers need to accomplish with the platform. What are their needs? Spinning up a developer environment? Scaffolding a new microservice? This can be done through user interviews and research. This is probably the most important step - not doing it is like developing a product without taking time to consider what features users need.

The second step is understanding what users know and don’t know. Let's take Kubernetes as an example. What detail does a developer really need to know about Kubernetes? What do they need to self-service? If you provide too much detail, you’ll confuse developers and create cognitive load. 

By taking a Platform as a Product approach, platform engineers should ask (both themselves and other platform users): 

• What do developers need to know to ship software safely and using golden paths? 
• What functionality does a platform need to get them there?
  

Why the Product approach now?

The rise of internal developer portals is allowing platform engineers to better implement the Platform as a Product approach, since the different building blocks of the internal developer portal support the delivery of a complete developer experience. The portal becomes the one stop shop for developers.

A portal can provide a user interface that further abstracts away the complexities of the platform and offers developer self-service so they can work independently. The portal is a one stop shop where developers can go to gain visibility and understand what’s actually going on in the platform - with information such as who owns a service, where it’s deployed as well as the quality and standards with regards to anything in the SDLC. On top of this, developer portals provide developers with a layer of self-service actions so they can work independently rather than having to use email or slack messages to request DevOps support. 

Introducing Portal as a Product

Internal developer portals should also be considered with the same product-centric lens. In fact, portals are what allow platform engineers to fully realize the vision of platform as a product.

There is more to this than meets the eye. Most platform engineers that encounter or seek out portals are interested in a software catalog - a central repository for everything application-related within your engineering. There’s good reason for this as a software catalog is one of the four main pillars of a portal and it enables organizations to view data through a ‘single pane of glass’. 

But developers need much more than a single pane of glass. They need developer self-service actions and the ability to manage software quality on their own. This is where the Portal as Product approach comes into play.

Portal as a Product Best Practices 

The portal has numerous use cases that will benefit engineering organizations, essentially covering almost all tools in the Platform stack. This includes, but isn’t limited to: 

• Unifying and tracking alerts
• Kubernetes & ArgoCD visualization
• Incident Management
• FinOps
• Using an API Catalog
• Driving AppSec 

Realizing the portal as product approach is accomplished through the portal’s building blocks:

1. Customizable UI

Developers want to use tools that have the right look and feel. By customizing the portal’s user interface, engineers can provide them with a tailored view for different teams, roles or users. They can enable developers to filter what they see and define visible properties. Each team or individual can have their own dashboards, homepages, abstractions and set of permissions. This way they can see what needs to be done and take action. ‍

2. Developer Self-Service Actions‍

Users want independence. Self-service actions provide them with that as they can perform various actions like deploying service versions, modifying feature flags, or spinning up environments without navigating through multiple platforms or having to wait for assistance. The form itself provides guidance to the developer as a golden path and also abstracts complexity away.

‍3. Software Catalog

The catalog serves as a single point of access for developers to view and understand all software entities. It is kept up-to-date and acts as a source of truth, enabling devs to get the answers to the questions they need (without having to actually ask anyone!)

4. Scorecards

These are benchmarks for each element in the software catalog, measuring quality, production readiness, and developer productivity. Scorecards help set engineering standards, trigger alerts, and support strategic initiatives. ‍

5. Automation

Developers want to be able to get the mundane, tedious tasks done so that they can focus on providing value elsewhere in development. Automation leverages the software catalog to help with things like alerting on changes in scorecards or catalog entities, initiating actions like issue creation, and automating routine tasks like resource cleanup or incident escalation. They’ll be relieved that some of their time has been freed up. 

Portal as a Product - A step-by-step guide

1. Identify the real needs of developers and understand what abstractions are required for them to be as productive as possible. 
2. Determine what needs to be in the portal once it is launched. Rather than focusing on individual elements such as the software catalog or automations, the focus should be on driving end-to-end experiences for each use case, which would incorporate many or all of the elements together. This means selecting a smaller subset of use cases that cover the real needs of the organization and the managers’ needs - similar to a minimal viable product approach.
3. Use a ‘Jobs to be Done’ framework to identify, define, categorize and manage customer needs as a way to ensure the product adds value and will succeed in the market. This encourages you to start identifying the jobs or tasks you’d want developers to accomplish based on their actual needs. 
4. Gather use cases to plan roadmaps and sprints, evaluate success metrics, and continuously refine the portal, just like a consumer-facing application.
5. To encourage adoption, start by mapping and comprehending the team structure within the organization to identify workflow interdependencies and tailor portal adoption strategies. Then, rather than using a big bang approach, customize the rollout to align with the goals and structures of your teams. 

A Product Mindset

Despite the simple explanation of using an ‘as-a-product’ approach, it requires a difficult shift in mindset to achieve. In platform engineering, a product mindset is needed for both platforms and portals. A portal-as-a-product approach will help engineers to contemplate the needs and requirements of its developers at a higher level. The portal's capabilities will then enable platform engineering teams to fulfill the platform-as-a-product approach   through the delivery of a product that serves developers well.