What if we thought of HR or IT as a product?

To be completely honest, I am not, by any means, an expert in product management, but I think you already knew that. It’s a term I’ve come across here and there, glancing at it discreetly but without paying much attention. Then, by chance, or rather thanks to LinkedIn’s algorithm (which is rare enough to be worth mentioning), I was exposed to some very interesting thoughts by Julien Laforêt, which made me take a closer look.

I have no immediate interest in the subject, but as usual, I tried to understand how a good idea that worked somewhere, in a given profession or industry, could be imported, or even hacked, to be applied elsewhere.

Naturally, I wondered if we could repurpose the principles of product management to rethink certain business functions.

This is not about playing wizard or toying with concepts for fun, but about providing an answer to the problem of the growing disconnect between support functions and the real needs of teams in the field.

HR, IT, and many other functions are structured as silos focused on their own internal compliance, when they are supposed to serve employees whose practices, tools, and expectations are changing rapidly.

So I dug a little deeper into the subject and, without claiming to have the same level of expertise as those who inspired me, here is what I understand about product thinking and how it can be used as inspiration to do something different.

This article is part of a broader reflection on operational excellence applied to tertiary functions, because thinking of a function as a product means reintroducing a logic of impact, value-driven management, and continuous questioning at the very heart of support services.

In short:

• Product management is presented as an approach focused on creating value by balancing user needs, business capabilities, and economic viability, and by directing action toward real problems that need to be solved.
• Applying this logic to support functions (HR, IT, management) would enable organizations to move away from silos and adopt a proactive stance driven by usage and impact.
• Thinking of a function as a product involves designing clear user journeys, measuring perceived value, and continuously iterating based on feedback from the field.
• This approach transforms rigid services into scalable solutions based on roadmaps, features, and performance indicators that are relevant to employees.
• Adopting a product mindset also means accepting the lifecycle of internal services, eliminating those that no longer add value and launching new services in response to specific needs.

Product management: a compass for creating value

Product management, in its simplest form, is the art of designing and developing a product that has value for both the user and the business. A good product manager doesn’t just deliver features: they identify needs, formulate a vision, prioritize efforts, rely on data, and constantly seek impact.

Good product reasoning is based on three main pillars:

1. What users want: their expectations, their actual uses, their concrete frustrations.
2. What the business can do: with its skills, resources, and technical, human, or regulatory constraints.
3. What is economically viable: in other words, what makes strategic or financial sense in the long term.

The role of the product manager is to navigate the intersection of these three dimensions and find the balance where value will be maximized.

The product manager is not a project manager, salesperson, or technical expert, but someone who guides a team toward what makes sense by asking two fundamental questions at each stage:

– Who are we doing this for?

– What real problem does it solve?

Applying this logic to a mobile app or a SaaS tool is standard practice, but applying it to a support function is another matter entirely. And that’s where it gets interesting.

But perhaps, in order to initiate the necessary change in mindset, we should start by considering that these functions we call support are in fact business functions (Employee experience is not a support function but a business function…).

Thinking of HR as a product

Let’s take HR as an example.

In many organizations, HR is structured like a catalog of services: recruitment, training, onboarding, career management. It is designed from the inside out, rarely from the perspective of the end user, i.e., the employee or manager (2023 Employee Experience Barometer: the employee experience confronted with its contradictions, The impact of HR questioned by French executives and IT is becoming the HR department for machines, but who is taking care of the humans?).

It also operates on a request-response basis: you ask for something, it delivers. But this model reaches its limits as soon as you question its impact, its clarity, or its ability to evolve with changing uses.

The proposal put forward by several players in organizational innovation is to move away from a service-based approach and toward a product-based approach. In short, HR should no longer be seen as a function that “provides services,” but as a function that develops coherent, usage-driven solutions with a vision, strategy, priorities, feedback, and iterations.

In this approach, HR:

• identifies its target users (candidates, employees, managers, social partners),
• builds clear pathways designed to be useful, usable, and desirable,
• adopts a product lifecycle approach (creation, adoption, evolution, withdrawal),
• and equips itself with success metrics that go beyond simple completion or compliance rates: adoption, satisfaction, perceived value, managerial activation.

