Breaking Silos: The Shift from a Software Delivery to a Product Development Mindset

Mihaela Draghici at UXDX EMEA. Video: https://youtu.be/QA9gUVsNfcU

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.

Shifting from projects to products at Volkswagen

[00:00:01] Hi everyone, it's great to see you all. I must admit it's really a pleasure to be here. I was thinking this morning that it's actually my fourth year at UXDX, and it's always great to be back. I realized how much I identify, in my day-to-day work, with the UXDX model and their mission and what they're trying to achieve through this conference. And also there is an alignment with what we've been trying to achieve at Volkswagen in the last few years, namely a shift from projects to products, specifically in our case in building digital products for the automotive industry.

[00:00:48] And it's been quite a ride, and that's what I want to talk about today. I want to share with you some of the problems we faced because of these silos that exist between the business and IT, how we ended up in that situation, how we changed our team setup in order to break these traditional silos, and some of the learnings we gathered and some of the results we had along the way. I hope you will get some interesting insights and maybe some of you will identify with some of the situations we faced.

[00:01:28] Before I go into details, I want to give some context around the software development centers and our mission. As you can imagine, Volkswagen has been building software the way it's been building cars, using waterfall. No surprise there. But over the last few years the group has been taking a lot more initiatives to shift to a more agile approach in software delivery, and this is how these centers were born across Europe, one of them being the one in Lisbon that I am part of.

[00:02:01] We wanted to bring change to how digital products are built. We work in cross-functional product teams, we employ extreme programming practices, we put a lot of focus on user research and discovery phases, we use an outcome-oriented approach. So as you can see, it's quite different from what waterfall would represent.

The silos, and the challenges they created

[00:02:28] However, over the years in building products for the group, we faced a problem, and that's mainly because of how we were organized and how we were set up. It emphasized the traditional silos that already existed between the IT teams and the business teams.

[00:02:54] And these silos led to a series of challenges for our teams. So for example, from the product teams we would always hear that it's very difficult to get involved in vision and strategy decisions. Usually these decisions are made in executive management meetings where plans are defined, budgets are approved, and then we have to deliver based on these plans. And we felt that it's usually very difficult to negotiate and adjust course when we gathered new information on the product, or new data, new information from the users.

[00:03:39] Another challenge was giving visibility over our work progress. Yes, we did have regular syncs and a continuous collaboration with our stakeholders, but in many cases it was hard for them to understand why we do certain things, why we have certain activities such as building a prototype to validate a solution with users. And ultimately it was hard for us to advocate for our values and for our practices.

[00:04:14] Similarly, for the business teams, again the conversation was difficult when trying to align on product decisions. It was a tough negotiation most of the time, because everyone had different expectations, different availability. There were already these preset plans that we had to stick to. And again, for our stakeholders it was difficult to understand sometimes why we wanted to do things in a different way, and it was difficult for them to shift the mindset from the project planning mode into the product development mode. I think some of you might have seen this in your own organizations and might find this familiar.

[00:05:03] What happened was that because of these differences in expectations and experience, we had a lot of communication problems between our product teams and the business, and these problems led to sometimes delays, led to frustration, lack of motivation, lack of trust. So we were quite like, how did we end up here?

How we ended up here

[00:05:32] In order to better understand that, I want to give you some context around our traditional business process when it comes to taking on new product initiatives. So generally there is some initial research made, usually with an external company. A solution is proposed, there's a project plan defined, a list of requirements defined, a budget is approved for that specific plan, and usually this process takes a very long time.

[00:06:06] Then teams like ours come in to do the actual development based on these plans. So we're introduced to the problem, we're introduced to a solution, and we're told what to deliver. And that's where we try to introduce our ways of working and negotiate on next steps. So for example, doing further research, getting more up-to-date input from the users, better understanding the problems, better understanding their needs, ideating on solutions that we would then test before going into delivery.

