Productside Stories

From Project to Product: Leading Real Transformation with Joeri Devisch

Featured Guest:

Joeri Devisch | Product Transformation Lead at EY
01/04/2025

Summary  

In this episode of Productside Stories, Rina Alexin speaks with Joeri Devisch about the intricacies of leading transformation efforts within organizations. Joeri shares his extensive background in technology and product management, emphasizing the importance of understanding both the technical and commercial aspects of product development. The conversation delves into the differences between transformation and change, common pitfalls organizations face during transformation efforts, and the critical role of people in managing change. Joeri also discusses the concept of T-shaped individuals and their significance in driving successful transformations, as well as practical advice for product managers looking to lead change initiatives.  

  

Takeaways  

  • Product management is central to organizational success. 
  • Transformation is a mindset shift, not just a process change. 
  • Effective communication is crucial in transformation efforts. 
  • Understanding the human side of change is essential. 
  • T-shaped individuals are key to successful transformations. 
  • Training must be complemented with coaching for effectiveness. 
  • Internal buy-in is necessary for transformation success. 
  • Pilot teams should be selected strategically for learning. 
  • Continuous learning and adaptation are vital in transformation. 
  • Product managers should focus on the whole product, not just features.  

   

Chapters  

00:00 Introduction to Transformation Leadership 

01:50 Yori’s Journey into Product Management 

06:44 Defining Transformation vs. Change 

12:37 Common Pitfalls in Transformation Efforts 

18:34 People-Centric Change Management Strategies 

23:06 Understanding Organizational Missteps in Transformation 

27:53 The Importance of Communication and Context 

34:02 Training vs. Coaching: The Key to Successful Transformation 

39:25 The Role of T-Shaped Individuals in Product Management 

46:12 Advice for Aspiring Change Leaders

 

Keywords  

transformation, change management, product management, leadership, organizational change, T-shaped individuals, agile, product mindset, transformation pitfalls, coaching  

 

Introduction to Transformation Leadership

Rina Alexin | 00:02.52–01:03.595

Hello everyone and welcome to Productside Stories, the podcast where we reveal the very real and raw lessons learned from product leaders and thinkers all over the world. I’m your host, Rina Alexin, CEO of Productside. And today I have the pleasure to be speaking with Yori Devish. Yori brings over three decades of experience in technology, transformation, and change leadership with a very diverse background.

across cloud, IoT, video and digital services. He’s seen many pivots, transitions, change of all kinds at companies from startups, scale-ups to global multinationals. Most recently, Yori held their leadership role at EY, driving product transformation. And today, we’re going to be discussing what it really takes to lead transformation efforts, what organizations get wrong or right about change efforts.

You’re welcome.

Joeri | 01:03.595–01:07.054

Hello, thank you for inviting me.

Rina Alexin | 01:07.054–01:46.209

this is a topic that I think is near and dear to both of our hearts, because it matters so much. Product is at the center of any company. Product management has to drive product led cultures and it’s, it’s really hard, right? It’s really hard to get a whole organization moving in a product led way. So I’m excited to talk to you today, but before we get jump into that discussion.

I always like to hear everybody’s story because it’s usually different. So why product management? How did you end up in this career?

Joeri | 01:46.209–03:51.448

Well, when I graduated as an engineer, electrical engineer, I kind of had the idea that software and ICT would be safer for my life rather as working with high voltage electricity type of systems. So I immediately switched careers, going into ICT software development. But from a personality perspective, I’m kind of a learner. like solving problems and challenges. I mean, that’s when you get to engineering, right?

And I, when you do software, you’re often blamed by either end users or the database administrator or the network engineer that the software is wrong. And of course you’re always like, it’s not the software. So from there you start learning systems, data networks, you start learning all kinds of things, end users. And before you know it, you’ve done in a couple of years, you’ve done pretty much all the roles in ICT.

And when you go from there, you get into project management. When you start kind of selling your projects and your vision and your strategy and your budgets to management, right? In a company or to clients, you kind of start seeing, well, maybe I can also do that with clients. And you start transposing that experience to discuss with clients, business development, pre-sales type of roles. So I went from ICT.

into telecommunications because there my understanding was you could do that also in telecommunications. I did their managed services. I started doing pre-sales for managed services, complex projects, all kinds of stuff because you’re young, you want to learn things. And at one point we were doing video solutions, complex IPTV, video solutions, telecom, data network, software, clients, business development.

But we made a switch from developing software in-house strategically at corporate level to basically doing Microsoft.

Yori’s Journey into Product Management

Rina Alexin | 03:51.448–03:53.035

was you the dog it’s I need to hear it

Joeri | 03:53.035–03:58.156

The dog is annoying, you hear it? I thought it was, I would cancel it out. Let me get rid of it.

Rina Alexin | 03:58.156–04:01.005

Yeah, no, it’s not canceling.

Joeri | 04:01.005–04:03.358

So we would cancel it out like this.

Rina Alexin | 04:03.358–04:31.053

It should, but your mic is picking it up pretty clear. Waiting to see if it’ll go down, but no.

Joeri | 04:31.053–04:32.364

Better? No?

Rina Alexin | 04:32.364–04:34.103

No, we hear it. It’s not a parking.

Joeri | 04:34.103–04:40.261

Damn, what’s with the dog? Let me do it. This is so strange.

Rina Alexin | 04:40.261–04:50.638

