From IT-Driven to Product-Led: Bridging Design, Product, and IT at Scale

20 May09:30 – 10:05Stage: Main StageTalk
Slides

Checking session availability…

Hang tight while we load the latest updates.

Steven Roest, a former designer turned product leader, shares his experience navigating the complexities of building IT4IT products at ING, a global organisation with 30,000 employees across 12 countries. In this talk, he discusses how he has helped ING transition from an IT-driven approach to a product-led operating model by integrating design thinking into product management and IT processes. Through real-world examples, Steven explores how ING is addressing challenges such as aligning local and global needs, setting clear standards for product maturity, and breaking down silos between business, design, and IT. This session highlights how a design mindset can transform IT from a cost center into a collaborative force driving product innovation.

From IT-Driven to Product-Led: Bridging Design, Product, and IT at Scale

Steven Roest at UXDX EMEA. Video: https://youtu.be/8FonAOslAm0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Death metal, art school and the power of empathy

[00:00:12] Steven: Good morning. Good morning. I have good news for you: I have a talk that is guaranteed AI-free. When I was 16 years old, I pretty much knew what life was all about. I knew how life should be lived. At least, that's what I thought back then. I was wearing long hair, clothes as black as I could find them, and listening to death metal. And I think this is a nice example of a logo of a death metal band that is utterly unreadable. It's a bit of a thing in the death metal scene. Blood Incantation is the band name, for those who want to know. So, listening to music that makes your ears bleed, I knew one thing for sure: that I would never ever do something as boring as becoming a lawyer or working at a bank. So here I am. But you could also say I achieved 50% of my life goals. And to friends I know from that period, I say I work at a financial institution, to avoid the word bank and refresh their memory.

[00:01:32] So, 16 years old, looking for a place to go to college, and it didn't matter that much where I would go to college, as long as I would go as far away from my parents as possible. Now, I lived in the center of the Netherlands, and the Netherlands is of course quite a small country, so it's quite disappointing if you want to go really far from your parents. I knew I wanted to do something creative. So I thought, well, maybe I can try the most prestigious academy of the Netherlands, the Rietveld Academy, and otherwise I can go to the AKI, which is quite close to the border here with Germany.

[00:02:15] First I went to apply to the Rietveld Academy. I went there, portfolio under my arm, and I vividly remember looking at the people over there. They were actually a bit weird people, and I was sort of looking down on them. I liked creative, but not this creative. These people were wearing purple skirts and they'd hand-painted white flowers on them. And I wanted to be this sophisticated, distinguished graphic designer with black turtlenecks. And I thought, well, that's clearly not going to happen at the Rietveld Academy. So I went to the east of the Netherlands.

[00:02:57] A couple of weeks ago I went to a vendor of ING, and it's actually located right across the street from the Rietveld Academy. I was half an hour early, and I thought, well, let's sit on the bench at the Rietveld Academy and look at those people again. And I remember how glad I was to see all these creative people, these free thinkers, these square pegs in round holes. And I was wondering what has changed over the years. I think what changed was that in my life I've seen way too much mediocrity, too little creativity. But the other thing that had changed is that over the years I learned about the power of empathy. Empathy is our ability to look through the eyes of somebody else. Every design thinking process also starts with empathy, and that's also how I tend to solve a problem. I start with empathy, and I think more people should do that.

[00:04:05] If I look around me, I see too little empathy. I see designers looking down on engineers, engineers looking down on designers, and everybody looking down on product managers. Yeah, I've been one, so I know. But it's a bit like, if you don't have the brains to become an engineer, and if you don't have the creativity, you end up as a product manager, somewhere on a scale of usefulness probably between a rock and an empty beer bottle or something. Anyhow, lack of empathy. And I think that every minute that we don't empathize, we get stuck in miscommunication, lack of alignment, prejudice, leading to frustration, distrust, even anger. In short, you're losing money, and you're losing it fast. So I think we need these engineers, we need these designers and we need these product managers, and we need them working together. And designers, I think, are ideally positioned between them to bridge that gap.

[00:05:22] Like I said, I have been a product manager, but I've actually played on all three sides: design, UX and IT. So maybe that is also a bit where I learned that empathy. I'm now able to look through the eyes of all three sides. Recently I became lead product experience within ING, and more specifically lead product experience in the tech department. The tech department delivers services and products to the rest of the ING organization, which consists of 60,000 employees. So I think there are just as many opinions on what makes a good product, and I think that's also what made my job really interesting. In this talk I want to tell you a bit about how I helped ING transition from being IT-driven to becoming product-led, and how this design thinking mindset can rock the IT and business world.