[00:06:45] And to give you an example, this is exactly what happened. It's a real situation, when our colleagues from the Volkswagen commercial vehicles team, from the sales and marketing department, came to us with a request to help improve the experience of the ID Home[?] community users. So, build something that would enable these community members to get together and share information, share updates, reviews, questions about the new ID Buzz. There was a lot of buzz around it. And also the brand wanted to share exclusive news and exclusive information.

[00:07:26] So they came to us and they said, we've done the research, we have the solution, we want you to build it. And that's when we insisted on running a discovery phase to get to know these community members, get to understand their needs, and figure out how to build a product that will serve their needs. What do you think happened? Do you think we succeeded? I'll let you know later.

Our setup, and the invisible wall

[00:07:57] Before I get to that, I want to give some context around our setup and what exactly had to change. As I mentioned earlier, we work in cross-functional product teams. Maybe nothing new for many of you here. We work very closely together at every stage in the product life cycle. At discovery stages we come up with solutions together, we then test and validate, and in the ongoing product delivery we also collaborate. And as part of the extreme programming practices, we do pairing. You heard that mentioned in the presentation earlier. It's really cool.

[00:08:34] Every time we take on a new product, we get together with our stakeholders and we present — and present is the keyword here — we present our practices, our way of working, and we try to align on the next steps. And at this point we expect that everyone understands what we're doing and everyone agrees with it.

[00:08:58] Alongside our product teams we have the business teams, and usually in these teams we have a business product owner and other members of the specific department that are relevant on that topic. They're usually what we call the interface to the corporate landscape. They're the ones that deal with these executive committees, project planning, internal approvals, legal topics, and all sorts of other aspects in their department.

[00:09:31] Usually the PM and the PO work very closely together. They have regular syncs, they collaborate on quarterly plannings and generally keep each other updated on the work progress. However, we tried to intentionally shield the product teams as much as possible from interferences and distractions coming from the business side, mainly because we wanted the product teams to focus on the users, to focus on building the right products, to focus on building quality products without distractions.

[00:10:06] And of course this led to this big invisible wall between the two sides, that created all the challenges I mentioned earlier. So for us it became very, very clear that we have to come up with some ways to break down these silos: because we wanted to have a better collaboration with our stakeholders, because we wanted to get involved in vision and strategy and generally have more ownership over the product decision-making stages, and obviously because we wanted to advocate for a more agile, user-centric approach in product development.

The new working model

[00:10:46] Now, the solution that we came up with was a new working model that doesn't shift us away from the way we do things, it doesn't shift us away from our guiding principles or from our practices, but gives our stakeholders a better understanding of what we do, and gives us a better understanding of some of the business needs and the business processes.

[00:11:12] And we trialled this out across four new products with four new product teams over the last one year and a half, working with different departments in the Volkswagen group. We didn't start it off with everything at once. We started off with one team, and then as we were taking on new products we were taking learnings from the initial setup and adapting it based on the new team's needs.

[00:11:36] So what changed? Basically, from having these two teams working in silos, we formed one cross-functional product team in which we involved the business, in which we actively involved the PO. And we wanted everyone to have the same level of ownership and responsibility over the product and over delivering value for the users and value for the business.

[00:12:06] Now this was a very big change, mostly because involving the PO in the team meant having the PO working with the team at every stage in the product cycle. So all these activities that the product team would generally do in isolation and then present the results to the stakeholders and expect the buy-in, would now involve the PO. So think, doing discovery together: we would sit down and define the research objectives and a research plan, write user interview scripts. The PO would shadow or even actively participate in the interviews, cluster the findings, synthesize the insights and then define user personas, come up with solutions together, then prepare for testing and validation, and then work together also in the continuous delivery phases.

[00:13:13] As I said, this was a big change for us, and initially it was seen with fear and concern. And there were valid questions coming from the team that were asking, well, wouldn't involving the PO in the user research actually interfere and affect the results? Wouldn't they be biased based on their experience, based on their knowledge?

[00:13:43] We had been disruptive in introducing new ways of working to the business, and this time it was on us to disrupt our own setup, because it was time to acknowledge that what we had was no longer really serving our purpose and no longer helping us. So we had to stick to our values, right, and be adaptable and flexible and embrace this change, try it out and see how it goes.