I don’t why it’s picking it up so well. Because usually, doesn’t always pick it up unless it’s in the same way.

Joeri | 04:50.638–05:03.15

I tend to do this on

Rina Alexin | 05:03.15–05:35.917

you

Joeri | 05:35.917–05:37.198

Okay.

Rina Alexin | 05:37.198–05:43.213

Yeah, I didn’t want your whole episode to just got barking. Let’s see.

Joeri | 05:43.213–05:48.376

Good. So, start again? Alright.

Rina Alexin | 05:48.376–06:08.042

Yeah, yeah. I’ll cue you in before we get started into that discussion.

Rina Alexin | 06:08.042–06:49.751

And today we’ll be discussing what it really takes to lead transformation efforts and what organizations get right and wrong about change efforts. So, I have to repeat that, sorry.

All right. Today we’ll be discussing what it takes to really lead a train. Now I’m messing up. It happens. Okay. Today we’ll be discussing what it really takes to lead transformation and what organizations get wrong or right about their change efforts. You’re welcome.

Defining Transformation vs. Change

Joeri | 06:49.751–06:52.128

Thanks for inviting me.

Rina Alexin | 06:52.128–07:07.361

Yeah, well, before we get started in that discussion, I always like to hear people’s stories because I get a different response every time I ask this question. So, Yori, can you share why product management? How did you end up in this career?

Joeri | 07:07.361–09:26.029

I think the general reason why I ended up in this career was actually the fact that I’m being an engineer, being graduated as an electrical engineer, I switched to ICT. Sounded like safer than just dealing with high voltage type of systems. But I’m basically being an engineer, I like learning, I like challenges, I like solving problems, preferably for people. And that way I basically went into ICT.

software development at a time when assembler C and C++ was still a hot topic. And at one point I kind of had like, why is always the software engineer blamed for the failures of the system? When it actually might have been the data network or the IT system, the database, or somebody did not explain very well what the requirements were. So I started learning about data networks. I started learning about IT systems.

I typically knew the problems because I was working in industrialized environments. But from there, I basically ended up doing project management because I kind of had like a very broad view on ICT technologies and users. You can easily do conversations with all types of people, discuss all kinds of topics. You’re kind of becoming more and more theoretically generalist, but you come from a specialist environment.

And at one point when I was a project manager, I was doing strategic projects because the projects always got bigger and I kind of was probably reasonably good in explaining why I needed to budget, why we needed to do it this way from a project approach. So I kind of said, well, let’s switch this around. I never intended actually to do kind of a sales or a pre-sales role because I typically…

I’m somewhat allergic to car salespeople, for instance, trying to explain me a car. So I didn’t want to do it, but when I saw that I was selling the projects, well, okay, I said, why not do business development? So I moved into telecoms instead of just ICT, I moved into the telecom world, telecom vendor world, doing basically business development and pre-sales tendering for complex solutions, transitions from 2G to 3G, managed services, data centers.

Joeri | 09:26.029–11:39.968

And now we’re talking data centers, not when the cloud was there, but data centers 2002, which was the early days, right? You know, telecom, know, ICT, you do business development. At one point I was just leading teams of architects doing presales. And at one point when in the company we had to do a switch from doing internal software for video solutions, IPTV video solutions, think Comcast type of solutions, but that on

copper networks rather than escape on networks. We were actually asked by the corporate strategy to say, well, we’re going to do Microsoft now as a software vendor because credibility as a telecom vendor in software is not that high. And we’re going to stop, we’re going to help our internal developments. We’re going to keep the customers that have the product going. We’re going to only sell Microsoft. We need to change our go-to-market strategy. I had a Microsoft background coming from ICT. So basically I was asked to say,

basically do reworked strategy. And one of my VPs told me, Yuri, you should do product management of your professional services. And I was like, wait a second, I’m an engineer. A product is something I can touch. It might be software, not touchable, but it’s a product. And after some time and some discussions in the team, we said like, wait a second, what we need to do is industrialize the professional services approach. Industrialize.

how we will deliver, make sure that we can deliver and scale it, make sure that we have pre-sales material which is convincing, bring our expertise which we had anyway talking to clients as being kind of explaining the project as what we sell. And then bundle the third parties being Microsoft plus some hardware plus the professional services as one solution. And we do a level of pre-integration of the solution. We kind of explain it. We say that’s on the roadmap for the solution.

But dear customer, you’re so special. We need to do a customization. That’s how we will deal with that customization because that’s what we do in onboarding you to the solution and later supporting you to the solution. And that way I ended up in doing product management for professional services.

Rina Alexin | 11:39.968–11:50.295

So Yuri, sounds like big, you know, I don’t often meet people with the background with engineering and also having that commercial mindset. And it seems like because you were also involved on the pre-sale side, you understand that it’s more than just about the product that you build. It’s about the commercial reality for the business or for the user, right? So you have both sides.

Joeri | 11:50.295–12:00.567

That’s true.

Joeri | 12:00.567–13:17.24

Yeah. Yeah. think, I think one thing which is, think is important that came, that came from my project management training back in the long time ago, previous century to be honest, was actually, goal directed project management, actually says a project by definition is a change. Therefore it is people, systems and organization. And you need milestones across those three swim lanes in order to be successful.

