Staying Agile While Scaling The Team

Benoit Terpereau at UXDX Community: France. Video: https://youtu.be/LuNs17mibJQ

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.

Introduction and Deezer

[00:00:03] Benoit: Thank you very much for inviting me. I'm thrilled to be here, in these weird conditions, but it's still really important for me to share with the community, even though this situation is not easy for everyone. I hope you're all okay and safe. If you have any questions during the presentation, don't hesitate to contact me on social media, like Twitter or LinkedIn; you have my links. I designed this presentation because a lot of people asked me: I know how to do project management, but what is at stake when you start to go from one team to two teams, three teams, ten teams, sometimes more, and how should we organize? So I put all my ideas together, drawing on several experiences that I've had in the past, mainly through Deezer.

[00:01:01] First, a quick intro. I'm Benoit, and my post is VP Product at Deezer. I'm running the entire product team, and I've been working at Deezer for two years now. Before that I was at an awesome company called Enable [?], a software company that provides software for big companies. A few words about Deezer, for those who don't know it. It's a worldwide music streaming service that provides music to more than 14 million monthly active users. We have more than 50 million tracks, so it's a huge catalog, and we are open in 180 countries. It's a vast and big product to run, I have to say.

From startup to scale-up

[00:01:55] Let's back up a bit and imagine that we are a small startup. At the beginning it was simple, right? You have, I don't know, probably one or two developers, you are open in one country, and you have one app. It's pretty simple. You have a simple method and you iterate. No issue here. But further down the road you start to be a bit bigger. You start to have two teams, and you open more countries, so you have to manage things like languages. You start to want to be not only on, for example, Android, so you start to be on iOS, and then you need to build a web version. That's a lot of challenges that you face already.

[00:02:44] Then you enter a situation where you're a scale-up, something a bit like Deezer, with something like 180 countries, as I said before. You have more than 100 products. At Deezer we are obviously on iOS and Android, but also on various desktops. We are on smartwatches and smart TVs. We are connected with various carriers around the globe, on smart speakers, on headsets, in cars, and we have a bunch of B2B partner deals. Again, it's a huge product to run, and we have a lot of issues along the road to manage all those people and countries and products.

[00:03:28] And it's not easy when you're a product manager, because you also have to manage things that stand in front of your agility and velocity. You have to manage various languages, as I said, and some cultural gaps. For example, for music, you don't use a music streaming service the same way when you're in Paris, in Rio or in Lebanon. It's not the same, so you have to manage that along the road. When you're a company like Deezer, you have some technical debt that you have to manage. You have requests from support. You have requests from your salespeople, especially if you work in a B2B activity, which is the case for Deezer.

[00:04:10] You always have some communities online, on Twitter, Facebook, Reddit; we also have our own communities, with a lot of requests. You lose some knowledge along the road, because some people quit. You also suffer a lot of the time from a lack of documentation; maybe you are lucky, but in a large company nowadays it's one of our pain points. You can face some management pressure from people who want to achieve something. And especially in my industry, you have some competitive pressure, so you need to deliver to keep up with the competition.

[00:04:47] So you end up basically like this guy. For me, let me say that product is probably one of the most overwhelming jobs in tech, because you have to manage so many things, and you are in the middle of the company, especially if you're running a digital product. It's easy to be overwhelmed. So let's try to see if we can find some solutions and better organize ourselves to reduce this pressure and this overwhelm.

[00:05:13] To me there are four keywords. They seem obvious, but in some cases they're not, if you want to run a successful product at scale. The first one is organization. The second one is collaboration. The third one is prioritization. And the last one is communication. Let's deep dive in and see what we have in mind for those keywords.

Organization: mission-driven teams

[00:05:40] The first one is organization. Again, it sounds so obvious, but you need to change your organization, treat your organization like a product: test things until you find something that works for your company. One part of the organization is what we call the tribe product organization. Basically, it's the organization that was explained by one company that also does music streaming, based out of Sweden, with a green logo. I won't go into it in too much detail, because first of all it's really well explained and I don't have any added value on it. Go on Google and you will find some great documentation and feedback about it.

[00:06:27] What I'm really interested in is more how you set up your teams. One thing that also seems obvious, but is not that obvious in some companies, is that from my perspective you need to organize your teams to give each one a clear mission and clear objectives. You will see a lot of debate in the product and tech world about whether you should have component teams or feature teams. I have to say that my preferred choice is what I call feature teams, objective teams, sorry: teams that are really focused on one objective.

