Ways of Working: Autonomy and Alignment in a Distributed Product Organisation

Mario Ek Aparicio at UXDX EMEA. Video: https://youtu.be/IevfQ-W_Z-Q

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.

The journey of product at Vipps

[00:00:07] Mario: Hello, everyone, thanks for coming. My name is Mario. I work as a product lead and head of payment products in Vipps MobilePay. I'm going to talk a little bit about the journey we had in product in Vipps, and now the merged company, Vipps MobilePay, and we're going to go into a few questions and interactions with you, and the pros and cons of different setups and different ways of working. First I'm going to go through a little bit of background.

[00:00:42] The journey of product in Vipps. First, when I joined Vipps in 2019, we had a pretty straightforward product organization. We had a chief product officer, and all the product managers and the designers were reporting directly to the CPO. That was good. It wasn't such a big organization, so that worked pretty well.

[00:01:10] Of course, when we grew as a company we needed to scale this setup, and after a couple of years we had product areas, with area product managers and PMs reporting in there. In this setup we also had what I called a product quad. We had a kind of leadership team with the area product manager, an architect, an engineering responsible and the designer. I think that was a really good setup to lead the product areas.

[00:01:43] Then in 2022, Norway, Denmark and Finland created a group. That's the merger between Vipps and MobilePay, and then suddenly things become a little bit more complicated. Of course it's a much bigger organization and a very different way of looking at product. Now we have no chief product officer, we have no head of product development, no one person that has responsibility for product in the organization any longer. I'm reporting in to a chief commercial officer as a product lead. We have three of those, and we have tech and platform. So this is a completely different organization. We have seven product leads in the different areas here. Of course it's a much larger organization, but of course very, very different from the one we used to have in Vipps.

[00:02:38] It's not clicking. We have a technical issue here. Yes.

[00:02:55] What's bad about this latest setup that I showed you? Well, of course the product community is struggling in this setup, because there's no one person to have responsibility for that. But there are of course some benefits of a setup like that. I would say that it's extremely autonomous, because we have business units with a high degree of autonomy.

Poll: how is product organized?

[00:03:21] But now let's hear from you. What's your experience here? Just waiting to get the poll questions up here. Switch to the polling.

[00:03:50] The first question is going to be about how your organizations are structured in terms of product development and design. For example, do you have something that's along the lines of the organization we used to have in Vipps, or do you have something else? I would love to get everything up here so we can start looking into the answers. But of course all the structures have pros and cons. Now I can see it in front there. Yes, there you go.

[00:04:25] First of all, I would like someone that answered blue or yellow to give a little bit of insight into the pros and cons of this kind of setup. Anyone yellow or blue? Yellow or blue? Anyone? No. Okay. Does anyone that answered green have something to say? "We have multiple product leads reporting to business unit leaders": that's the setup we have in Vipps MobilePay. Does anyone want to comment on how that's working? Come on, I know it's past lunch and everyone's a little bit tired and digesting, but come on, speak up, let's hear about it.

[00:05:32] Yes, there. Okay, you have someone there. No. Just because no one else is speaking up. Okay, does anyone that answered pink, no formal structure, want to explain? Yeah, okay, there we go. Thank you, sorry, I didn't see you.

[00:05:57] Audience: I'm on the green.

[00:05:59] Mario: You're green, perfect. Sorry, I'm blinded by the light.

[00:06:02] Audience: My name is Ela and I work at a fintech called Dex [?]. We don't actually have this structure. What we have is product teams that report within product, but we have business teams, and the product team and the business team are not linked. So I can see a lot of value in this slightly more complicated structure, where you would link business teams to product teams.

[00:06:34] Mario: So you feel that you're closer to business, basically, because of that setup?

[00:06:37] Audience: Sure, yeah.

[00:06:38] Mario: So what do you think are the biggest disadvantages of that kind of setup?