From country silos to a scalable tech platform

[00:06:27] First I want to take you a bit back in history. Ten years ago, in 2015, ING was very much siloed. Every country was more or less its own autonomous business unit, with its own vertical tech stack, a stovepipe, with their own hardware, operating system, middleware, and then the business applications on top of it. And the involvement of ING as a group, overarching the whole company, was quite minimal. But then in 2015 they decided it was time for a change. They said, "Okay, we're going to build this scalable tech platform, because it makes no sense to build the same hardware ten times in ten countries over and over again, reinventing that wheel." So, a solid reason, I think, for that change.

[00:07:26] Now, if you move up the tech stack towards the front end, you see that local preferences become more of an issue. For the back end, the end customer will not notice whether an application is hosted on Spanish hardware or on German hardware. But for the front end, you saw that countries make more of an issue of saying that it's really specific to local markets. Luckily, even for the front end, we found that there are quite some commodities that we can share across these countries. This tech platform provides these services and IT products, but also, as a country, you can for instance build a product and publish it on that tech platform for other countries to reuse, which is quite beautiful. But the countries who build it must make sure that they build it really scalable. So we have this one engineering system that helps them build these scalable products. And then you can become a provider and a consumer of products at the same time.

What is a product: 33 criteria and six convictions

[00:08:38] You hear me mention the word product a lot, and I will mention it quite a few times going forward. But getting to this shared mental model of what a product actually is took an insane amount of time. Yesterday Mikaila also talked about the common language in an organization, how hard it is. And we experienced the same with the word product. It felt a bit like comparing apples and pears sometimes. Because a mortgage feature, with an entire flow and back end and whatever, that is a digital product. But maybe one of the APIs you use within that flow to do this small approval and consent, that is also a product. So are we comparing apples and pears? I think that was a bit why the discussion was taking so long, and also because everybody felt impacted. Not only engineers or designers felt impacted, but also finance, tax, architects; everybody felt impacted.

[00:09:54] But at a certain moment we did get to a common understanding. We saw that even though those products might be different, there are characteristics of a good product that they all share. We found 33 of those characteristics and we grouped them into six convictions. Onboarding process: that is of course how easy it is to get started with a digital product. Engineering experience is about how well the product is integrated into that tech platform. Is the documentation proper? Can you do it without human intervention? Those kinds of things. Service model is about availability. Do you have agreements on that? How do you deal with incidents?

[00:10:43] Optimized charging is also really important. We charge, as a global provider, the consumers of the products, and they of course want predictable charging, and they want it optimized based on their actual usage. And we had another challenge, because when you build scalable products, you don't want to penalize the first adopter of that product by giving them the full cost of the product. So you also need to be a bit clever with that. Then we have roadmap prioritization. You want to have clear, transparent criteria for how the product teams prioritize feature requests, and you want to make sure that the consumers are also able to influence that priority, either via user boards or in other ways. And lastly, you don't want the product team to be the bottleneck, so you should be open to contributions, either via code, or in people, or in money. So we have all these 33 criteria grouped into six convictions, and you can score every criterion on four levels. That's the closest we could get to a measurable product experience, and that was quite a milestone.

Six tracks for the product operating model

[00:12:04] As I just mentioned, everybody felt impacted, was impacted or could be impacted, and we wanted to help people embrace this new product model, product operating model I should say. So we came up with six tracks to help departments organize around these products. Leadership trinity: good news, design gets a seat at the table. The weird thing maybe is that the trinity consists of four people. I guess if you make more than a billion profit, you can just put four people in a trinity. But maybe it's also a bit that they are reluctant to let go of the word trinity, because quartet doesn't have that ring to it. So let's see how that changes over time. It's quite new still.

[00:13:04] Strategy alignment is also important. You want to have these autonomous product teams with their own vision and strategy, but you also want to make sure that it contributes to the bigger strategy of ING. So you want a drill-down from the topmost ING strategy all the way down to your product strategy. What really helps with that is, for instance, objectives and key results, or KPIs, those kinds of things. That's slightly longer term. And then of course you have a quarterly business review, which is for the slightly shorter term.

[00:13:45] Product manager maturity: that is an interesting topic. At ING we have a bit of a weird history of giving confusing function titles to product managers. Ten years ago it was formula manager. Then it was blueprint consultant. I've been a blueprint consultant, but I never put that on my CV or LinkedIn. The weirdest function title of the list. Customer journey expert. And then product owner entered. Woohoo. But that was only on the business side; on the IT side that was called a feature engineer. Now, finally, we have the product manager. So, luckily, an industry-standard function title, but that of course also comes with industry-standard expectations. So this track was really about how we can make sure that the product managers level up to that industry standard.