And the same applies to product and the same applies to a lot of things. I’ve been using it for pretty much 30 years as an argumentation to either upsell, explain our positioning better to the client, kind of emphasize, empathize with the clients so that we kind of can say, yeah, we understand your problems, these and these and these things we can help you find. I think the key question to answer in product management, in my opinion, is if the client, if you reach the C level in pre-sales and the C level asks you,

How do you guarantee quality? You need to be able to explain that. How will you work with my teams to basically make my transformation as a client successful? That’s when basically the other answer you need to have. If you cannot answer those two questions, if I would be the client, you would be out of the room. That’s kind of where it sits.

Common Pitfalls in Transformation Efforts

Rina Alexin | 13:17.24–13:25.345

So then how did you get into the position of actually leading transformation projects?

Joeri | 13:25.345–13:47.31

By training and by helping people, coaching people, gathering a team around me that could actually deal with the complexity of the solution, because one person cannot deal with the complexity. One person can understand certain areas and then get the right people on board to basically drive it as a transformation. And transformation is change, right? It’s pure change.

Rina Alexin | 13:47.31–13:58.369

Okay, actually, let’s define that a little bit better because companies go through change all the time. So what separates a transformation from any other kind of change?

Joeri | 13:58.369–14:56.462

I think the transformation is typically more impacting as a standard change in a sense that if you do a transformation, you let’s take the example of I’m a project organization, which we kind of started in the late eighties and nineties and we continued a lot of companies are still very project oriented, but you could actually, if you change to a product and a product go to market, you’re doing a change to the mindset. You’re moving from start to end to a continuous

flow of improving that product to stay on top of the competition, to stay on top of the market. And it’s actually a business transformation. You’re doing a mindset and a business model potential transformation. So you need to deal with a couple of complex things which do not purely relate to process or technology or people, but actually to the mindset. And that takes more difficult. It’s easier to change software than it is to change people, to be

Rina Alexin | 14:56.462–15:19.453

So when you say you’re changing, and what we’re discussing here is a project mindset versus a product mindset, the core principles of a project is that, as you just said, there’s a start, there’s a finish, versus product is continuous delivery. So then what does it mean to have different, what does it mean to have truly a product mindset?

Joeri | 15:19.453–16:29.056

I think that the product mindset comes from, it has an aspect of agility in it, meaning you need to continuously do iterations. You need to continuously look at more areas than just what you would do in a project. You could make it more data-driven because it is continuous, plus what I find very important, and I kind of, I have to admit, I stole it from your teams. I think…

The whole product for me is an important element. It’s just two words, right? But putting the whole product in front of the word product makes it a transformation because you’re touching basically on anything. You’re touching on the end-to-end solution, business model, organization, in order to make sure that that whole product gets the right quality, the right attention, and that continuous flow, endless flow of basically continuously improving.

for value to clients, for positioning in the market, differentiation. That’s kind of why transformation is in my opinion bigger than change.

Rina Alexin | 16:29.056–16:53.069

Yeah, I definitely agree with you. And as you’re kind of talking about it, the whole product concept, it’s the product mindset has to extend past the product management team. It really touches the whole organization. So when you’re undergoing such a big change, you have to bring everybody else along and not everybody, not everyone’s workflows.

Joeri | 16:53.069–16:54.094

Yeah, I agree.

Rina Alexin | 16:54.094–17:10.357

workflows are set up in a way that can deal with also the uncertainty and ambiguity of product where you might not know what you’re delivering exactly and when and that’s hard for a lot of different departments.

Joeri | 17:10.357–17:59.864

No, I agree. think transformations to that respect, especially the complex one where you have to do that switch from project to product, they very often fail on organizations not understanding what you’re trying to do. It’s similar to a very large agile transformation. If not all organizations are on board, there is a problem of failure. So what in my opinion helps there is to have at least a team of

But what I tend to then call T-shaped product managers that actually understand what those other organizations do and therefore can easily have the conversation with those organizations and gradually bring that on board. I mean, there is a better way. It’s doing a big transformation CEO level down, but that doesn’t always work.

Rina Alexin | 17:59.864–18:16.013

Well, before we get into the people or the T-shaped people aspect, I’m curious, so you kind of started talking about what organizations get wrong about transformations. Maybe we can spend a little bit of time here. So why do transformations fail?

Joeri | 18:16.013–19:18.766

I think one of the aspects of transformations failing, and we saw that in the eighties and the nineties when we started with project management or more structured project management, is that basically we’re forgetting that change for people, individuals, is different in meaning. The human side of change, as the famous ProSky change managers tend to claim always.

is that every individual perceives the change, the reason for the change, the wording that is being used in communication, because typically change management traditionally is lot of communication and psychology, but you cannot just avoid that people read words differently and understand differently what is said between the lines of the communication. And that is where the focus on the individuals is very important.

Do they understand the same as what we are trying to achieve here?

People-Centric Change Management Strategies

Rina Alexin | 19:18.766–19:40.109

But, Yori, with, especially when we’re talking, you know, large enterprise teams, there are sometimes thousands of people involved. And so on the individual level, you can’t always know what a single person is thinking or how they’re responding to that communication. So are all large scale transformations just completely doomed to fail as part of their…

Joeri | 19:40.109–20:48.12

No, think the way I look at it is the large scale transformation, they need to take time. You don’t have a choice. You need to allow the teams, the people, the companies in many cases, the legal entities, even in a large organization, you need to give them the time to adjust. That basically means that you need to sell internally the transformation. Like you would sell a product, you need to basically explain what’s in it for me.