[00:06:44] Audience: Well, the business team is coming up with ideas. They're speaking to customers and they're coming up with ideas, and they feel blocked by the product team a lot of the time. But the product team is also speaking to customers and coming up with their own ideas, and there's a bit of a misalignment between the business objectives and the product objectives.

[00:07:03] Mario: Yeah, good. It causes friction. So do you have any thoughts about how that could be sorted out?

[00:07:10] Audience: Well, I think the product team needs to continue to report into product directors, but I think there's maybe a hybrid structure where the business teams and the product teams could be more closely aligned. Or maybe product teams report to product in terms of craft, the producty bit of what they do, but then the teams could be more aligned and maybe even report into the business managers for customer centricity and planning roadmaps together.

[00:07:49] Mario: I think that's an excellent suggestion, actually. We tried that in Vipps. We have something called business teams, where we have truly cross-functional teams in addition to the product teams, where we meet weekly or bi-weekly with the commercial teams, with marketing, to work a little bit how you suggest. I think that's an excellent idea. And I think that our problem is often that product is perceived as a wall of no, and that doesn't help the craft in the organization.

[00:08:20] Did anyone who answered pink care to say something about that? I struggle a little bit seeing, so please raise your hand very high. All right, all right, let's go to the next question then. Okay, the clicker is not working. Yes, there we go.

Poll: autonomous, empowered or delivery teams

[00:08:50] Yes, here we go: autonomous, empowered versus not. Let's hear it. How are the team structures and what's their scope of responsibility? Do you have autonomous product teams that own both the product strategy and prioritization? Do you have empowered product teams that own product and prioritize it, but they do not own the strategy? Delivery teams that own part of the product, but the work is decided outside? Or do you have project teams?

[00:09:27] Yes. All right. Anyone want to share what it means to be an autonomous product team for them? What does it mean in your context? How much of a degree of freedom do you actually have? Anyone that answered blue want to share anything? Yes, there we have one.

[00:09:53] Audience: Technically the organization I work in has autonomous product teams, but it goes to the degree that we can work autonomously unless there's something that management thinks is more important than what we think is important. We can build a strategy, we can do our own prioritization, and then we propose it to management. But then at some point there might be something new: I don't know, the CEO got some crazy cool idea, or there's something from our parent group that came down that now we have to do. That's the limitation of that. If there's nothing else, it's all fine and we can prioritize it ourselves, but the reality is that most of the time there is of course something else as well. It's this difference: on paper we work in autonomous product teams, but in practice we have autonomy until someone in leadership doesn't like it anymore, or has a different idea of what the strategy is, let's say.

[00:10:53] Mario: Yeah, excellent. I can really relate to exactly what you're saying. But you could say it is the leadership team's and owners' privilege to set the direction of the company. I think this is quite a common situation.

[00:11:09] Empowered product teams: does anyone want to say a little bit about that, and what's the limit of your degree of freedom? What can you do and what can you not do? Anyone? No one. Is anyone working as part of a delivery team or a project team who wants to say a little bit about how they perceive their every day, and how they perceive the work and how it's working? Yes, here in the front.

[00:12:03] Audience: Hi, hello. I've been working in the same company for the last four years. I've been in three different projects, and they are all delivery based. We do have an idea that comes from the CEOs and the business teams, who actually talk to the customers, and they come up with the idea. They have some sort of sketch of what they need, and then we are responsible for actually writing the tasks for that specific delivery. Then we work on a small MVP, we deliver, and then we work on top of that.

[00:12:38] We don't have much autonomy to change the scope of it, but it works in the sense that we have small parts of the delivery that are already idealized by someone else, by someone from above, and then that person will validate as we move along with the deliveries. We end up delivering some sort of MVP that can be used, and then at some point, if the final user is happy, it becomes a bigger project, and then we write bigger tasks on top of that and end up delivering a product at the end. So there is no autonomy about pretty much anything, but the good thing is we deliver a lot of things, and we actually see those things being used in a short period of time, and we actually see value being delivered, which is a good thing. I don't see not having autonomy as a bad thing in that sense.