[00:14:50] Then the productization framework. I mentioned the six convictions with the 33 criteria, and the whole idea is that both consumer and provider agree on what makes a good product. Building globally scalable products can come with a conflict of interest. Sometimes what's good for a local country is not good for the company as a whole, and you have to make some trade-offs. I think this productization framework was perfect for actually documenting these trade-offs. And the good thing is that, like I said, you can score the product experience on these 33 criteria, but you have the provider that does a self-assessment, "How do we think it's going?", and the consumer also does an assessment. Obviously, the interesting discussions are where the opinions on the maturity or the quality differ the most. And we wouldn't be ING if we didn't have a cool Power BI dashboard to show it. I'm not that much of a fan of reports and Power BI dashboards, but in this case I really feel that it's materialized empathy for both provider and consumer.

Compelling roadmaps and the alignment problem

[00:16:15] Compelling roadmaps. Making a nice roadmap is an art form by itself, and I've seen many, many roadmaps in my life. I would almost say nobody knows roadmaps better than me, but then there's always Donald Trump. In the old days, what you would see is that if an engineer created a roadmap, he would create a roadmap with all information known to mankind. It would probably have a thousand lanes, with all the small bumps and fixes and features, and probably only a horizon of four weeks, because beyond that, it depends. If a product manager created a roadmap, it would probably be in Excel, a list of prioritized features, all nice and probably very valuable, but maybe utterly unfeasible. If a designer created a roadmap, he or she would ask, "Who is it for?" Because the designer understands that a roadmap shown to a CEO needs to tell a different story than a roadmap you show to the development team.

[00:17:32] But those were the old days. I think now, in the meantime, we are able to create roadmaps for the right audiences. But that is actually only where the complexity starts. Imagine that you have ten countries, with in each country 30 initiatives that each have their own roadmap, and all these initiatives depend on one or more of hundreds of shareable products that also each have their own roadmaps. How can you make sure that you align all these roadmaps? Because if those roadmaps are not aligned, that leads to tactical solutions, which will be technical debt later, or it leads to waiting or other inefficiencies. And I don't have the solution yet. So if anybody has a solution for how to align so many roadmaps, please hit me up. We did get better over time, but this is still a challenge in such a big company.

The Obeya room and visual communication

[00:18:37] Last one: the Obeya room. For those who don't know, obeya is a Japanese word that means large room, so Obeya room would translate to large room room. The Obeya is a collaborative workspace where the leadership team can come together and do some decision-making, and really connect strategy with execution. On one wall you might have your delivery portfolio, and on another wall you might have your operational health metrics, your availability, those kinds of things, and on another wall even the OKRs. The good thing is that it's all in one room, so you can make decisions. Because what is typically the case in big corporates is that a problem is always a dilemma. It's always about choosing this over that. If you want to do something here, it probably means doing something less over there. In this Obeya you can really make these decisions with all the information that you have.

[00:19:51] But the important thing is that you want to make sure that everybody gets to a common understanding as fast as possible, and this is really where visual communication helps. With charts and graphs, for instance, you can make complex information snackable, and with color, for instance, you can really get to an emotional level. We all understand that a chart that is in full red is more important to look at than a chart that is completely green. And the last thing: I like the trust and transparency of this room. Everybody gets to see the same information, everybody can see where the issues and the problems are, and everybody can also walk into that Obeya.

[00:20:40] So do not underestimate the power of visual communication. I think this is really where this distinguished, sophisticated graphic designer can do an awesome job, but maybe even better, the creative thinker with the purple skirt with the white flowers on it. And I think also, like Jeff said yesterday, designers are the number one communicators of the heart and soul of the company, so they are really equipped to do that visual communication.

Takeaways: empathy is key

[00:21:20] Takeaways. In order to get what you want, think about what others want. If you cannot do it alone, you've got to understand what makes people move. The second one: in companies, problems are always dilemmas, so it's about choosing sides. I think the one who is able to tell the most compelling story gets to choose the side, but you've got to make sure you understand who your audience is. And the third one is maybe a bit for the people who work in big corporates, but you've got to get to that shared mental model with everybody, whether it's digital products or jobs to be done or customer journeys, whatever. And once you get to that shared mental model, you've got to go all in.

[00:22:24] Biggest takeaway: empathy is key. If we can all, a little bit more consciously, choose to put away our biases, assumptions and prejudice, and try to look through the eyes of somebody else a little bit more, I think our companies would do way better, and I think also the world would be a better place. Thank you.