from different perspective for different people. Talking about a change to an engineering team or to a finance team is fundamentally different because the personalities you will find in the finance team and in the engineering team, most of them will have a different mindset from a personality perspective. So you need to focus the messaging of why you’re doing the change, what they’re gonna get out of it, what’s in it for me. You need to focus that to the teams and even to the individuals, which also means that you actually need to…

project-wise spread a transformation within large organizations across time there is no other choice. And you need to plan that correctly.

Rina Alexin | 20:48.12–21:01.773

like this idea of the transformation effort being its own product and you’re selling it internally. feel like it kind of reminds me of, know, there’s a lot of internal product teams that work on, you know, non-commercial products where they need to, we encourage them to still consider it as they need to sell it internally, right? A lot of, think a lot of IT products end up failing when they don’t have that end user in mind.

Joeri | 21:01.773–21:16.47

Hmm.

Joeri | 21:16.47–21:17.504

Yeah, correct.

Rina Alexin | 21:17.504–21:31.531

And then it’s like, no, there’s going to be a push where everybody has to use this system. It’s internal users and they’re missing that, like what’s in it for, for the users. So you’re saying similarly, you have to almost like approach it like an internal product.

Joeri | 21:31.531–22:53.56

I would approach it like an internal product. I mean, the last couple of years when I was doing the transformation, I was actually building a practice as a service product. Transforming, but building the practice as a service, which basically meant you create that continuing. You’re putting in the product definition already, the name of it is an as a service continuing. you’re actually, the reason why we did that was, well, big four are consulting companies.

They’re not software companies from a brand perspective. So it’s easier to actually get your people that need to become product managers and start changing their mindset to basically stay a little bit closer to their environment as a consultant. And so if you develop a practice as a product management, as a practice, you’re kind of putting those people potentially as consultants in the field for product management, which is closer to what they understand.

And that’s kind of a way that we explain it sometimes to the people in the teams that need to change to become product managers, right? Because you typically don’t hire everyone. You kind of create a mix between hiring people and transforming, changing people. That’s one thing. And the other thing is then you start changing the mindset. And the next step is you need to also bring the rest of the organization along. So you need to explain them and train them.

Rina Alexin | 22:53.56–23:06.017

But Yuri, isn’t there a limitation, Justin, how we’re talking about it? Because usually you don’t start a product, you don’t start selling a product into a market without understanding the needs of the market and coming with a solution already.

Understanding Organizational Missteps in Transformation

Joeri | 23:06.017–24:36.908

No, correct. So, no, no, correct, correct, correct. So, what is critical is that there needs to be a good reasoning with strong sponsorship for why you’re doing the transformation. You’re not doing the transformation for the fun of the transformation, like you’re not developing software for the fun of the transformation unless you’re in a school environment or university environment. But that’s kind of the way you need to look at it. the reason why you’re doing the transformation and the strategy behind it needs to be well explained by

the top leadership and the top stakeholders. And they, need to basically, well, and I’m thinking as a change manager, you need to help them change the message from time to time to certain audiences, because there is no choice in order to do so. Because people understand it differently. And that’s an important one to do, right? So for me, if I would take a transformation, would still, I would plan like a change manager.

So for me, what is beneficial is at one point I did the technology part, I did the profit and loss management and the business management part. But at one point I said in my career, I need to focus a bit more on the change, the change of people, because it helps me sell for sure. And it helps me internally transform. And so you need to think or you need to get support from change managers in order to define that strategy. And just like 30 years ago, you need to have

kind of planning items around how you would deal with the people.

Rina Alexin | 24:36.908–24:37.419

Yeah, I want to talk more about how you deal with people. then, because we’ve been talking about it a little bit, then, so what do you recommend in terms of having a people first change plan? Like, what are the elements of that?

Joeri | 24:37.419–24:56.973

And that’s more than training.

Joeri | 24:56.973–25:04.718

I think the elements are, and I’m referring back to Prosky with their ad-car, because, so Prosky, North American company, don’t remember whether it is US or Canadian, but they actually, what they did is they productized change management. So what they’ve done is they’ve kind of developed the argumentation of doing change in a structured way and what it benefits you and change in that case.

Rina Alexin | 25:04.718–25:15.808

Can you define what that is?

Rina Alexin | 25:15.808–25:26.497

Mm-hmm.

Joeri | 25:26.497–27:48.887

their claim and the measurements they’ve done, the studies they’ve done, they claim a six times faster change in adoption of whatever transformation you want to do, which basically means less waste. They also structured, they went into, maybe it’s a bit, it’s not comparable to digital software, of course, but they actually have a data driven approach, meaning that at an individual level, they allow you to measure

their typical process, is ATCAR, which stands for, are the people aware? Is there awareness that they need to change? Is there a desire to change the D? Is there the knowledge to change, meaning you need to train them? Do they want to get trained? Is then the ability there? They’ve been trained, but do they actually kind of understand what they’re doing and why they’re doing it? And then you need to repeat, because then you get into that cycle, right? And that ATCAR.

They develop the tools and that’s just basic Excel tools, but they actually allow you at an individual level to measure where are people in their personal journey of that transformation. Because there are two types, I mean, at the extremes, there are two types of people. There are people who just accept whatever is asked and there are people who kind of will fight it, either because they’re very resistant to change or whether they’re actually, haven’t hit an agenda, right? They might be politically.