[00:07:03] Let's go see one example, a simple example of a B2C product. These four teams each have a clear mission. The first one is about growth: they need to acquire and convert new users. The second one is about engagement: it's about driving stickiness and avoiding churn. The third one is platform: to give the right infrastructure and the right tools. And the last one is content: getting good content into your product. For us, the content is music, but for a B2B product you also have some content, if you are running software, for example.

[00:07:39] Those teams are not about "I'm building an iOS app" or "I'm building this feature." It's really about having a goal and making sure that everyone understands which goals they can contribute to. This is key, I think, so you can really engage all teams across success and performance.

Organization: aligning with OKRs

[00:08:02] The first thing is about the mission. The second thing is about setting objectives. Why? You will still face issues along the way. You can have two teams with clear objectives, but if you don't set up common goals, they will probably fight against each other. Let me give you one simple example. You tell the growth team that they need to increase the number of people who sign up within the product; you need new people who will register. If they do it the simple way, they will say, okay, I will reduce my acquisition funnel, my sign-up process.

[00:08:36] But maybe the engagement team needs some part of this acquisition process to create some engagement and drive stickiness, because the early days of a user are really important. You need to capture the maximum signal when you welcome people into your service. So the growth team may hurt some engagement KPIs, which is bad for you, because you don't care that much about one single KPI. You want your product to perform in all verticals.

[00:09:07] So my advice, again, is to use OKRs to align teams around clear and engaging objectives. OKRs are the objectives framework from Google; it's also well documented on the web, so you can go there. But basically, if we go back to our example, what does it mean? For example, we set up for both teams an objective like: you need to boost user acquisition, with whatever tactics you can use, okay, but you still need to keep stickiness above 60%. If you do that, and if it's fair for both teams, the growth team will have to watch stickiness and make sure that what they do doesn't destroy it. If you are running A/B tests or things like that, you will have to figure this out, and reveal if they do something that will hurt the engagement KPI. So OKRs are a really great tool to engage everyone.

New roles: product strategy and product ops

[00:10:04] I also want to mention that some new jobs are rising in the product area nowadays, and they can help you boost collaboration in this matrix environment where we have squads and tribes and things like that. The first is a job we have at Deezer that I really love: product strategy. The role of a product strategist is basically to look at the future. Right now they are working on 2021, not 2020. The reason they are doing that is that if you want to be aligned with your team, you need a clear vision of what the future has to offer. And in a really competitive market you need to be prepared, and you need to watch and be ready for the future. It's really good for that, because when you start the year, you have everything ready for the teams to pick up, with a clear product strategy for the year.

[00:10:57] The second job is product ops. Think of product ops as the COO of the product group. If you have issues across your teams, product ops will tackle it. If you have a transversal product, product ops will tackle it. It's really convenient, because again, in this modern agile world where you have your teams, remember this growth, engagement, platform and content team setup. If you say, okay, I have this really important feature, it's across all teams and we need to do it, everyone will agree in principle. But when they do their own prioritization, it will be difficult for them to prioritize the thing that is cross-team, because they think their own roadmap is more important for their own objective. So product ops can handle those transversal tasks, and more and more companies are trying to hire this profile. I think it's really interesting.

Collaboration within the product group

[00:12:00] Number two, collaboration. Again, it seems obvious: we need to collaborate with each other. But in a lot of cases it's not that obvious and not easy. Remember all those things that I mentioned before. You can have the perfect organization, perfect missions for all the teams, perfect OKRs and stuff like that, but those issues won't disappear. They won't go away. It will still be something complex for you to manage.

[00:12:28] The first advice, before you collaborate with others, which is really important: when you are a product group, you need to collaborate among yourselves, within your group, and especially product and tech. For example, at Deezer we did several things. The first thing is what we call the weekly kickoff. Every week starts with a 30-minute catch-up with all the leaders, so we can align ourselves and communicate about progress and issues, and everything that comes along the road is solved there or just after. It really enables us to communicate and synchronize.

[00:13:10] We also do what we call product meetups. These are internal meetups that we launched, where product, tech, QA, data and user research are invited. We share our roadmap, we share pains, we share best practices, we share some data insights, some user research insights, some design insights. It helps to have a better group, better communication, better alignment, and it's always good to be all together.

Collecting feedback in a consistent way

[00:13:40] Then, from my perspective, you really need to create multiple channels to collect all the feedback that you have around you, in a single and consistent way. What do I mean by that? At Deezer, remember, we are open in 180 countries. I think we have something like seven offices around the world. We have 14 million monthly active users. We have a bunch of people around the globe talking about Deezer, and we need to collect all this and make sense of it, and it's not all in the same format.

