Stop the Meetings, Start Building: Product-Led Transformation

Paul Svoboda at UXDX USA. Video: https://youtu.be/1U_Dfyl5REc

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.

Too late, too niche, too far

[00:00:08] Hello everybody. My name is Paul, and today I want to talk about how a small team within a 350-year-old company was able to change how teams build and ship products without asking for permission or even a mandate.

[00:00:26] So how did I get here? Well, it took three things I had to learn the hard way. The first was that I was definitely too late. The second, I was too niche. And the third one, I was too far.

[00:00:42] Early in my career, I worked at a digital agency on a connected car experience for one of the largest German car manufacturers. I was working on one feature: the lock status of your car. And this is everything that we could do back then: "Your car might be locked." The problem was that the system was capable of tracking when the remote key was used, but not when the physical key was used. So if somebody was locking the car the old-fashioned way, we simply didn't know.

[00:01:19] The reason for that is simple: what gets tracked and what doesn't was decided years before I even touched the product and was part of the product team. This taught me a very, very valuable lesson: being a product person also means being part of the decision making. If you are too late to the party and all the decisions are already made, you're not shaping a product. You're just decorating someone else's constraints.

[00:01:54] This then led me to my next role, within a startup called Kobe [?]. We had the goal to disrupt the bicycle industry, and to be honest, I had everything that I was looking for. I had product authority, I was involved in the decision making, and we were building a really cool product. We were able to turn any bike into a smart, connected bike.

[00:02:24] But when I took a step back and looked at our customers and users, I realized that we were actually working on something that I like to call champagne problems. What I mean by that is that they were buying a $350 device to put on a $3,500 e-bike that they already owned. So I had the feeling that they were already good. Of course you can always do better, but I really believe that products can change how people behave. You can help them change their behavior in a way that's good for them. I really believe that products have that power. But if you choose an audience that is already okay, this is where I think I was a little bit too niche.

[00:03:14] To be honest, I was super excited when I got the call, was invited to the interview, and then at the end was asked if I wanted to join Merck KGaA, Darmstadt, Germany. It's a company with 62,000 employees, operating in three main business sectors: healthcare, life science and electronics. We are serving millions of customers, patients and scientists in the world. I joined Merck KGaA in Germany in a group function, up there. As you can see, I was pretty far away from the people down there.

[00:03:59] My official title was head of prototyping, and I was sitting in a lot of meetings with different teams, trying to help them build better products and services for our customers. But what I realized is that I was actually in a position that didn't allow me to do a lot, because the organization was just so big. We have 62,000 people. We have the three businesses. We have different countries, different franchises, different product teams, and they all work on different products.

Project mindset versus product mindset

[00:04:32] I realized that the way I was working, or most people were working, was a little bit contradictory to my past experience. I would say I grew up in a product environment with a strong product mindset, while this corporate setup I am currently in is more project-oriented. How do you know that this is the case? It's questions like, for example, "When is the product actually done?" I sometimes get a funny look when I say never, because I truly believe that you should evolve and work on your product until it's reached its full potential. There are also other questions, like "Do you have a mandate?", "Who is going to present this?" or "What's the change management plan?"

[00:05:31] In theory, both approaches actually want to do the same thing. The project and initiative approach, where you have a lot of meetings, workshops, alignment and a lot of documentation, is actually there to help others, in our case, build better products and services. But what I believe is the better approach, and something that is easier to scale, is to have this product mindset: to do research, build something, and then validate whether this really helped your customers, in this case your colleagues and co-workers, or not.

The Fogg behavior model

[00:06:12] If we say that products can change behavior, the big question is of course how products can actually change behavior. Therefore I really like to bring up the Fogg Behavior Model. It was invented by a guy called BJ Fogg, a professor at Stanford University, and it's a very simple way to think about it. I really like it because he says you need three things to converge in the same moment to change a behavior.

[00:06:45] The first one is motivation. How motivated are the people to act or perform the behavior that you want? For example, if you have a questionnaire with 20 to 30 questions, you might want to give them a voucher, something like an Amazon voucher, so that they are motivated to do it. On the other axis, you have ability. How easy is it to perform the task? If it's just one question, you might not need to motivate them that much, because it's so easy to do.