wanting to make a career or whatever reason, that is something. You need to identify those people. So what Prosky does is data-driven measurement of where is the individual in their journey for transformation. And the other thing they do is map out the stakeholders, which is more traditional change management, map them out, make a plan for every stakeholder because you’re actually coming top down with that transformation. And then basically they…

propose a project approach or a program approach to that transformation, where basically the sponsor, the project manager managing the whole thing, and the change manager managing the communication, doing the measurement of where people are in their, especially the stakeholders are in their individual transformation. Those three work together into a plan. And there is a high level roadmap plan for those transformations around the communication and the change, right?

Joeri | 27:48.887–28:08.046

that actually becomes one larger program to do the change. And then you still need to split it. mean, there is countries, teams, divisions, depending on the organizational structure and the size, you need to split it, you need to spread it out, and you need to basically make sure that it’s manageable. But that’s the end project management, right?

The Importance of Communication and Context

Rina Alexin | 28:08.046–28:35.607

So Yuri, mean, essentially at the heart of my question here is at this point, there’s just so many materials. This ADCOR method is pretty well understood and known, I think by most organizations going through a transformation project. mean, I’d be shocked if there are transformation projects that don’t take the human or the people aspect in mind when they go for it.

Joeri | 28:35.607–28:35.682

Yeah, okay.

Rina Alexin | 28:35.682–28:44.513

How do they get it wrong, right? Okay, so you’re laughing. So yeah, how do organizations get it wrong?

Joeri | 28:44.513–29:37.582

They get it wrong by not spending enough time from top management. The sponsorship role is not really filled out, right? It’s like, I’m just doing one communication. I’ve done the preparation work of why we need the strategy. I’m doing one communication and that’s it. That’s not carrying the transformation, right? Carrying the transformation means going to the floor, explaining, listening. That needs to happen. The other element which you typically have is their

Honestly, sometimes they’re very cheap on the budgets. So if they have a change manager, they believe they can see it all. I’ve seen organizations where basically you have the sponsor role, the change manager role, and the project manager role in one manager. Depending on the size, that might work, but it’s not going to work in a large corporation. That’s too much load.

Rina Alexin | 29:37.582–29:43.819

Oh, wow. That hurt. Just like hearing you say that that is possible, that definitely hurt. So just, think what I’m hearing from you is there’s just also this assumption, and by the way, I think a lot of people get that wrong, the need for over communication, because when you’re involved, when you’re deep in a project and you understand the why or the what is happening and you say it once, you feel like, oh, they heard me, but the reality is you have so much more context.

Joeri | 29:43.819–30:07.051

No, yeah, it’s possible.

Joeri | 30:07.051–30:07.138

Yeah, correct.

Rina Alexin | 30:07.138–30:14.637

than everybody around you. And so it’s like, you need to really spend the time to explain that context and also make sure that they heard it.

Joeri | 30:14.637–32:31.563

Yeah, you need to go and talk to the receiving side to see how they interpret the wording. I mean, the wording is extremely important, right? I’ve done a couple of those transformations, project to product, and the last one I did was a very large organization. Well, it was a large organization as a firm, EY, but the team we were transforming was much smaller.

But then again, that team sits into a larger organization and you need to take the context of that larger organization into account where there is a potential risk and failure. But what you see in a lot of cases is that, let’s just, and I’ve seen it in several companies, the wording is, the terminology is a very important aspect to get it right and to make sure the other side understands it. If you’re talking about a product in a digital software company,

They consider it their SaaS or their software. If you talk about a product into a professional services organization, they might consider something completely different. So the word product is differently used. When I was part of the team that was involved in the merger of Alcatel and Lucent, two very large corporations doing telecom equipment, but Lucent was already, let’s say, on the downside of the business and they already transformed themselves to a large extent as a professional services organization.

Alcatel was still very productized, hardware, software as a vendor. But in the first conversations we had with mixed teams, the word engineering was differently understood on both sides of the fence. Because engineering for professional, for the professional services company being Lusen was actually, we’re gonna do engineering on behalf of the client as a consultant. On the engineering side,

In Alcatel, engineering was R &D, fundamental or at least R &D research for a product. But the impact is very different because on the professional services side, that engineering sits on the variable cost line of the profit and loss, and the engineering side in the product company sits on the overheads. And so managers interpret that same word differently.

Joeri | 32:31.563–32:51.384

The same with product, the same with feature. A feature in a digital software company is a capability that the product delivers to an end user. A feature in an organization that comes from a project mindset that has trained all their people, for instance, on safe, for them a feature is a planning item.

Rina Alexin | 32:51.384–33:01.047

So you’re going, so even more than just miscommunicating from the perspective of thinking that you’ve communicated but people haven’t truly heard you, you might actually be communicating one thing and people hear completely something else.

Joeri | 33:01.047–33:05.451

Correct.

Joeri | 33:05.451–33:24.812

completely different thing with the same wording. So you need to really as the change manager in that case, go check, go around, check kind of the data driven approach of product management, go and check whether the message is correctly understood and potentially give context, right? That’s why just training doesn’t work. You need to do training and coaching.

Rina Alexin | 33:24.812–33:40.619

Yeah, I mean, I would agree with you, but I almost think that in those kinds, like the more complex the transformation effort is, the more you have to do what you can to simplify or make it smaller, right? Make a phase.

Joeri | 33:40.619–34:50.584