This article sums up the problem well: “Today, HR is a service provider, not a designer. But services cannot scale. Products can.” (From Service to Product: A Smarter Way for HR to Work).

In terms of methodology, here is an example of an approach to thinking like a product team (HR as a Product — How to transform HR into a product.):

• Create an HR roadmap structured around user priorities.
• Identify HR features (onboarding, feedback, career management) and develop them as product modules.
• Define owners responsible for each feature, with a vision, impact measurement, and user feedback loop.

This may seem abstract, but in reality, it’s extremely concrete.

Let’s take onboarding as an example.

Instead of a rigid process fragmented across several departments, it becomes a product in its own right, designed to generate a smooth, well-equipped, progressive, and measurable experience. We identify irritants, prototype new content, test it with new arrivals, measure the clarity of the journey, the completion rate, and the feeling of integration, and continuously improve.

Thinking of HR as a product is not a cosmetic change or a change in vocabulary, but a change in attitude and governance: moving from a reactive approach to a proactive strategy driven by value and usage. It is also a way of making HR more transparent, more accountable, and closer to the work.

Another more radical example: at Moderna, the HR/IT merger was accompanied by a product-based approach to the HR function. The goal? To rethink HR services as an internal platform, with a focus on usage, interface, and user satisfaction. All of this is backed by feedback loops and co-construction with business teams (Why Moderna Merged HR and IT).

The emerging concept of “Chief of Work” (Do we need a chief of work?) can also help embody and implement this product vision (Chief of Work: A Modern(a) C?Suite Role).

Management as a product

Management can also be thought of as a product for use by employees themselves in serving customers.

I won’t go into too much detail here, as this point has already been covered in a previous article (Do you have a delivery model for management?), which made me realize that in the past I have repeatedly used product management principles for operations, HR, and management without knowing it and without the technical knowledge. But when the intention is right…

What I take away from this is that starting with the employee and their needs has allowed me to throw out a lot of things that I wanted to implement as a leader and “expert” but which, in this particular context, were of no use to anyone except perhaps my ego, and would have mobilized energy and created constraints without having any significant impact, or even been counterproductive.

Think of IT as a product

On the IT side, the situation is similar, with IT departments often perceived as top-down control towers that push tools that are disconnected from everyday irritants. The result: shadow IT, rejection of new solutions, software fatigue (A complicated IT experience. Irritant #7 of the Employee Experience).

And yet, if we consider the workstation as a product, collaborative tools as user journeys, and support as an experience to be optimized, then everything changes.

At ThoughtWorks, this approach is formalized in the concept of the “Product Operating Model“. A modern IT department no longer manages projects in a waterfall model, but rather internal products with a vision, a roadmap, KPIs, and short iteration cycles. (How to create a product operating model to support product organization transformation).

Once again, it’s not about turning all IT agents into product managers, but about instilling a mindset: the employee is the end user, and users need to be listened to, observed, and measured.

Thinking about products also means thinking about their life cycle

Thinking about products isn’t just about designing existing services better but it also means accepting something that many organizations carefully avoid: internal services have a life cycle.

In a product-based approach, a product is created, evolves, lives, and eventually is replaced or discontinued. And that’s normal.

In a process-based approach, on the other hand, what has been put in place stays in place. Sometimes the tool is changed, an FAQ or chatbot is added, but we avoid asking ourselves whether the service is still being used, relevant, or useful.

Adopting a product mindset means giving yourself the right to remove what is no longer useful, improve what is not working, and launch new services when a real need arises, without waiting for a complete overhaul.

This means accepting that not everything is meant to last and that the quality of a service is not measured by its age or compliance, but by its ability to generate value for its internal customers.

In this sense, a function that adopts product thinking becomes a living function, not frozen in reference documents or roadmaps, but capable of learning, testing, iterating, and abandoning.

Bottom line

There is a real lesson to be learned from product management for all business functions. Not to “be like startups”, but to refocus on a question that is too often overlooked: does what we do really serve someone, and does that person derive tangible value from it?

If the answer is unclear, it may be time to look at your job differently.

Image credit: Image generated by artificial intelligence via ChatGPT (OpenAI)