[00:14:17] So what do we do? First of all, we created something called RAP, the Region Ambassador Program. Some product managers and myself talk on a regular basis to our local teams to collect what we call market feedback. It's really important, especially when you are based out of Paris and you operate in countries like Brazil or the Middle East. It's not the same usage of your product, so you need to be aware of what's going on. Sometimes the network is not the same, the phones are not the same, so you need to understand what's going on in those markets.

[00:14:55] So we connect with markets, and we also connect with users via support. This is something that is really important for me. We send every product manager at Deezer to spend two days per year doing support within the support team. Product managers go into the support building and they do support ticketing for two days. We're doing that because as product managers we need empathy with our users, so we need to be closer to the pain they have. If you create virtual interfaces between people, like: I'm a customer, I'm on Deezer, I send a ticket to support, support sends a ticket in Jira to the product manager, that's too many interfaces. Sometimes you need human connection. When you are doing support you have this human connection, which lets you feel the pain. And if you feel the pain, you can be a better product manager and understand that when you deliver something, you need to deliver something clean that tackles a customer pain.

[00:16:03] We also do UX sessions with design friends and UX friends. A lot of the time we invite people to discover new features or discuss new ideas, and we welcome them. We have some planned user sessions on a regular basis to do that. And obviously we have data insights coming from our great data team, which flag issues of bad performance or good performance, and we take that into account.

Product initiatives

[00:16:33] All those kinds of information, or weak signals, that we have around, we put into what we call a product initiative. What is a product initiative? A product initiative is first a problem statement: our users have a problem with this feature, it's not efficient enough; or they have trouble subscribing in this country; or this or that. It's really a problem statement. It's not really interesting to put a solution here. It's really about the problem that our users are encountering.

[00:17:05] It will evolve in three phases. First, of course, the most important, where PMs are the most involved: the problem. The product people work with user research, with product, and mostly with design to find the best solution to the problem. Then they work with more tech people to develop, and then they do this cycle again.

[00:17:29] If you want to start and imagine what a product initiative is, I really advise that you start by looking at what Intercom is doing. The simplest template that you can find around is called the Intercom Intermission, and I really love this template because it makes things simple. It's a one-pager where you put mostly the problem, and then you have job stories and how you measure success. You can look in the notes below. But basically, if you cannot have your problem well stated in one page, it means that your problem is too big and you won't be able to find an easy solution. At the end of the day, the smaller you can state your problem, the more straightforward the solution will be, and the easier to implement. By the way, I will put the link on one slide at the end of the presentation so you will be able to copy it, or I will send a link on my Twitter and LinkedIn accounts just after the presentation.

Prioritization matrix

[00:18:29] Number three, prioritization. It's also really important, and it's probably one of the biggest pains that we have when we are running a big product organization: what should we do, and what are our priorities? I do suggest that you try what I call a prioritization matrix. There are several prioritization methodologies around. The one that I think is the most well known in product is RICE. I don't use RICE; I know it, but it's a bit fuzzy for me. I use things that are more straightforward, or that I've seen working, so I'm comfortable with them. This is one priority matrix that I encourage you to use, and I will also share the link to this matrix so you can play with it on Airtable.

[00:19:14] It's pretty easy. You put all your product initiatives, remember, all your problem statements, in there in order, and then you rank them according to criteria that you decide. For example: can we be seen as an innovative company? Should we provide customer value or business value? Should it be brand awareness? Or should we be more efficient? Basically you create your columns, and then you rank the initiatives against those columns.

[00:19:47] Then you work with tech to do some technical assessment. For that, don't do something complicated, because at the end of the day, from my perspective, technical assessments are almost always wrong. So let's spend five minutes, do a quick technical assessment, and then it will create a priority score. Obviously the priority score will help you to prioritize. In this example, the highest score is the most important.

[00:20:17] But the magic of this matrix is not there. The magic is in the weighting. I created two matrices here with two different weightings. The good thing with the priority score is you put some weight on every column. For example, your CEO tells you: I want this quarter, or this year, to be mostly about innovation. I want to be seen as an innovative company. So you really put the focus on innovation. If you do that, and you put 50% on innovation, 10% on customer value and so on, you will have a score with the problems that are the most innovative first. If your CEO is telling you now it's time for efficiency, you do the opposite and put 50% on efficiency, and it will reverse the order.

[00:21:05] It's really good, because to me it gives the final cut to the CEO, but more importantly it gives back to you the ownership of putting forward the right problems, evaluating the right problems and putting them in front of your CEO. I do think it's a good exercise. At the end of the day it's just a tool; it's not rocket science. You can use it, you can put priority 1 and then 3 and get rid of the 2, because in the end it's more complicated than you expect at the beginning. Again, I will share the link. Please use it; it's on Airtable, it's open. And please give me your feedback, and you can also help me build a better one.