Yeah, chunks, you need to chunk it. need to basically in iterations do this and learn. you need to, as you rightfully said, need to, like a product manager would learn from what the market and the potential clients are requiring as value, you should do the same. So you should go and talk to different division business units, organizations, potentially different countries, potentially different environments, different…

with market contexts that might happen in certain regions like the EU is not the US, right? Especially currently in the AI space. So you need to understand what those needs are because they might differ. So you should not all do them in parallel. You should really plan them. Probably pick a few pilots which actually allow you to test out the complexity, take the worst case and the easiest case and then learn from both and then assume the rest is kind of a mixture.

but then at least you’ve identified certain problems. So you’re actually doing the transformation as a product. You’re not gonna go, I mean, there are very few companies in the world that can go globally with their products immediately. That doesn’t happen.

Training vs. Coaching: The Key to Successful Transformation

Rina Alexin | 34:50.584–34:54.015

So how do you select the right pilot teams?

Joeri | 34:54.015–36:07.158

You need to, you need to, I think, I mean, as I said, I think it’s probably, you need to take the ones which are the most difficult, which might be culturally and language wise different. mean, Japan is a very good example of no English in general. They’re very hierarchical. It’s a different mindset, a different, different culture. And then you compare that to Europe or to the U.S. which is then a different mindset. If you have those two, you’re going to learn a lot from those pilots and then you, you pick.

You pick some teams to do the transformation with and you learn from it. That’s one. the ones you need to, and during those pilots, what you need to identify are who are the people who will support and help you bring the message, drive the change, drive the transformation, kind of the early adopters, kind of the business innovators that immediately see it. And who are the laggards? You need to identify both because on the laggards you’ll have to spend a lot of effort.

and you potentially want to use the actual early adopters to pick up the laggards. So you need to kind of think about how you deal with that. But the only thing to do that, to learn that, is by doing the pilot.

Rina Alexin | 36:07.158–36:20.139

It’s interesting that you said that for, so let me just clarify. So for a pilot, would you choose, a relatively quote unquote easy team? Like you would do two, you would do one that’s easy and one that you think is like more difficult. because, when if, if, cause when we, when we go through pilots, we always try to pick a pilot that would work because you also need to spread the message of, Hey, this is possible for you to do.

Joeri | 36:20.139–36:36.556

More difficult, yeah.

Rina Alexin | 36:36.556–36:36.969

Right? Yeah.

Joeri | 36:36.969–36:55.008

Agree, if you’re taking an easy team, the chances of success are course more easy than on the difficult team. But I think you then also need to balance your effort, right? In that case, you need to put much more effort on change management on the difficult team than on the easy team, right?

Rina Alexin | 36:55.008–37:01.675

Yeah, and even within those segmented groups, as you’re saying there are going to be, it’s like approaching it like the market, right? The early adopters, the laggards. So then even in this effort, then is there a change curve where there’s essentially like you’re kind of, I mean, how you answer a market can also, you know, the, sorry, I’m trying to think of that.

Joeri | 37:01.675–37:18.795

It’s like, yeah, correct.

Joeri | 37:18.795–39:43.369

The change curve is the same, right? What you would do, and I’m coming back to ATCAR, is you would measure in both sides, the teams on where the individuals are on their five steps, awareness, desire, knowledge, ability, reinforcement. Reinforcement is less important, but you need to have the knowledge and the ability is very important because the ability is the point where you can say, we’ve made it.

We’ve done the transformation. now need to make sure that it keeps running, but we’ve done it, right? The second important one is, is there a desire for the change? And that will be more difficult in a difficult, let’s call them, let’s say culturally more difficult team than it is in the other team. So you need to balance that out, but you can measure it. You need to see the progress and you need to intervene, right? You need to send the coaches, you need to send the change managers there where you see…

people not moving, progressing, because you need to progress in those names. I one of the examples I can give you that we did is we organized all kinds of trainings with Productside, Standard product management training, digital product management training, agile PO type of trainings. Especially on the digital product management side, we started a training program where we actually said like,

Okay, they’ve now had the theory of what is product management, all those things, digital product management. Now we started explaining them basically, because that’s something that didn’t happen before was we started explaining them. The product in a professional services company is something different as in a software company, because a lot of this agile and software digital product trend comes from engineering teams, right?

But engineering teams might be too disconnected from the business and from the brand, not understanding that changing a brand is something really, really, really, very difficult. And you need to basically get those product managers to understand your product is first of all, the whole product. It’s the professional services and how you deliver combined with the digital assets, data, process, software, whatever, plus your brand is a professional services brand. So you’re doing actually a solution rather than a software product.

The Role of T-Shaped Individuals in Product Management

Joeri | 39:43.369–39:53.742

Even if your engineering team says you’re going to do work, we’re doing it. Our definition of a product is a software. The actual go-to-market product is something different. And those things you need to take into account and you need to… What we started doing was actually explaining to people on how these things work. What is a software company? What is a professional services company? How does that impact certain go-to-market models, certain business models? We started explaining them.

Rina Alexin | 39:53.742–40:13.377

Thank

Joeri | 40:13.377–41:05.838

where that came from, that corporation is there. And you need to then, while the way that we actually organized it was like, we gave them the themes pre-reading material. Check these SharePoints, take these, look at these UQ movies, which actually, in an attempt to get them thinking, right? Even more than just the theoretical courses, get them to think about the whole concept and the situation they’re in.