Working model agreements, and workshops

[00:14:14] So the way we went about it was creating this new working model agreement. Basically, when taking on new products, instead of just presenting our ways of working to our stakeholders, we created this series of collaborative workshops where we bring everyone together and align on specific responsibilities, specific tasks and who does what. We also align on common tools or communication channels. We used existing frameworks, we created our own as well, and also adapted things as we figured out what works and what doesn't.

[00:14:55] The main idea by bringing everyone together to work in these workshops was that everyone gets a clear understanding of their role in that team and of their role in the product, and everyone has the sense of ownership over the success or even the failure of that specific product.

[00:15:17] There's the trick: these workshops were not easy. It's nice when you present the story, but in reality, in some cases it took more than one session to reach agreements within a team. In many cases it became even clearer how everyone had a completely different understanding of agile and agile practices. There were knowledge gaps, which we had to address by organizing further trainings or workshops on introducing design thinking frameworks, or training on how to run user interviews, how to define user personas, different frameworks for prioritization, you name it.

[00:16:04] We also realized that we need to repeat these workshops at every stage in the product cycle, because each step includes a different set of activities. So you cannot really do it once in the beginning and it's the same all throughout. And we had to have a trade-off here and understand that we need to invest a lot of time and effort in these sessions in the first phases, but also a bit throughout, to make sure that we have a better collaboration, that we work better together.

[00:16:37] Another thing that had to change was around the product team activities or ceremonies that were initially reserved for the team and would now include the PO. And again this change was seen with some hesitation. There were concerns around, if we have the PO in the retros, how would that affect the team honesty or the team morale? Or even from the PO side, how would I fit all these activities in my already busy schedule?

[00:17:10] So we gave each team the flexibility to align on what would work best in their context. So some of the teams said, okay, let's do it, have the PO in the weekly retros and see how it goes. There were teams that said, okay, maybe we can organize a separate session every two weeks dedicated to that.

[00:17:32] Over time, by putting everyone to work together like this, we saw that the connections were getting stronger and we had better relationships and more trust, while each side had a better understanding and more empathy, if you will, towards the other. And it was cool to see that, from being considered this bunch of kids that love colorful Post-its and whiteboards and spend hours in a room drawing stuff, we were now perceived as trustworthy professionals that know what they do and build quality products. So our work started to actually make sense for our stakeholders, and that was a big achievement for us.

How we measure whether it works

[00:18:21] Talking about how we would measure if this works or not: for us, we collect feedback regularly from the teams in different ways. We look at the product success, so how is it being perceived by the users, is it being used as intended, what's the feedback, what's the impact on the business, as opposed to the number of features we've delivered. And we also look at future investments coming from the departments we collaborate with on new product initiatives. And mainly we also want to see if we're shifting this needle in the other direction, if we get more input and get more included in the product decision-making process in the earlier stages.

What we learned: people and processes

[00:19:15] Now, I hope you're still here, still listening, because I want to share some of the things we learned on this journey and some of the achievements, some of the results we had. And the first I want to start with is about the people. It's the most important part. As we understood, some of our POs didn't know much about software development or agile practices, and we realized that we needed to gain trust in a very short amount of time even though we didn't speak the same language. And by including them in our day-to-day activities, we realized that that actually helped considerably. It made a big difference.

[00:19:58] However, there are still people that are very much familiar with a certain way of doing things because that's how they've been doing it for years and years and years, and it's hard to change. It's hard to shift this project mindset that is still prevalent in some cases, where people are still thinking, here's the list of features, you deliver it, that's it, we move on to the next thing. So what we understood was that it is important to put in time and effort in the beginning, but this is an ongoing journey and the team has to be on board with it, and it's a matter of continuous and constant advocating for our practices and for our way of doing things.