Q&A

[00:22:56] Host: Steven, well, wonderful way to kick things off. Great level of humor, really lovely final message there. We have some questions from the room. For anybody who has joined us since the beginning ramble from me, the QR code is new for today, so make sure you scan that and get your questions in. I'm going to be slightly cheeky as host and ask you a question first before we move on to these. The Obeya rooms: love that, large room room, everything up and visual. How does that work digitally? Do you have a digital space for your Obeya, or do you always bring people into a physical space?

[00:23:32] Steven: That's not only cheeky, but you're really poking where it hurts.

[00:23:39] Host: It's all right, I'll leave.

[00:23:41] Steven: No, it's a fair question, because ideally you want to have this physical room. I really love the physical room, because I want to be like Kim Jong Un pointing at things. I like that, and touching things, and putting something from left to right. That really helps. But indeed, we have distributed teams in, I think, five countries. We have hubs in Poland, Romania, Spain, Turkey, India. So we also have to have the digital equivalent. What we're now trying to do is a bit of both, because we also feel that physical has its limitations. Sometimes if you look at an issue, you want to drill down: okay, which epics are connected to it? So it's always a combination of physical and digital. That's how we do it.

[00:24:35] Host: Nice, standard middle-of-the-road answer. It has to be, right? It's the world we live in. Everything's hybrid.

[00:24:43] Steven: It has to be hybrid.

[00:24:44] Host: Fantastic. The top two questions are fighting with each other a little bit, so let's dive in before it changes. OKRs, a way of setting goals in a previous life, pre-product. What tips do you have on using goal-setting techniques like OKRs in a more product-led approach?

[00:25:04] Steven: I'm a big fan of OKRs, and I've been advocating for them, and very much struggling with them a lot. So we have also been learning. You always have the dilemma of cascading OKRs. Do you really want 100% cascading of OKRs from top to bottom? Our answer at this moment is no. But you want to make sure at least that OKRs are not going in opposite directions. The second learning we have is that OKRs really have to be measurable. You really quickly fall into the trap of having something that is not measurable, or where you say, "We're going to measure it somewhere along the way," but then they are completely useless. And the last learning that we have is that you cannot stop at just defining your objectives and your key results. You also have to think about what the initiatives below the key results are that really bring you to that key result. Because those also define your product roadmap, and if you don't think about that up front, then you get into problems later on. So those are the learnings we have for objectives and key results.

[00:26:28] Host: All right, so a little bit more connective tissue from that objective and key result that's hopefully clear on paper. We were talking yesterday, over the beers, about maybe using easier language in OKRs, but also more connective tissue down to what it actually means at a product level; otherwise they get disconnected.

[00:26:44] Steven: Indeed, yeah.

[00:26:46] Host: Amazing. So, obviously ING is a big, big company. You fulfilled half of your life goal, to not end up in a bank. In a big company, how did you advocate to facilitate that change as a designer in that company?

[00:27:04] Steven: Yesterday, what struck me in the responses is that the designers seem a bit scared of AI, and I think they underestimate the power designers have. The way I looked at myself was that I'm like a wolf in sheep's clothing. I entered that IT department as one of the first UX designers, and those people didn't know what was happening, because I was telling them that there were users on the other end of the software, and they didn't know. But I think as a designer you really have the position to give them a different way of thinking, to help them think outside of the box. So as a designer you should maybe focus a little bit less on crafting that UI, and really think about how you can change people's minds, change people's thinking. I think as a designer you have that power to do so. And if you just get stuck in your tunnel vision about your next UI, then you will be replaced by AI. But think about the power you have to help people think differently.

[00:28:25] Host: Nice. This is a good and difficult question from Christian, so early in the morning, but something I think we've probably all faced a little bit in the room. Steven, how are you handling those spontaneous legal requirements, the thing that has to be done right now? It's a sudden shift, "We need to do this," versus all of that careful roadmap planning you've done.

[00:28:49] Steven: I do a bit of a reverse trick: I try to delay them. Typically what they say is, "This has to be there. European regulation. Everybody will be extremely mad if you don't do it." But then I really need to see that proof, and really challenge them on those legal requirements, because I think often they get through too easily, while you're not even sure that they are required. So delay it a bit, and meanwhile focus on cool stuff.

[00:29:26] Host: Amazing. Delay legal, focus on cool stuff. What a great way to end things. Ladies and gentlemen, your first speaker today, Steven Roest. Thank you.

Speaker

Steven Roest

Steven Roest

Lead Platform Experience

ING