which is a corporation, in that case even a firm, which is even more complex than a corporation. And then we asked them, present what you’ve learned to us as a team. And then we had just two people sitting there, listening, taking notes. They didn’t get it, they didn’t get it. Plus we could, during the calls, we could do some coaching, right? We could kind of explain it better. And the training without the coaching won’t work. So if…

Rina Alexin | 41:05.838–41:10.165

Yeah.

Joeri | 41:10.165–41:32.558

You’re saying in a transformation, if your management says, we’re going to give you a training budget, put everybody on training and there is no trainer in the room, which might be the case to keep the costs low with self-learning type of things. And you don’t coach and you do not create availability of experts to coach those people. It’s not going to work.

Rina Alexin | 41:32.558–41:37.389

I can only agree with you from my experience here at ProductSight. If I ever am in a conversation with the prospective client where they want to go and they want to truly transform, but they are not understanding it, it’s not just the training. The training is a knowledge transfer. helps, it sets the foundation, but it’s the work you do after. And that’s why.

Joeri | 41:37.389–42:00.694

It’s not gonna work.

Rina Alexin | 42:00.694–42:08.087

At Productside, we really put a lot of time and we continue to do so to put into the implementation part of training. So sometimes that can be done also by product leaders or by internal coaches that the company hires. But in many cases, companies don’t even think about that. They just think we’re going to do a training, a valid transfer, and it’s going to work.

Joeri | 42:08.087–42:20.68

Hmm.

Joeri | 42:20.68–42:39.233

Yeah.

No, that’s the point, right? So there is not enough investment from a transformation perspective as a budget to take care of this. It’s the same with, I’ve seen companies where engineering is considered productive work and product management is considered overhead. That’s a very strange one in my opinion. I was actually very pissed off when I read that statement, but it is like they consider…

Rina Alexin | 42:39.233–42:48.503

Wow.

Joeri | 42:48.503–44:26.647

product management as the preparation work for engineering, which of course there is some truth in it, but that doesn’t make it over it. And in fact, I would really like to see product managers to manage some kind of a backlog so that they make sure they focus, they spend time, focus time on making sure that they do competitive analysis, a competitive analysis, which is done five years ago is useless. So you need to redo them. You need to look at the market evolution.

You need to look at potentially regulation depending on what kind of market you’re in. And if product managers, which is actually a part of their role, at least don’t do this, it doesn’t work. I mean, I think there are four key value streams in product management. There is product delivery. You need to know whether it is progress, yes, no, whatever, right? And prioritize. You need to do iterative planning so that you kind of can enforce yourself in getting a feedback loop from the market and the clients. You need to do product success enablement.

which is actually.

What do I prioritize? For what reason? And then there is success measurement, which actually says like, where am I with my adoption? Where am I in my market? And if you follow those four and you plan activities on those four at the product management site, then basically you should be a, not everything has to go with the same frequency, but you need to continuously take those things into account. And that’s not overhead. That’s value. That’s continuously making sure that your product has the right value.

and can continue to deliver the value and that you’re not being eaten up by competition in the meantime and you haven’t seen it. And that those type of things are very important to take into account.

Rina Alexin | 44:26.647–44:30.414

Yeah.

Rina Alexin | 44:30.414–44:44.065

It does it, you know, think sometimes a lot of product managers have trouble also linking their decisions, like the context of the decision, everything that they’re doing, they’re working on to the actual revenue generated at the end of the day, especially with commercial products. And it’s, it’s almost like the marketing and sales teams get the credit, but without the work done properly upfront. Yeah. They’re not going to be able to sell. Yeah.

Joeri | 44:44.065–44:53.409

Yeah, correct.

Joeri | 44:53.409–45:07.118

Yeah.

Yeah, no, yeah. You have the same problem with TechDip, right? You need to clean your TechDip. You need to spend some time on TechDip because otherwise three years down the road there is no sales.

Rina Alexin | 45:07.118–45:17.111

I’m absolutely with you. And a lot of companies, I think, do get in trouble when they don’t pay attention to tech debt. But we talked a lot about the people. Iori, I want to make sure to bring this point back. We talked a lot about the people involved in the change effort. But you were talking at the start of our conversation. And I heard you also in past conversations talk about T-shaped individuals. So I want to ask you about that, because I’ve heard it in a number of different ways.

Joeri | 45:17.111–45:35.35

Mm-hmm.

Rina Alexin | 45:35.35–45:43.429

you know, what makes for a great person or like what is a T-shaped individual in your eyes.

Joeri | 45:43.429–47:12.834

I think the T-shaped individual comes from the fact that you need to have exposure and preferably experience in a broad range of roles, potentially markets, potentially companies. It doesn’t have to be everything, of course, but it helps that you’ve done multiple roles in ICT, you’ve done client facing work in pre-sales, business development, or you’ve done support to it. You’re not a sales guy potentially, but…

You need to understand business. You need to understand what value is. You need to be able to talk to clients. So to that respect, there are certain areas of things you need to understand, right? I mean, if you put an IT product manager in a construction company and you can still do product management in construction companies, they might suffer unless they stick just to the IT organization. But if they’re really going to go into construction, then they will suffer.

So you need to find people that have a level of depth, but not in one area, but in four or five areas. And that depth can come from experience. You don’t have to be the expert in the five areas, but you need to have the exposure. A product manager that has never done business or business development, to me is like, maybe we should expose them to it, right? And if you plan a career, you should plan for that having a couple of…