[00:07:15] You can see the action line here. Motivation and ability correlate, and together they create the action line. He says that a trigger, or what he now calls a prompt, is successful if it's above the action line. If it's below, the trigger will fail. Let's keep this in mind, because this will be the main theme of the rest of the talk.

The Liquid design system

[00:07:47] The idea was that we built a product lineup of things that will help the different teams in our company build better products for our customers, scientists and patients. We call this Liquid. All the products that are connected to this portfolio, these individual subproducts, are meant to change one aspect of the product development cycle. Why Liquid? You can ask me at the bar; it takes a little bit longer to explain. This is our product portfolio, and I just want to give you a quick introduction to all of them.

[00:08:30] The first one is the Liquid design system. The behavior that we wanted to change is, I think, very obvious. We had all these different teams building the same components over and over again. We paid a lot of agencies and developers money to build the same component many, many times. They all looked different, and this also meant that we had a very heterogeneous experience, and our customers basically had different apps on different touch points. So the idea here was really that we have a design system that people can use and work with.

[00:09:10] We did something in 2018 that some corporate people would maybe call career-ending: we launched this thing without asking for permission. We even decided not to put any password protection or anything on it. Yes, we had some terms of use, but we put it out there and said, "Hey, everybody at our company, please use this." And the good thing is we saw adoption. People used it not because we asked them to, but because for them it was the most logical choice. It was a React-based component library, and everything was good. We saw great adoption.

[00:09:51] But then in 2021, I was sitting together with my team, and we looked at all the feedback that we got. We got a lot of complaints from developers who were using Vue, Angular and other systems. There was this rising star, this promise from web components, that we could create a framework-agnostic system, and in theory it sounds amazing. There were also definitely some problems with accessibility, things that we wanted to tackle.

[00:10:26] And then a year later, I had to realize that I had violated my own rules. The reason for this is mainly web components, because I was mainly listening to the people who were not using the component library, and not to the ones who actually loved the components and worked with them every single day. Web components pretend to be React components, but they are actually not, and a lot of folks who are React developers didn't like it, because it was just frustrating for them to work with. So ability went down, and the worst thing that could have happened, happened: people stuck to the old library and didn't adopt the new one, in 2024.

[00:11:16] Then in 2025 we launched a new version, with user intimacy. We really talked to our closest users and customers, and we also introduced an AI-first thinking approach, because we knew that developing products will be different in the future. This is where we are currently. We see great adoption. People feel heard again. We are back to React components, so the developers love them. And for the first time, we developed this together with our life science business, because they have the biggest need. So they were not just users; they are now partners. That's how we created our design system.

The Liquid strategy kit

[00:12:04] A design system can really change how products look and feel. A strategy kit is meant to change the way people think. You have to understand that we have a lot of product managers at our company who are scientists by training. They are chemists, or work in different fields, or are even physicians. They work on these products and have a deep knowledge of what's going on. On the other hand, I realized that they are not so familiar with user research, and a lot of their decisions were made based on their own experience. What we wanted to do was provide them with methods like Six Thinking Hats, product love letters or innovation boards, so that all their product decisions are grounded in real user research and feedback.

[00:13:01] We collected all the knowledge that we had gathered, on Confluence for example, and we put all of it on a website that we call the Liquid strategy kit. We tried to map this to the double diamond process, so you can decide whether you're still more in the strategy phase, whether you're already ideating, whether you're prototyping, or whether you need to validate. We saw great adoption among the different teams.

[00:13:33] But the most important thing for me here was that we were so pleased and excited that all these methods were freely available to us that we decided to make this available to everyone else as well. If you go to the link or scan the QR code, you can access it for free, because we really deeply believe that if we get something from the community, we have to give something back. So that's a product that is definitely meant to change how my company works, but is maybe also helpful for others.

Liquid images and the agentic workflow

[00:14:04] The next product in the product line is Liquid images. This is actually our newest product. You can imagine that the challenge we face is that we still pay a lot of agencies and content creators to create content, and if they are capable of using AI, they mostly produce things that are not brand compliant. Even worse, sometimes they use really funny stock images. So we wanted to build something for them that makes it very easy to build brand-compliant assets and content, and we created Liquid images.

[00:14:50] Liquid images is very, very easy. You just enter a prompt, select the style, select a color theme and an aspect ratio, and the image will be created for you. There is also an editing mode, so if there's an aspect of the image that you don't like, you can easily go in there, type something, and it will be done for you in seconds. Currently we are in a rollout phase with roughly 400 users, and this summer we want to launch it to all 62,000 employees at our company.