Communication

[00:21:50] Number four, communication. Again, it seems pretty obvious, but it's not in most companies. You need to communicate, communicate and communicate again. You need to over-communicate your roadmap and updates to your team and your stakeholders. How do we do that at Deezer?

[00:22:08] First of all, I like to use a good communication tool. A lot of the time we use roadmaps in product and tech. I don't like roadmaps where you put timing so much, because, again, since costings are always wrong, roadmaps are most of the time wrong. I much prefer what I call a two-pointer roadmap. I give one example from white Shearer [?] from Front, and by the way you can go see this talk, it's really awesome; I will put the link at the end of the presentation. Basically, it's always about your vision, your strategy and your objectives.

[00:22:45] Coming back to the previous teams, your objective is to welcome new members. You put this objective, and then you put some projects: improve your registration funnel, or change your UI, or change the messaging of the first days. This is the kind of thing that you can put. It's much more objective-oriented than just time-oriented, which is, by the way, what you expect. You expect results, and not so much respect of timing, from my perspective. I mean, sometimes you have hard deadlines, so maybe for hard deadlines you manage it in a different way. But for objectives, this is what you need to do.

[00:23:21] Then you also need to share updates with your stakeholders a lot of the time. At Deezer we are really lucky, because we work with product marketing managers, a great team, and they help us transform our features into stories. A lot of product managers are asked for a story to tell when they implement a feature, and they want to talk about it, but it's not because you have a story to tell that you know how to tell a story. Product marketing managers help us to be closer to people, so they understand what we do, and closer to marketing, so marketing can talk about our features.

[00:23:59] We also do weekly breakfasts at Deezer, which are forums where we can go and talk about our evolution. We also do product roadmap events, our roadshow. Every time we change our roadmap, we do an event, now online, which works the same, to explain progress and what we delivered. We also have two big rituals at Deezer. They're called the cameras [?] and the quarterly plannings. This is where all the teams meet together to exchange about their objectives for next quarter and also what they will deliver, so their quarterly roadmap.

[00:24:34] And I strongly encourage you to do a product newsletter to your whole company, especially if you are running a digital product, to explain what was delivered, when and on what platform. We all know, if you work on several platforms, that you will never be able to release something at the same time on Android, on iOS, on web and on other platforms. So you need to inform people so they understand, because at the end of the day it's complicated and it's tricky.

Takeaways

[00:24:59] I imagine you're just behind your screen and you look like that. I'm sorry, I had to cover lots of topics in 25 minutes, and we are almost there, so I had to speed up. But in a nutshell, what I want you to take away: set up missions and objectives for your teams. It's really important and it drives performance. Use OKRs to align them and break silos. Once you have your teams, you should organize collaboration within your teams, with events, with various people like product ops.

[00:25:34] You need to set up your feedback channels and have a consistent way to welcome feedback. You need to use a prioritization matrix to start to prioritize things, one that is common for everyone and that you can share with the whole company. I forgot to mention that, but if your prioritization matrix is open, you can share it with the company and explain why something won't be delivered, or why something will be delivered. And communicate your results. It's really important. People need to understand, and if something is obvious for your product team, it's probably not for stakeholders like sales, for example, who are really important for product.

[00:26:15] Here are the links: the Intercom Intermission, the prioritization matrix that you can try, and the talk about the roadmap from Front. If you have any questions, please feel free to ask them now, or connect with me on social networks.

Q&A

[00:26:31] Host: Great, excellent. Well, thank you very much for that. I think your slides were visually very nice to look at as well as very informative, so I hope everyone else agrees. We will quickly jump to one question, but if people do have any others, please send them in and we can address them later on in the breakout rooms. One question that came in was: how do you marry the prioritization matrix with planning the direction for the product? For example, avoiding incrementalism and making sure the product is moving in the right direction.

[00:27:08] Benoit: It's a good question. First of all, from my perspective, a product initiative in this matrix should not be done until you are satisfied with the result. One thing that you should avoid, and it's the number one trap that we all fall into, is: we want to ship new features. We think that new features will serve us and solve our issues with the product and make us win, but sometimes they don't. I would suggest that until a product initiative is resolved, if you have one issue, and if you have one conversion metric that's not good, you keep it there, so it will remain something important, unless your CEO or yourself change the priorities of the company. And sometimes the priorities change, and it's not about acquisition anymore but about retention. At some point you should be able to change your priorities, because this is also what agility is.