high level role so that you understand.

Advice for Aspiring Change Leaders

Rina Alexin | 47:12.834–47:45.537

Yeah, so I’ve seen concepts, obviously there’s the eye shape, which is just you have depth in just one area. And then what you’re describing here is, you know, there are different ones. Tea, I’ve seen pie or comb where generally you have broad, but you have depth in a few areas. And so it sounds with product managers, tea shaped.

or pie shapes, either way you need to have a really broad understanding of the business.

Joeri | 47:45.537–49:36.341

Yes, but I tend to what you see a lot today, especially in digital product management is that they want that they consider product management to be the expertise, right? So that they’re like, you know how to deal with clients in asking the right questions and making sure that you get the priorities right. know wireframing, you can prepare for an IT organization. I tend to call those people product owners, let them work between…

between the client and the engineering team and do some kind of a transformation, they can become very, very eye-shaped, specialized in, let’s call the trade of product management, the practice of product management. But you also need the right mix of T-shaped individuals that actually can think strategic, right? For me, product management has three levels. It has a strategic level, which is like two, three years down the road. Why am I doing certain things?

and always keep change in mind, right? It doesn’t make any sense to plan for two, three years in advance. You have the tactical level, which is more the iterative planning, what is my next increment? What is my next release? What will I deliver? And then you have the operational level, which is then more known in what the sprint plannings and the sprint can be anything, right? It can be marketing activities, training preparation, software development, QA, whatever. And you need those three. You preferably have that in one data set so there is no loss of

information between slides and excel sheets and share points and whatever. One set of documentation which you actually allows you to do reporting and working on strategic level, tactical level, operational level. That’s kind of the way you need to and those people that typically can do that helicopter type of view and then sometimes come down and go up again. Those people are the T-shaped people that have to lead the teams.

And then they can have high formed, high shaped type of people into the specific roles, for sure.

Rina Alexin | 49:36.341–49:43.232

And,

Rina Alexin | 49:43.232–49:45.471

and also lead the transformation efforts at their company.

Joeri | 49:45.471–49:54.99

And preferably, well, if they’re capable of leading a transformation, but then I would definitely put them onto change management type of courses so that they understand why it is important. That’s,

Rina Alexin | 49:54.99–50:10.295

Yeah. And we’ve done that also at Productside. We’ve, we’ve definitely sent our people also to change management courses. okay. So then let’s actually say that. So if there are people or product managers currently at organizations where there’s an opportunity to get involved in driving an estimation effort, what advice do you have to give to them?

Joeri | 50:10.295–50:15.797

Mm-hmm.

Joeri | 50:15.797–52:04.878

I think what is important is basically keep asking the right questions. Meaning, and you could relate it to product, right? We’ve said it a few times, transformation could actually be the product. I think what you need to…

Like when you’re talking to clients and investigating the market, what you need is keep asking the right questions. Just why, not how and what. Why are they doing it? Try to get that value. That’s an important one. I still like the aspect of Agile and I’m a strong believer that Agile can be used pretty much anywhere. It doesn’t have to be in software. I I remember my exam as being an Agile practitioner.

actually defending the castles from the armies of the pope in the 13th century. There is nothing software in there. It was a deliberate choice of that use case to get you to understand agile, take change into account, very important work, multidisciplinary. That’s an important one. I think the other one is get exchange, get exposure to change, get exposure to multiple areas so that you get that T-shaped because the T-shaped will do the transformation.

They need to be the coaches and you need to have that. The more exposure you have, the more knowledge you’re going to get out of it, right? For the good or the bad, right? You can learn from mistakes. That’s always an important point. So that is an important one. For me, the transformation again, it comes about and that’s why I like in the courses of Productside, the whole product so much. The whole product is the people, the organization and the systems, the technology. If you don’t mix those three,

You have a problem on your product management and on your transformation.

Rina Alexin | 52:04.878–52:16.983

those are all really good points of advice. I especially like the exposure point. I would say expose yourself to change and also to people who have led change to hear their war stories as well.

Joeri | 52:16.983–52:20.952

This is sometimes a story, that’s true. But I think there is a lot of overlap between product management and transformation management. You could actually do transformation as a

Rina Alexin | 52:20.952–52:30.446

While you’re…

Rina Alexin | 52:30.446–52:48.333

Well, I think there’s an overlap between product management and just about everything. It’s just core, it’s like really good transferable skills. Well, Yuri, thank you so much for coming and joining me today. A fantastic conversation. How can our audience keep in touch with you after they listen to this recording?

Joeri | 52:48.333–53:02.028

My LinkedIn profile is always updated with my contacts. I don’t post a lot, but I read a lot, I like things, but I’m not into posting yet, but I’m everyday on LinkedIn.

Rina Alexin | 53:02.028–53:45.485

Well, there you have it. please, after this episode, feel free to follow Yori Devish and connect with him. And thank you all so much for tuning into another episode of Productside Stories. If you found our conversation valuable today, don’t keep it to yourself. Make sure to share it with a friend and subscribe to Productside Stories so you don’t miss a future episode.

Visit us at Productside.com for more free resources, including webinars, templates, and other product wisdom repackaged for you. I’m Reena Lexin, and until next time, keep innovating, keep leading, and keep creating stories worth sharing.

Joeri | 53:45.485–53:45.485

Thank you.