[00:20:41] Another thing we learned was around internal processes that are not yet suitable to help us in the way we work. As I mentioned, there are these executive meetings and internal committees where the conversations still focus on features, on outputs, and we constantly need to push the discussion towards the value for the user, the value for the business. And there are other processes, like the internal software approval process, which is not yet adjusted to help us roll out to the users faster and quickly validate and reduce risk. We had situations where actually getting the approval for a product to go live to users took longer than building the MVP, which is not great. Fortunately this is being addressed on a group level. We're working closely with our colleagues that are responsible for it, because we really do want to build a streamlined, faster and simpler process that can help us roll out to the market in a shorter time.

[00:21:47] There is a lot of flexibility in many areas, but there are business domains or organizational structures that do have a lot of restrictions and limitations. So for example, working with the production department, we learned that it is very difficult because you cannot be as flexible as you want. There's little room for experimentation and you actually have to always get it right. If you build software for production and that thing fails, production is impacted, therefore business is critically impacted. So here we do have strict deadlines that we need to stick to, we do have a list of functionality that we need to deliver, we do have more thorough checks and approval processes that we need to follow, and as I said, there is little room for experimentation.

Results

[00:22:40] However, on the product that we built for the production department, which is this really cool Google Street View for factories, by working very closely with the PO we helped them understand the value of user research and validating with users before actually implementing certain functionalities, and they're now actively supporting us in our initiatives to do user research.

[00:23:06] And talking about the value of user research: going back to my colleagues from the Volkswagen commercial vehicles team, yes, it did take quite some time and quite some work, but we managed to convince them when we got approval for a discovery stage, where we did evaluate the input from the initial research and also did further research focused on the product. So we managed to change their perspective, and we were all surprised actually how much we managed to learn from our customers. And also in this process we managed to create more trust and establish ourselves as reliable colleagues and reliable professionals that do care about building quality products.

[00:23:52] Now the PO is advocating for our practices and showcasing the product inside their department. They're doing product demos or talking about what we do, and they're actively supporting our initiatives for doing further research or setting up product analytics tools to generally have a constant flow of data that could help inform our product decisions.

[00:24:17] On another topic, this is on one of the products that we're working on for the procurement department. If the PO in the past would spend time preparing a vision, a long-term strategy and a plan, getting it approved with the management and then presenting it to us, we're now actually working together on that, and we are actively involved in these management meetings where we can continuously push the conversation towards what value we would deliver with the product. And that gives us more flexibility over the roadmap and generally more ownership over the product decisions.

[00:24:53] And even though there are some limitations in some areas and there are some restrictions, we've noticed that this needle is actually shifting in the other direction and we are getting involved earlier in the product decision phases, and we have generally more ownership over what is being built, which is amazing because that's what we wanted. And we've seen also more investments coming from the departments we work with on new product initiatives, where we no longer get involved there, but more at this side[?].

[00:25:31] And the last thing before I go, I wanted to share another great success, and I wanted to mention this because this is actually happening this week while we're here. It's the Volkswagen Group IT Symposium. It's a global event introducing innovative digital products and innovative ways of working and practices from different areas of the business, and one of the products we're building was invited to be showcased at this event. And this is big for us, because we get exposure to different areas of the business, we get to showcase the value of the way we work, and we get to get closer to this mission of shifting towards a more agile approach and a more user-centric approach in product development.

[00:26:21] Before I go, I wanted to give a big, big kudos to the wonderful people here. As I mentioned earlier, we trialled this out with four new product teams, and these people are the ones that shared from their experience and worked on these things and helped me put together all the information that I shared with you today, that I hope you would find interesting and useful. Some of them are here actually, so you can meet them throughout the day and continue the conversation if you will. I would encourage you to do so. Thank you very much, have a lovely day.

Q&A

[00:27:01] Host: You went from software delivery to product delivery. What were some of the big cultural challenges on the team?

[00:27:09] Mihaela: I think one of the biggest things is around the people, and that's what I mentioned. I think in the beginning we were very enthusiastic about putting ourselves in our bubble, introducing these new ways of working, hiring great professionals that are on board with it, setting up these wonderful teams that do great things. But then we separated ourselves, kind of intentionally, from the business that was not familiar with this way of working. And we had to realize that it would then take a lot of time to actually bring them on board and help them understand the way we work and the value of what we do. And it was not enough to just talk about what we do, because if someone doesn't have that hands-on experience and understanding, they won't get it. So that was the challenge, and the way we addressed it was by actually involving them actively in the day-to-day work.

