Platform as a product: Why an internal developer portal is key to your success

Editor's note: This post was updated on 25 March 2025 to include new information about Port features, internal developer portals, and how to apply a product mindset to your platform.

What is a platform-as-a-product approach?

When you consider a product built for a consumer, it’s clear that the company that built the product has considered exactly what its user base wants to see. Each iteration of the product delivers improvements to it and overcomes pain points of previous versions.

In platform engineering, this similar principle is known as the platform-as-a-product approach. platform-as-a-product is about thinking of your developers who use the platform you build in the same way you’d think about customers using your software. Developers are the end-users for platform engineers, who build and maintain the internal developer platform or portal according to their needs and standards.

The internal developer portal encompasses everything from the software development lifecycle (SDLC): infrastructure, CI/CD pipelines, Git, AppSec, microservices architecture, users and teams, and more. To make their portal accessible, intuitive, and scalable for developers, platform engineers need to think less like architects and more like product managers. 

The intention of the portal is to make everything within the SDLC easier to access and use, removing the need for developers to work directly within third-party tools, abstracting information for them, and providing them with autonomy to work. In turn, this relieves DevOps of tickets to set up a temporary resource or scaffold a service. 

Platform teams should be like product teams, establishing roadmaps to ensure the platform delivers value to the business and improves developer experience. In other words, the platform-as-a-product approach helps organizations ensure they build a portal that developers will actually use. Viewing the platform as a product for developers to use helps platform engineers ensure they’re taking into account the needs and requirements of their users when they build or improve their internal developer portal.

The rise of internal developer portals has allowed platform engineers to focus their platform-as-a-product approach and clearly define what the developer experience will be so they can drive adoption. By focusing on the users of the platform, they need to define what the developer will see in the catalog when they investigate a Kubernetes issue, what the developer self-service form shows (and doesn’t show), and what dashboards they will use. 

Product management principles in platform development

While every platform and portal will look different, there are a number of product management principles that platform teams can use regardless of their specific situations. These include:

• Always ask yourself, “who is the portal actually for?” — While platform teams may have a sense for the issues their developers are experiencing, they should be cognizant of making the project about validating their own assumptions instead of supporting the actual issues. This should look like gathering feedback from developers via surveys, without using leading questions or prioritizing based on their own preference, and considering different teams. For instance, cloud-native developers will have different needs than developers who are migrating to a microservices architecture — and your portal needs to factor in both of their needs.
• Stakeholders should drive the project — Everyone who will use the platform should lead roadmap development, and not just be informed of progress. Platform engineers should enable and refer often to short feedback loops throughout the development process. 

• Conduct regular user research — This can be through both qualitative (in-depth interviews) and quantitative approaches (surveys). Port offers Engineering 360 to enable regular surveying, monitoring, and whiteboarding within the developer portal — which makes it easy to link your self-service action adoption rate with improvements in metrics like deployment frequency. Take a look at our guide to conducting developer experience surveys to learn more.
• Use a minimal viable product (MVP) approach — Select a specific persona and a smaller subset of use cases that cover the real needs of the organization. You can also consider how this will impact other personas, including managers. Build smaller versions of important features and work consistently to improve them over time and usage.
• Use a “Jobs to be Done” framework — This common framework helps you identify, define, categorize, and manage your developers’ needs as a way to ensure the product adds value and will succeed.
• Focus on driving end-to-end experiences over one-shots — The ultimate goal of your portal isn’t to stand up a bare-minimum MVP and walk away from it — it’s to make long-term investments in the engineering infrastructure, scalability of systems, and health of your SDLC. Steer away from focusing on individual elements or features and instead think about driving end-to-end experiences for each of the following: 
  
  • Planning your day (e.g., creating developer homepages that allow devs to  see all of their assigned Jira tickets).
  • Automating your development pipeline (e.g., creating self-service actions to scaffold a new service).
  • Shipping features (e.g., creating workflows to manage canary versions and feature flags).
  • Managing incidents in production (e.g., automating service owner notifications during incidents and preventing future incidents with scorecards).
• Encourage adoption with incremental changes — Rather than using a big bang approach, customize the rollout to align with the goals and structures of your teams.

Benefits of treating the platform as a product

Platform teams who use a product approach to portal development can ensure they balance developers’ need for self-service actions with the right level of abstraction. They negotiate this balance between themselves and other platform users by asking:

• What do developers need to know to ship software safely? 
• How can we encourage, define, or enforce using golden paths? 
• What functionality does a platform need to facilitate this?

With the answers to these questions, platform teams can build an effective platform that developers want to use because it’s an actual improvement over their prior method — not because it’s prettier or abstract. 

The knock-on effect of a better developer experience isn’t just limited to developers being happier and at less risk of burning out. It actually increases developer productivity!

Recent research by GitHub and DX found that a focus on measuring and improving developer experience can enhance productivity and profitability for developers, teams and organizations as a whole. 

Key components of a platform-as-a-product approach

Platform teams need to carefully consider their specific technology stack and reference architecture when building a platform. Below are some of the essential components and tools needed to establish an internal developer platform that empowers developers to work autonomously. This should act as a great starting point for teams looking to build a portal for the first time:

• A control plane for managing resources, whether they are applications running in a Kubernetes cluster or services running in various cloud providers. It is an entry point API and acts as the central point where resources are managed in the platform.
  
  
• An internal developer portal, which provides a friendly user interface for your control plane. An internal developer portal enables a platform-as-a-product approach. The portal improves developers’ visibility into their SDLC via the software catalog, which helps them to locate and understand the relationships between services, find information such as who owns a service, and see the quality and standards requirements for different deployment types. As applications use multiple resources, referring only to a control plane alone makes it difficult for developers to track dependencies and relations between services. The portal is also where developers can find and use self-service actions, enhancing autonomy and reducing or removing the need to use email or Slack messages to request DevOps support.
  
  Platform teams can use the interface to decide which details to abstract away, so that unnecessary details such as database storage information aren’t displayed. Direct interaction with the cluster or control plane should be avoided — users should instead store their desired states in Git.
  
  
• Git helps you store desired states in a Git repository and then synchronizes with the control plane via GitOps.

{{gitops}}

• Databases are an essential part of the internal developer platform. To ensure efficient management, you should employ and require a consistent method for handling schemas within these databases, preferably as part of application definitions stored in Git.
  
  
• A secrets manager is recommended for sensitive information that cannot be stored in Git, such as passwords.
  
  
• CI/CD pipelines are also essential to execute actions such as creating repositories based on templates or building images with updated release changes to manifests.

Product approach with both the portal and platform

When you’re taking a product mindset to your platform, an internal developer portal can be a huge part of your success. It’s worth noting that the portal should also be considered with the same product-centric perspective. This means rather than focusing on particular features like the software catalog or scorecards, users should think about the numerous use cases that will benefit organizations, and consider driving an end-to-end experience for the user. That may entail using one or more components of the portal. 

{{cta-demo-baner}}