Suneth Rupasinghe is Vice President of Global Enterprise Platforms & Services at HP, where he leads product management, engineering, and operations across SAP S4/HANA, ServiceNow, MS Dynamics, Adobe Commerce, MuleSoft, and HP’s global payment platforms — a portfolio supporting more than $50+ billion in annual revenue. He joined HP in 2022 as Vice President of B2C E-Commerce Solutions and Digital Solutions Architecture before moving into his current role in January 2025. Earlier in his career, he held engineering and architecture leadership roles at MetLife and Amplify Education, working across digital benefits platforms, e-commerce, and cloud-native modernization.
In this conversation, Suneth talks about the three-year effort to transform HP’s enterprise platforms from maintenance-mode technology assets into true products — treating internal business units as customers, building a product management practice from scratch, and even reframing compliance itself as a product with its own roadmap. He also shares how that shift helped HP advance its compliance strengths, and how his team decides where AI capabilities should live as build-versus-buy questions get harder to answer.
From technology asset to product
What changed at HP that made the traditional approach to managing enterprise platforms no longer sufficient? What’s the reasoning behind the move to platform-as-product?
Before taking on this role, I had spent much of my career in product development and bespoke software delivery, so I already approached technology through a product lens. When our platform organization came together about two years ago, it quickly became apparent that we were largely managing our platforms as technology assets rather than strategic products.
The conversations were typically centered on operational metrics: uptime, cost to operate, incidents, and service stability. Those are important measures, but they don’t tell you whether a platform is creating business value, enabling growth, or helping the company move faster. In many ways, it was a model I’d seen in other organizations as well.
At the same time, the pace of innovation across the industry was accelerating. Whether it was AI, automation, analytics, or new platform capabilities, vendors were delivering meaningful advancements at a rapid rate. Yet we often found ourselves unable to take advantage of them because of technical debt, heavy customization, or being multiple releases behind. Our business partners would increasingly ask, “If the platform can do this, why can’t we?” That question became an important catalyst for change.
We also recognized that our investment approach was too focused on maintenance and sustainment. What was missing was a strategic roadmap for how these platforms should evolve over time. Reusability, adoption, modernization, and innovation were not being managed as intentional outcomes. As a result, teams frequently had to build capabilities from scratch, increasing both cost and time to value. The move to platform-as-product addressed those challenges. It shifted the conversation from maintaining technology to continuously evolving capabilities that serve the business. Each platform now has a clear strategy, a roadmap, defined outcomes, and measurable value drivers, just as any product would.
When we looked at all of those factors together, it became clear that a different operating model was required. Treating platforms as products gave us a framework to modernize more effectively, accelerate adoption of new capabilities, improve reuse, and align platform investments more directly with business outcomes. That’s ultimately why we came together as a team and why the platform-as-product model became such a central part of our strategy.
Building the product management practice
Can you briefly explain who your customers are on these platforms?
We’re fundamentally an IT-for-IT organization. Our primary customers are our peers across the CIO organization, particularly the value-aligned teams responsible for delivering business outcomes. These teams work closely with functions such as sales, supply chain and finance, translating business objectives into technology-enabled capabilities.
Our role is to provide the platform foundation that allows those teams to move quickly and effectively. We focus on ensuring the right capabilities, services, and products are available so they can build and deliver solutions that drive the outcomes their business partners are seeking.
In that sense, our direct customers are the value-aligned teams themselves. By enabling them with scalable, reliable, and continuously evolving platform capabilities, we help accelerate delivery and reduce the complexity of building solutions from scratch.
Beyond that, there is a natural ripple effect. The value-aligned teams serve the business, and the business serves HP’s customers. So while our day-to-day engagement is primarily with our peers inside the CIO organization, the capabilities we deliver ultimately contribute to business performance and, in some cases, directly influence the experience of HP’s end customers.
That’s why we think of our platforms not simply as technology assets, but as business enablers. Our success is measured by how effectively we help our internal customers achieve their outcomes, which in turn supports broader business and customer success.
So how did you start building the product management practice?
When we brought the organization together, one thing was clear: we needed to evolve how we operated. We had incredibly strong platform talent and deep domain expertise, but product management required a different set of capabilities. The challenge wasn’t the quality of the people; it was creating the structure, skills, and mindset needed to operate as a product organization.
We focused on two priorities. First, we brought in the right leaders to establish and scale a modern product management practice. Second, we built an operating model to support it. That operating model became the foundation for how we worked, how we developed talent, and how we drove consistency across the organization.
A critical part of the journey was investing in the people already here. We wanted to build capabilities from within, not simply hire them from outside. Relying exclusively on external talent creates unnecessary friction and misses the opportunity to leverage the deep institutional knowledge that already exists. As a result, training, coaching, and upskilling became core elements of the transformation.
That investment continues today. We have ongoing learning programs for product managers, engineers, and platform teams, and we work closely with strategic partners to stay current on emerging practices and technologies. More recently, that focus has expanded to include AI-native product management and how AI can enhance product strategy, delivery, and customer engagement.
Ultimately, our approach has remained consistent: bring in new talent and perspectives where needed, while continuously developing the people already in the organization. The operating model ties those two elements together and helps create a sustainable product management community that continues to grow, adapt, and mature over time.
What do you look for now when you’re hiring product managers, in terms of AI skills?
This has evolved significantly over the last 18 months. The foundational capabilities of product management are still essential. We look for people who have successfully managed products, developed strategy, worked closely with customers, navigated complex stakeholder environments, and consistently delivered business value. Those fundamentals haven’t changed.
What has changed is the expectation around AI. We now look for product managers who understand how to leverage AI-enabled tools to amplify their effectiveness. It’s not just about working faster; it’s about making better decisions, conducting deeper research, uncovering insights more quickly, and improving the overall quality of outcomes. Product managers today have access to capabilities that simply didn’t exist a few years ago, and we’re looking for people who know how to incorporate those tools into their day-to-day work.
The second area we’re increasingly focused on is what we call the full-stack builder. This is an evolution of the traditional product manager role. In addition to owning product strategy, customer engagement, and roadmap execution, these individuals have a strong understanding of engineering practices, the software development lifecycle, and agentic AI systems. They know how to orchestrate work across people, platforms, and AI agents to accelerate delivery and innovation.
We’re actively bringing this capability into the organization today. While traditional product management skills remain critical, we believe AI-native product managers and full-stack builders will become two of the most important roles over the next 18 to 24 months as we continue to transform.
Learning to listen to internal customers
When the customers for your products are your internal business teams, how do you understand what they need and translate that into a product roadmap?
Serving internal customers is different because a lack of feedback isn’t necessarily a positive signal. If internal teams aren’t engaging with your platform, they’ll often find alternative ways to solve the problem. In many cases, silence is actually a sign that you’re not creating enough value.
Early on, we recognized that adoption couldn’t be a pull model. It had to start as a push. Our responsibility was to proactively engage with customers, understand their challenges, and demonstrate how the platform could help them achieve their goals. As the platform matured and delivered value, that dynamic gradually shifted from push to pull.
We borrowed a concept from leading product organizations: Customer Success Management. We asked our product managers to act as customer success leaders, not just product managers. A key part of their role was building relationships with internal customers, providing white-glove support, and helping teams realize value from the platform. We held workshops, monthly ideation sessions, and regular business engagements focused on understanding objectives, exploring use cases, and identifying opportunities for rapid delivery.
One of the most important mindset shifts was moving away from a requirements-first approach. Instead of starting with everything a customer wanted, we started with what the platform could deliver today to help them achieve business outcomes faster. From there, we could iterate and expand capabilities over time. That approach significantly accelerated time to value.
We were also applying what is now commonly referred to as forward-deployed engineering long before the term became popular. We would rapidly build a proof of concept, validate the use case, and demonstrate the outcome. That hands-on engagement created momentum, accelerated adoption, and strengthened the partnership between our platform teams and the value aligned teams.
Ultimately, the transition from push to pull came from one principle: ensuring our customers were successful. When customers experience value quickly, adoption follows naturally, and the relationship evolves.
One strategy, five platforms
How do you create a consistent product strategy across platforms as different as SAP, ServiceNow, payments, commerce, and integration?
The goal isn’t to make every platform do the same thing. These platforms serve very different purposes. Adobe Commerce is customer-facing, SAP is deeply domain-specific, and MuleSoft is an integration platform that enables connectivity across the enterprise. A one-size-fits-all strategy simply doesn’t work.
What you can do is create a common strategic framework that applies across all platforms while allowing for platform-specific execution. We developed a strategy built around five pillars: simplification, adoption and maturity, innovation ignition, operational excellence, and compliance and security. Those pillars are intentionally platform-agnostic. They provide a consistent way to think about progress and investment without prescribing the same outcomes everywhere.
For example, simplification means something very different on SAP than it does on MuleSoft. In SAP, it’s about reducing customization and moving toward a clean core so upgrades can happen faster and with less effort. In MuleSoft, simplification is about increasing reuse and standardization so teams can leverage existing APIs and integrations instead of continually building new ones. The outcomes are different, but both support the same strategic objective.
Our platform product managers helped shape the framework from the beginning. We came together to define the overarching strategy and then built FY26 roadmaps aligned to each of the five pillars. The initiatives within those roadmaps vary by platform, but they all connect back to the same strategic themes. That’s how we standardize. It gives you the framework to talk about in a consistent way and the flexibility to be specific where it matters.
With competing demands across so many platforms, what gets prioritized?
Once we established the framework, we assessed every platform against a maturity model across each strategic pillar. The model included roughly fifteen subcategories and measured capabilities on a spectrum from reactive to leading. That assessment gave us an objective view of where we stood and created a heat map that clearly highlighted areas of strength and areas requiring attention.
From there, prioritization became much more straightforward. We always have a finite investment envelope, so we direct funding toward the highest-value opportunities where maturity is lowest. The goal is to elevate those critical capabilities while sustaining the areas that are already performing well.
When we built our FY26 roadmap, we used a simple two-dimensional lens: business value and maturity. We focused our investments on the capabilities that would deliver the greatest impact while moving the most significant gaps forward. In practical terms, that meant turning the red areas into yellow, while ensuring the green areas remained strong. It’s deliberately simple, and it’s the approach that’s held up for us.
Treating compliance as a product
How do you build compliance into a platform in a way that lets teams move faster rather than slowing them down?
Traditionally, compliance happens at the end of the process. Teams build and deliver, and then they encounter a series of control gates that require rework, delays, and additional effort. We wanted to change that dynamic.
Compliance was one of the five pillars of our strategy because we had clear visibility into where the gaps and friction points existed across our platforms. Rather than treating compliance as a set of checkpoints, we treated it as a product.
When people hear “product,” they often think of software, but in this case it’s a service-oriented product. Take a common ITGC requirement like timely incident management. The product isn’t just a control. It’s the end-to-end capability: the process definition, stakeholder responsibilities, workflows, reporting, and services that enable customers to meet their compliance obligations with minimal effort.
The key shift was moving the focus from what we needed to do internally to what our customers needed to be successful. We built a service layer around compliance requirements and packaged those capabilities into reusable products that teams could consume consistently.
We’ve also matured those products over time. In the early stages, many of these services were highly manual. We then introduced automation and standardized reporting, creating semi-automated capabilities. Today, some of those same products have evolved into AIOps-based services supported by autonomous agents. The underlying objective hasn’t changed, but the delivery model has become increasingly self-service, intelligent, and scalable.
That’s how compliance becomes an accelerator rather than a constraint. When you build it into the platform as a product, teams no longer encounter compliance at the end of the journey. They consume it throughout the process as a built-in capability, allowing them to move faster while strengthening governance and control.
You strengthened the organization’s compliance posture. What organizationally and technically contributed to that result?
What made the difference was treating compliance as a product rather than a project. Too often, organizations overly focus on meeting only the immediate needs. We took a different path and approached compliance as a transformation. That meant redefining processes, establishing clear service ownership, improving repeatable compliance products and controls, and helping teams build on their understanding that compliance is a core business capability. The goal was to more deeply embed compliance into the way we operate.
It wasn’t a single technical change or organizational initiative. It required aligning people, processes, and technology around a common operating model and strengthening a structure that scales consistently across the organization. This demands tremendous commitment from the team. But that investment leads to a stronger foundation. Today, we have further developed processes, reusable compliance products, and greater clarity around expectations and accountability. As a result, we’re able to move faster, scale more effectively, and continuously strengthen our compliance posture.
The key to this mindset is recognizing that this is never about solving isolated compliance requirements. It is about continuing to strengthen a capability that improves how the organization operates year after year.
What comes next: Signals, and the AI build-versus-buy question
What signals tell you that a platform is becoming a successful product rather than simply a well-run technology?
The strongest signal is when customers start coming to you asking how they can build on the platform, what capabilities already exist, and what they can reuse. That’s the point where the conversation shifts from operating technology to consuming a product. Instead of us driving adoption, customers are actively seeking ways to leverage the platform to achieve their outcomes.
We also track a set of metrics to understand whether we’re moving in the right direction. Platform Net Promoter Score (NPS) gives us insight into customer sentiment, while measures such as reusability, maturity, and cost per transaction help us evaluate how effectively the platform is delivering value. As we execute against our roadmaps, we expect those maturity scores to increase over time, providing a quantitative view of progress.
For me, though, the most meaningful indicator is the transition from push to pull. In the early stages, we had to invest heavily in customer engagement, advocacy, and adoption. We were constantly demonstrating value and encouraging teams to take advantage of platform capabilities. Today, on some of our platforms, conversations have fundamentally changed. Customers are approaching us with questions such as, “Can I use this capability?” or “When will this feature be available?” Many of those discussions are centered on AI and automation, where demand is often outpacing our ability to onboard teams responsibly.
We’re not at that point across every platform yet, and there’s still work to do. But where we are seeing strong customer pull, increasing reuse, improving maturity metrics, and growing demand for new capabilities, those are clear signs that the platform is evolving into a product rather than simply being managed as a piece of technology.
With AI capabilities coming from enterprise platforms, external vendors, and your own teams, how do you decide what to build, what to buy, and where each capability should live?
We start with our broader enterprise AI strategy, which is led by our Applied AI team. We complement that with a platform-native AI strategy supported by a set of guiding principles that help us make decisions in a rapidly changing landscape.One of the most important principles is augmentation versus differentiation. We ask a simple question: is this capability creating meaningful competitive differentiation, or is it augmenting an existing process? If it’s primarily augmentation, our default position is to leverage native platform capabilities. It’s typically easier to implement, easier to maintain, and allows us to benefit from ongoing innovation within the platform ecosystem.
We also evaluate total cost of ownership. We’ve already made significant investments in our core platforms and licensing. Wherever possible, we want to maximize the value of those investments before introducing additional technologies that increase complexity and support costs.
Another key consideration is technology sprawl. As AI lowers the barriers to building and acquiring solutions, organizations risk creating fragmented technology landscapes. Like many large enterprises, we’re actively working to simplify and consolidate. We want innovation, but we want it in a way that’s intentional and sustainable.
That said, if a capability is truly differentiating and can accelerate business outcomes, we’re willing to bring in external solutions or build capabilities ourselves. The important thing is making that decision deliberately. What may be differentiating today can become a standard platform capability tomorrow. That’s why strong partnerships with platform vendors are so important. We invest heavily in those relationships to gain early visibility into their roadmaps, participate in preview programs, and influence future capabilities. In some cases, we may choose a third-party solution knowing that a comparable native capability is likely to become available in the near future. When that happens, we can transition to the platform-based solution through a planned and intentional lifecycle.
We’ve deliberately avoided creating a rigid decision matrix because the market is evolving too quickly for static rules to remain effective. Instead, we apply a consistent set of principles around differentiation, augmentation, total cost of ownership, platform leverage, and technology sprawl. Those principles don’t guarantee every decision will be perfect, but they ensure each decision is thoughtful, transparent, and aligned with our long-term platform strategy.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.