[00:28:16] Host: Yeah, okay, wonderful. Let's take some audience questions. So let's go with first: as you know, people don't respond well to change. Who communicated the change of working model, and what was the reaction of the team, and how did you handle the change management?

[00:28:33] Mihaela: This is an interesting one, because I think there was a lot of feedback coming from the product teams and there were a lot of conversations, and as we later found out, the same conversations were happening in the other software development centers. So everyone was aligned that there is a problem and everyone had kind of the willingness to look at how can we make this better, how can we change the situation. And it became a bit of a collaborative effort of a group of people getting together and thinking, okay, let's trial something out.

[00:29:09] And the thing is, it wasn't big changes, it was smaller things initially. We started with one team, let's see how it goes. We then did it with another team, let's see how it goes. And yes, there were, as I mentioned even in my talk, there was hesitation, there were fears. And usually you manage that by talking to people and getting people curious about, okay, let's try this out, because we're not in a great situation but we can actually have an opportunity to make it better.

[00:29:42] Host: Certainly. I give lots of trainings to product and design leaders and they always have this thing about, I need to go and sell this idea. And I'm like, go get a friend, go get a guinea pig, go get the person who's willing to be your early adopter as your example, because then you get more buy-in.

[00:29:59] Host: All right, people want to get hired. Are you hiring? Five thumbs up.

[00:30:02] Mihaela: Yes, we are hiring product managers and designers and developers, because we have cross-functional teams. Find Maha, apply for a job.

[00:30:11] Host: All right. So, when you're exploring your audience's unspoken needs, how do you approach this from a research perspective to make sure you cover the important topics with such a broad audience?

[00:30:23] Mihaela: When you're exploring unspoken needs. It's a long one. Okay, I'll try to answer this, I hope it does answer the question. The products we build for the group are either internal-facing products or customer-facing products. And that's why it was very important for us to get our stakeholders working closely with us, because they are the ones that actually in many cases are helping us out to reach out to users, to do user interviews, to do user testing, and put us in touch with the relevant people from the departments that we build products with, or put us in touch with the relevant people from the customer side.

[00:31:11] Host: Let's take one more question. Let's go with: do you work with a single business unit or PO, or multiple, and how would you balance the structure with many business stakeholders?

[00:31:22] Mihaela: So yes, on each of the products we have different stakeholders. Each of the product teams have different POs, because they work with different departments building different products. I don't know if that answers it. Basically each team is autonomous and independent, and they form this unit with the business team.

[00:31:45] Host: Do you have to use different techniques or methodologies with different stakeholders, given they have different desires, North Star metrics?

[00:31:53] Mihaela: Oh yeah. It's different departments, different people, it's very diverse.

[00:31:56] Host: Wonderful. Then let's squeeze in one more then. What was the role of a PO, and why are they not originally part of the product team?

[00:32:06] Mihaela: That's a very good question. So the business product owner is a function on specific departments. So let's say an area of the business, say the production department, has a problem to solve and they form a unit, and in this unit you would have a product owner that is the main person responsible for building a business case, and then finding the relevant companies, the relevant organizations and the relevant people to put things together, start some initial research, then get the plans approved, get the budgets approved, and then generally make sure that things are being done according to those plans.

[00:32:52] And the idea was that over time we also understood that there was a bit of an overlap in terms of responsibilities, and what we do, between our product teams and what the PO and their teams were doing. So actually by putting everyone together we're reducing the duplication of work and those overlaps, and basically trying to integrate everyone in the same unit, in the same team.

[00:33:16] Host: So it sounds like they're kind of playing more of like a program management role, maybe a bit of analyst, but they're kind of like your counterpart on the other side of the business.

[00:33:25] Mihaela: Yeah.

[00:33:26] Host: Thank you for your great questions and great answers. Thank you. Let's give one last round of applause. Maha, thank you very much.