[00:15:28] The magic is actually not the interface itself, and we have to explain this to almost everybody who wants to hear it: the workflow is the magic behind this. We tried to put all the knowledge that we have about AI image generation into what you can call an agentic workflow. The user enters a prompt. The prompt is analyzed, and we first try to find out: is this a real image idea, like, let's say, a snowflake or a snowman, or is this just a theme, like winter? So we give feedback based on the prompt. Also, in some cases you are not allowed, for example, to create humans with a certain style, so we will then give feedback to the user.

[00:16:18] Second, if the prompt was accepted, we then use an LLM to transform it. We call this a magic prompt, and it has all the knowledge about how the styles need to look and how the prompt needs to be written, for the model that has a trained LoRA on top of it. You can think of this as a small layer that knows how our brand needs to look. Then, with the correct prompt, you generate an image that looks very close to what brand would consider brand compliant. Then we have another step, the last one, which is the Nano Banana editing step, where we do the final touches.

[00:17:04] This brand compliance block is actually very relevant, because AI can make mistakes. We use the LLMs to look at the image, and we use a deterministic method to grab all the pixel values and see the delta between the desired value and the actual value, and then give feedback on whether it's brand compliant or not. We also have things where we have to be careful, like competitor brands on products, or just think of somebody touching a chemical without wearing gloves. This could actually hurt our reputation, and this is why we have this LLM as a judge as an extra security layer. And whenever they download or want to download something, we do an image upscale for them, or we do the vectorization. So this is really the end-to-end process that runs and drives Liquid images.

[00:18:02] How do you know that you're successful? This is Kai Beckmann [?], our new CEO, and he made a LinkedIn post with an image that was created with Liquid images. This is not a mandate. This is actually adoption.

Three plays for shipping inside the walls

[00:18:17] Before we take a look into the future and the products that we are currently working on, I want to share three plays for shipping inside the walls. The first is that you need to build something before somebody says yes. This is sometimes even the case with my own team. For example, with Liquid images, I was the one who tried to understand how we can train models to reproduce our brand style. And it's the same with others. If you have a wild idea, not everyone can challenge the status quo the way you can, or envision what you have in mind or see.

[00:19:01] Even though I like the radical approach, I want to soften it a little bit with the second one: the people who will defend or use your product, you should involve them. If you build a product, let's say for legal or procurement, involve them in the process. Make them your partners, your power users, or even co-own it with them.

[00:19:23] And the last one: someone somewhere in your organization is actually waiting for your product. We've built a ton of other stuff, and it's just amazing: there are sometimes people who build things with it that I couldn't imagine. So always look out for those people. They will help you scale your products inside the company.

AI and the Liquid agent kit

[00:19:44] Let's talk about AI. I know that's an important topic, and a lot of people feel a bit scared or intimidated by it. Will it take away some of our jobs? Will it replace product? To be honest, for me, as someone who thinks about products as something that can solve problems, it's actually the best time ever, because AI has made it faster and cheaper than ever. If you are really into problem solving, this is your time to build, and there's no excuse anymore. We also realized that we need to keep up with the development of how software is developed, and we thought about the process and what we need to do to enable basically everyone in our company to build software.

[00:20:37] The foundation is still the same: we have the design system, we have images and we have the strategy kit. But on top we built something that we call the Liquid agent kit. There are a lot of tools out there, or Medium posts, that try to explain how you write better prompts, how you do a planning phase, and how you talk to your agent to get what you want. But the challenge is, first, how do you enable people who are not software developers to write code? And second, how do you make sure that if you have a team of four to five people, they all work with the same standards and methods?

[00:21:20] The framework that we are currently working on is a set of agents that will allow basically everyone to contribute to the product. We have an agent that helps you create structured outcomes. For example, we have the ability to create issues based on stakeholder input or on insights, all in a standardized way, and the agent will also ask follow-up questions if something is missing. Second, we also commit and track work with it. We have these commitment sessions where we sit together and say, "Hey, these are all our issues in the backlog."

