PX Transformation
What It Takes, What We’ve Learned, and Where to Start
We’re getting close to the end of our first PX as a Product cohort, and it’s been an energising experience. I’m in the middle of final edits on the content for Week 4, which focuses on transformation, and it feels like everything has been building to this point.
Because it’s one thing to teach product strategy, discovery, or how to break work down into small, testable increments. That’s all fun in the abstract.
But really, what we’re trying to do is change how we work. We’re trying to embed these ideas permanently, systemically, sustainably.
And this is where the real questions start to emerge.
In every cohort conversation, almost without exception, someone eventually asks:
“Okay, but how do we actually do this?”
“How do we make the change real in our organisation?”
“And… what even are our products?”
These two questions: “What are my products?” and “How do I make this change?” keep surfacing again and again.
And by serendipitous coincidence, the team at TI People invited me to join a session with some of Europe’s largest employers this week, who had come together as people actively working to co-create the next evolution of the HR operating model, and I was offered a short window to pitch a few thoughts.
I’m incredibly grateful for the opportunity.
And it was striking to see the exact same questions echoing there at scale, at speed, and with serious intent.
So this post is about the questions we all keep coming back to and how we go about making transformation actually happen.
The Questions That Always Surface
In almost every conversation I’ve had about transformation, whether with cohort participants, consulting clients, or executives from global organisations, the same set of questions shows up:
What mindset shift is actually required here?
Is this just about tools and techniques, or is there something deeper in how we need to think?
Where do I start?
Do I need a strategy? A product? A team? A pilot? How do I avoid spinning in place?
Who owns this?
Is this a PX initiative? A product problem? A leadership challenge? Where does responsibility sit?
What does the rhythm look like?
How do we actually run this in practice? What changes in our day-to-day cadence?
What skills do we need?
Do we need to restructure? Retrain? Hire new roles? Or can we reframe what we already have?
Do we have permission to work this way?
Will the system allow it? Will leadership back it? What happens when we hit friction?
Are we ready?
Do we have the scaffolding, the space, the capacity, and the belief to do this for real?
If you’ve asked any of these, you’re not alone.
There is one additional question that comes up again and again:
“But what even are our products?”
It is a valid question to ask. But it’s also the wrong place to start.
There’s often an unspoken assumption that somewhere out there is a standardised PX product portfolio you can adopt and implement, like a blueprint for how every organisation should run its employee experience.
But that’s not how product thinking works.
Just as no two customer-facing businesses share the same product portfolio, no two organisations will offer the same internal experience product. And they shouldn’t.
Because products, whether external or internal, are not defined by the business first.
They’re defined by the problems that need to be solved.
The job of defining a PX product portfolio is to:
Identify the most important employee problems to solve
Understand what needs to happen to advance the business goals
Design and iterate on experiences across the dimensions of work that solve those problems in a way that people find value from
The product lives at the intersection of the employee’s jobs-to-be-done, the dimensions of the ‘user-experience’ of work, and the business capabilities that shape those experiences.
When you design for those dimensions intentionally, when you build solutions that solve for employee jobs-to-be-done and enable your organisation to move forward, you’re building products.
And crucially, the product portfolio is not the starting point.
It’s an emergent property of working in a product operating model.
Once you begin working this way, focusing on problems, assigning ownership, learning through iteration, the shape of your portfolio begins to reveal itself.
So if that’s what emerges… then what are we moving toward?
What a Transformed Organisation Looks Like
If the product portfolio is what emerges when you start working in a new way, then the natural question becomes:
What exactly is that new way of working?
What does transformation look like in practice?
This is a shift in how the organisation functions and more specifically, in:
How you decide which problems to solve
How you solve those problems
How you build the solutions that address them
This is the foundation of the product operating model.
To support this system, you need to develop five essential capabilities:
Product Strategy
Clear direction. Shared outcomes. Alignment to both employee needs and business goals.
Continuous Discovery
Constant learning. Mapping. User research. Opportunity identification.
Continuous Delivery
Small bets. Frequent releases. Iteration. Responsiveness.
Empowered Product Teams
Cross-functional units with clear ownership of a problem space and the necessary skills and capabilities to achieve the desired outcomes.
Product Culture
The environment that supports all of the above. Language, norms, rituals, and incentives that reward outcomes, not compliance.
And 4 essential competencies show up in the teams doing the work, regardless of function, industry, or maturity level:
Product Management
Responsible for setting direction, aligning teams, and ensuring work solves real problems for real users while also advancing business goals. This role brings focus, prioritisation, and sequencing to the table.
Experience Design
Responsible for shaping the way employees engage with systems, services, and moments of work. From forms to workflows to rituals, design makes the work usable, human, and coherent.
Solution Building (“engineering”)
In PX, what needs to be built might be a process, a team structure, a policy, a space, or a digital tool. So this engineering capability might include: Org designers, Process architects, Workplace teams, People tech specialists, Ops and enablement roles. They are the problem solvers who make the ideas tangible.
Product Leadership
Leaders who enable the system. They create space, set the bar, protect time to learn, and align teams around outcomes. They lead with clarity and context, not command and control.
These competencies might not map to your current job titles. In fact, they usually don’t, especially in traditional HR orgs. But they need to be covered. Somewhere. By someone. Without these skills, the system will default to delivery over discovery, output over outcome, and activity over impact.
What You Start to See
When an organisation truly embraces the product operating model, several observable patterns start showing up:
Focus on outcomes, not output. Success is measured by the value delivered to customers and the business, not just by work done.
Empowered teams making decisions. Teams operate autonomously, with everything they need to deliver complete solutions, and are trusted to make decisions.
Continuous discovery and delivery. Teams talk to users and ship in short loops
Clear strategic alignment. Every team’s work is directly connected to the organisation’s broader goals, ensuring cohesive progress. There is a shared language around value and impact.
Culture of learning and adaptability. A safe environment encourages experimentation, learning from failures, and continuous improvement.
These shifts represent a fundamental transformation in how the organisation thinks, operates, and delivers value.
Where You’re Starting From
Everyone starts from a different place.
Some people find themselves in traditional HR functions that are reactive, process-heavy, and undervalued. Others are experimenting with agile practices, trying to work in new ways inside organisations that haven’t caught up yet. Some are already in progressive environments, but still looking for the scaffolding to turn intent into capability.
We speak to a lot of motivated individuals who know there’s a better way to work, and are hungry to bring that future forward.
But the hard truth is that if things are going to transform, the organisation has to choose to undertake the journey.
And that is hard.
Because it requires different decisions, different behaviours, and different expectations from leadership, from teams, from everyone.
So while individuals often spark the change, it only becomes transformation when the organisation chooses to go with them.
The Enabling Conditions That Make It Real
Most transformations fail. My belief is that this is because of the conditions - the invisible structures and expectations that shape how work really gets done.
If you want this to work for real, you need to start by changing what the system allows, encourages, and enables.
The Seven Enablers of Transformation
These are the seven conditions we’ve found to be consistently necessary for product-led transformation to take hold - not just inside teams, but across the organisation.
1. Visible leadership commitment
Senior leaders understand and support the shift with both words and actions.
They’re clear on outcomes, aligned on priorities, and creating space for teams to work differently.
Without this, everything else is theatre.
2. Enabling structures & support
The structure, incentives, and rhythms of the business enable the transformation.
This includes roles, governance, data access, capacity, and clarity of accountability.
3. Redefining success through outcomes
There’s a shared understanding of what success looks like, not just for the business, but for employees.
Teams know what they’re aiming for and why it matters. Without this, work defaults to output delivery.
4. Ownership closer to the work
Teams have real ownership of a problem space.
They’re trusted to make decisions, test ideas, and learn without waiting for permission.
5. New operating rhythms
There’s a working tempo: structured rituals, regular reflection, continuous decision-making.
Work moves forward in loops, not lurches.
6. Culture and Language / Mindset & language shifts
The way people talk about the work reflects the way they actually do the work.
You hear words like “problem space,” “test,” and “learning” instead of “handoff,” “rollout,” and “comms.”
Culture is what gets said and done, repeatedly.
7. Feedback & learning loops
There’s space and expectation to reflect, adapt, and improve.
Learning is continuous, not reserved for retros or quarterly reviews.
If there’s no learning loop, there’s no transformation.
These enablers work together. They form the infrastructure for a different kind of organisation that is more adaptive, more focused, and more human.
Get the enabling conditions right, and the rest gets lighter.
Start Small. Learn Fast.
If you are leading a product transformation, your North Star probably needs to be something like:
The percentage of product teams who can work with autonomy and clarity, who have a direct line of sight between what they do and what matters.
And that will look something like:
Teams have a set of leading indicators and they can demonstrate how their work is influencing them.
They’re able to engage directly with the people they’re building for, without unnecessary approvals or process overhead.
They can stay anchored to a long-term vision while making consistent, visible progress - and tell a clear story of learning, momentum, and iteration over the past few months.
The way they’re resourced aligns to the nature of the work, whether it’s early-stage exploration or ongoing improvement of an established solution.
They’re not stuck executing outdated plans. Their focus is on solving problems that are relevant right now.
The first step is always local, so start with a single team. Find one team, one opportunity, and one meaningful problem to solve. Use the method to implement the method.
Make sure that team has what it needs to:
Connect directly with the people they’re trying to help
Design and deliver without waiting on layers of approval
Stay focused on a single space, without being pulled in five directions
Pause, reflect, and adapt based on what they’re learning
From there, run a complete loop:
Spot an opportunity
Understand the problem
Build something that addresses it
Learn from what happens
If that team completes the loop, even in a small way, you’ve made real progress. That’s one team working in a new way. Now ask: how many more teams can do the same?
The transformation occurs when the patterns within that pilot team become the norm.
So your goal then is to raise the percentage of teams working this way until it becomes the default.
Use the levers to intentionally shape the environment around the team so this way of working is possible
Visible leadership commitment
Ownership closer to the work
Structures and support that remove friction
New rhythms and rituals
A language that reinforces clarity and learning
Success defined by outcomes, not effort
Feedback and learning loops
Where to Go From Here
If this way of working feels right to you, but you’re not sure where your organisation stands, you’re not alone.
Transformation is complex, but it can start with clarity.
We’ve developed a set of practical tools to help you understand where you are today and what might need to shift. If you’re just beginning, you can use our Product Operating Model Diagnostic to assess the conditions in your environment. It’s designed to surface what’s already in place, and where the gaps might be.
For teams further along, we also offer a deeper set of capability assessments at the role level, helping you identify where strengths already exist and where you might need to grow.
If you’re navigating this work and want help interpreting what you’re seeing, we’d be happy to talk. This work is hard, but it’s worth it. And you don’t have to do it alone.




This is so helpful and well laid out. Definitely sharing this with a few folks we have started working with to paint the picture of where we are headed.