[00:13:29] Mario: That's good. So what's the size of this organization?

[00:13:33] Audience: It's huge. It's huge, yeah.

[00:13:36] Mario: So you're seeing a lot of value created. There are of course pros and cons with everything here, and I guess that alignment is not the big issue in this setup, because the leadership team deciding what to build has already decided the priorities.

[00:13:52] Audience: Yeah, they actually have a very, very specific idea, and we just work trying to deliver as close as possible to what they are requesting.

[00:14:02] Mario: All right, that was really good, thank you. Anyone else have a comment on this? Awkward silence. All right, yeah, here in the front. Yes, thank you so much.

[00:14:32] Audience: I guess I'm more in the orange part. We are getting some ideas from business or leadership and we try to implement that stuff, but we can also talk with the business side and customers to find out what the requirements are. It would be interesting, because of the way you were describing how you're implementing and delivering the stuff. In my experience, it often happens that we get described what we need to do, and then we try to implement it and get more detail and more requirements, and then we are not actually sure what to do exactly, and then we have to talk with the customers to find out what is really wanted. Because leadership can have some vision, but what the customer really wants, it's really difficult.

[00:15:13] So it would be interesting: does it really happen so often that you get really good requirements, you implement them and the customers are happy? Or are you creating the MVPs and then you iterate a lot and then it works out? That would be interesting for me, because I've got the feeling that this is the reason why things like autonomous and empowered product teams are getting a lot of positive vibes, because of such situations. I don't know. If you want to answer, of course.

[00:15:43] Mario: So basically what you're saying is that you're delivering missions or some initiatives from the management team, but then you have to work with discovery to actually figure out what to build?

[00:15:56] Audience: Yes.

[00:15:58] Audience: In my case, we do work in the beginning with small MVPs, and then the person who came up with the idea, who actually was in contact with the customer, validates that for us. Then we have a demo to the customer, which I do not participate in, but then I get feedback from that, and then we move on with new tasks on top of that MVP, until it's a solid project that the user says, "Okay, that's good for me, I would work with that for the start." And then on top of that we have a new big project that will actually deliver the value for the customer.

Poll: short-term goals versus long-term alignment

[00:16:33] Mario: All right, good, thank you for the contributions. Let's go to the next polling question, see if my clicker is working. Yes, it's working. How do the teams handle short-term goals versus long-term strategic alignment? Do you have a company rhythm with alignment periods in between? Do you have quarterly OKRs, a centralized plan and roadmap, or ad hoc adjustments?

[00:17:09] All right, it's pretty even out here, so that's good to see. Does anyone who answered blue have any comment, who wants to explain how it's working? Any blue people? No.

[00:17:26] Blue, that's the kind of setup we have now in Vipps MobilePay. We have a two-week alignment period where we decide what's going into a six-week focus period. In that two-week alignment period, that's where we align across the different teams and the dependencies, that we are doing the right things according to the company priorities and also the commercial or business unit priorities. And if we need to access shared resources, for example a platform team, that's handled in this two-week alignment period. Then we go into focus, six weeks of focus. We try to not disturb the teams too much and not have any big changes in priorities.

[00:18:04] I was a little bit against that setup when we started it, because it felt a little bit like waterfall, but now I'm a big fan, because it is good to work in a shared company rhythm when you're becoming a bigger company, so you can clear out the priorities across. Anyone else want to share how they're working? About ad hoc adjustments, continuously: did anyone answer that and want to explain how that's working, and if it's working?