[00:22:02] I also want to say that we are really trying to move away from Figma and Confluence, at least as our single source of truth. We're really trying to move over to the code as the most important thing. So we now do issue tracking in GitHub. We have these commitment sessions, and you can then just talk to your agent and say, "Hey, can you assign me to issue 64?", and then together with the agent you can say, "Hey, I would like to develop it." We also have methods to write a product development plan that has all the knowledge integrated: what is our technology stack, how do you deploy something. Everything is included there, ready to be handed over to sub-agents that will execute it for you.

[00:22:50] We also have review, ship and close agents that do the rest of the work. The amazing thing is that now everybody can contribute to the project. If there's, let's say, a small feature that needs to be developed, a designer in the team or a product manager can now do it, and everything is consistent with our guidelines and our own development standards. And you can access it all in Claude Code and OpenCode [?], in the CLI or in the local apps.

Liquid research and the outcome engine

[00:23:24] That was the Liquid agents. Another thing that we realized is that if we can now develop software and products so much faster, we also have to keep up with insight and knowledge generation. We have Liquid strategy here on the right, and the next product that I want to show you is Liquid research.

[00:23:48] In the past you had two options. You could do qualitative research, where you have deep user insights and you can ask follow-up questions, but you're basically limited by the human factor. You cannot just have 50 or 100 of these interviews, and certainly not at the same time. Quantitative research is great because it's more quantifiable and you can do it at large scale, but you cannot ask follow-up questions. This is something that we wanted to solve with Liquid research.

[00:24:22] This tool is now capable of taking questions. As, let's say, a UX researcher or product person, you can enter five questions and also add a mission for what you want to achieve with the questionnaire, and it will then ask follow-up questions so that you get a better understanding of what is actually the driving factor: why they behave the way they do, or why they do what they do. For me that's the super exciting thing, because with that we can really speed up development and research at the same time. What is also important, of course, is that you try to teach the model what good practices are. You want to teach it that it shouldn't ask leading questions, for example. But this is something that is solvable and that you can easily do.

[00:25:11] This is our framework. We call it the outcome engine, where we have the basic products on the bottom, design, images and strategy, and now our agentic enablement kit on top of it. We really believe that we can ship products for internal and external use 10 times faster, and this is something that we couldn't do before.

[00:25:38] This is how a small team inside a 350-year-old company changed behavior, and changes behavior, through products. So let's stop the meetings and start building. Thank you very much. If you are interested in talking to me about trust in scientific AI, the outcome engine, generative AI or cyber-physical trust, here's my email, LinkedIn and website. Feel free to reach out. Thank you very much, and enjoy the conference.

Q&A

[00:26:13] Host: Great stuff. All right, let's see what we have here with some questions. How did you spread the word about this design system across such a huge organization?

[00:26:27] Paul: There are these centralized teams, and of course we tried to reach out to them to spread the word. But there are so many channels. We have an intranet, where we did a post, and there are a lot of marketing opportunities within the internal communication channels.

[00:26:50] Host: In a company with 62,000 employees, how many are part of the design team? How about the development team? Might as well break into product for this one also.

[00:27:00] Paul: It's relatively small, I would say. We have all these different teams, and I can't really tell how many designers and developers there are. It's probably between 100 and 200. We are a science company, so it's mainly about technology and pharmaceutical stuff. But there are also a lot of agencies and freelancers that worked with us or helped us in the past. And I believe that with all the capabilities of AI, it will probably be even easier to ship products, even with smaller teams.

[00:27:42] Host: Was there pushback from development teams on your implementation of agents, and how did you overcome this challenge? And there's also a question there on security.

[00:27:51] Paul: Yes, we definitely had some discussions about AI slop, whether we are feeding the machine with even more AI slop, and whether all the bugs that we encountered were down to the AI or our own fault. That's definitely a problem. When it comes to AI and the agents, we are in a lucky position that we have a huge AI and data department, and they provide basically all the models to us, so we can use them in a safe environment.

[00:28:28] Host: Did you try to jumpstart adoption by focusing on one client within your company, or did you launch all at once?

[00:28:36] Paul: Our main focus was always life science, because we also develop products for scientists, and to be honest there's a big opportunity for us as a company when it comes to digital products. So yes, life science was definitely our main focus.

[00:28:56] Host: Okay, and the last question here. Did the design system block creativity at all?

[00:29:03] Paul: That's a good question. For me, no, because our goal is to solve problems, and if we need to argue about how modules should look, this will just slow us down. So I would say no, it didn't.

[00:29:15] Host: Great.