[00:18:39] Audience: Hey. We're probably a bit of a mix between green and pink. We have a centralized plan and strategy and theme for the year and for the next few years, but because we're a fairly small team, only about five or so developers, we tend to work project to project. We'll pick the things that we're working on, and as we come towards the end and are about to implement those things, we'll then reassess what the next thing is going to be, obviously still with the central plan in mind. Obviously that works at our scale of team, because we don't have to manage too much of the pipeline. We can be flexible, which is great. But it'd be great to get your opinion on how you can scale that as we start to look at adding additional teams and growing the team, and we need to have that bigger track down the line. How do you make that adjustment? That'd be good to know.

[00:19:30] Mario: Yes, that's the kind of setup we used to have in Vipps in 2019, and it worked pretty well. We had a shared project setup in Jira where all of the bigger initiatives were. But we quickly came into big issues with prioritizing shared resources. For example, we have a payment team, a payment platform, and it was a constant struggle getting priority from the payment team. That's why it made a little bit of sense to have a rhythm, because then at least the payments team can have some quiet and space to work on what's been decided. And when we are in the two-week alignment period, then we can fight and we can discuss and go back and forth and escalate and figure out what's more important.

[00:20:23] Of course it's good to have focus time, but of course in a smaller organization, being set to a rhythm gives you a little bit less agility. So I would say stick with what you have as long as it works, and as long as you can go in the correct direction. It seems like you have a pretty good setup, but maybe when scaling you can consider something else.

[00:20:49] Anyone else want to share anything about how they're working here? Did you have a hand up? Yeah.

[00:21:01] Audience: Hi. We're somewhere between yellow and green, but I had a follow-up question for you on the blue that you're working in, because to me part of it sounds idyllic, and I'm wondering what the cons of that process are. I can definitely feel the cons of being in yellow and green, so I'm just wondering if there are any, or if I should be running back to the company and talking about blue. And also how it works in the two-week alignment period, because two weeks for alignment on one hand sounds very short and also sounds very long. So I'm just wondering what the practicalities of that period are.

Flex and Focus in practice

[00:21:35] Mario: Let's start with some of the disadvantages. For example, the company rhythm, which we call Flex Focus, is really well anchored in product and tech and design, but not necessarily in the rest of the organization. But we need the entire organization to follow that rhythm. For example, when we want to tie in business reviews with the rhythm, we're struggling a little bit with that, because a lot of the time finance and the other departments are a little bit detached. They don't see the point of this. At the same time, we are getting there. Now we are lining up the business reviews with the rhythm. That could be a challenge, but it is getting better.

[00:22:21] And as I said earlier, six weeks and two weeks may not be that agile if you have teams that work on really short cycles, testing out stuff, and they don't really want to plan, they just want to create as much value for the company as possible. So maybe not the most agile setup, but it's a compromise between agility and alignment, I would say.

[00:22:41] The two-week alignment period is a bit chaotic, to be honest. That's the time where the PMs really need to be turned on, and they need to talk to everyone, clarify, escalate and agree on stuff. It's a little bit chaotic, but it works pretty well. We have someone facilitating the Flex period, so we have someone kicking us in the shin, telling us, "Now you have to go ask all the teams what they're doing, write up the high-level stories, have everything ready." And then we're forced into meetings to present it to everyone, so everyone in the organization, or all the product leads, know what the others are doing.

[00:23:26] And they say, "Okay, but I thought you were supposed to help us out on this thing." And then, "No, sorry, we got another priority." Then you can clarify that, because then you can change and do something else when you go into the Focus period. Because maybe you don't get the support from the payments team, so you can delay that task to the next Focus period. So it is working pretty well.

Poll: how important is strategic alignment?

[00:23:52] Yes, okay. I think we're about out of time. Okay, we have 10 more minutes. I think I have a bonus question here as well that I want to do. How important is strategic alignment of product development for your organization? Is it absolutely crucial, without good alignment we build the wrong products? We strive for it but it's not crucial? It's only important for company-wide projects? Or we prefer autonomy over alignment?

[00:24:40] Yeah, so for a lot of people here, alignment seems to be very crucial. We have had a lot of discussions in our company about company alignment, vision, having a company strategy and also product strategy. And it turned out that we have a CEO that likes a very, very, very thin layer of company strategy. He's almost like a no-strategy strategy, which is quite interesting. He wants to keep it open to take opportunities. This is really difficult, especially for the design team. They want to be visionary, they want to see what's happening in the future. But it has some advantages, because that means that you can take initiative on things, and as long as you can prove that it will create value for your company, you can do it. So I think we need to look at what's the advantage of the setup we have, but of course there are some challenges.

[00:25:40] All right, anyone who answered blue want to comment: why is good alignment so crucial? Anyone want to comment on that? No one. No hands. Why is alignment so important? Yes, okay, there you go.

[00:26:08] Audience: I think as companies grow, you have more pillars in your product team. We have maybe 10 different tribes across three different value streams, and we're not quite a big company, but we're also in that transition from a really small company. If you don't have strategic alignment, it's very difficult for the teams to communicate with each other, week to week or sprint to sprint, what work they're doing. That strategic alignment makes sure that we're all rowing in the same direction.

[00:26:45] Mario: So how do you do that in your organization?

[00:26:49] Audience: We have a strategy, and I think the product team inputs into that maybe not as much as they would like. Things go up, and then the strategy comes back down to us. And we have quarterly roadmapping sessions. Each team takes ideas from different parts of the business, each product team, that is, each cross-functional tribe, and those ideas are lined up against the overarching strategy. And we, I guess, bet on which things we think are going to bring us the most value and align to the strategy, and that's how the decisions get made.

[00:27:37] Mario: Good, excellent. So how is the strategy formalized? Is it a set of missions, or a set of positions?

[00:27:47] Audience: It's again a kind of cascade. We have a customer-facing statement, and that's "time for business", and then it flows down into a more detailed description, mission, values. That's it.

[00:28:03] Mario: Yes, but it's pretty thin, so there's really a high degree of interpretation within that space, I would assume?

[00:28:10] Audience: Yeah. We went through a phase of having an evolution of that strategy, and maybe 18 months ago that was redeveloped so that the strategy should stay the same. Maybe every two, three, five years it would change, but it's something that's broad enough that it can stay the same, but maybe specific enough that it directs us to be driving value for customers continuously.

[00:28:44] Mario: Excellent, thank you so much. Any other comments? I think we are approaching the end here. Yes, thank you so much.

[00:28:51] Audience: Hi. Our company is somewhere between blue and yellow, and why it's quite crucial is: I joined the company when it was three years old, and the strategy was really decided on the fly. Everybody just rode in, and we had a very clear company vision, so everybody just really worked autonomously towards that vision. But the company's now 11, I'm there seven years, and as my team grows I just get so many questions about the strategy and the direction. We use a balanced scorecard framework. Without that it would be very difficult to communicate with everybody the direction that we're going. That's why it's so crucial.

[00:29:46] Mario: So why is it so important to be able to communicate that?

[00:29:51] Audience: Just because, when there's ambiguity or a lack of knowledge about the direction, people are a little bit like headless chickens. They're not really sure where we're going, they're not really sure what to do, they don't even know how to prioritize and focus their time. You want them to be able to work autonomously, and they just can't if they don't have that direction.

Wrap-up

[00:30:13] Mario: Yeah, I think that's an excellent remark. All right, I think we're about out of time. Four more minutes, we have time for one more remark if anyone wants to share anything. If not, I can try to wrap up a little bit. It was really good to see all the different setups that people have here. We had a good spread of different organizational setups: centralized with a CPO or head of product, and we also had some examples of product organizations reporting into business units. And also a good spread on autonomous, empowered and project teams, so that's also good to see.

[00:30:57] As we've come to learn today, everything has a pro and a con. Even though you may not be organized according to the product literature or whatever, there are of course a lot of advantages to be found in that. I think I will just end there, and thank you, everyone, for listening.