Ben Williams: commitment

Transcript context

…Broadly, how do you structure it? Just like how many teams do you have? Do you align it across by outcome or is it by surface area of a product? And then is the growth team like adjacent to this product org? Is it like a unit within the product org or is it integrated? But I don't think it is. So what does that look like org chart wise? I think we've got a fairly common pattern for how we structure our product and wider R&D org. So most of the org functional ownership-based, there are a lot of really complex domains in the core product. So having that localized knowledge is important to be able to own and run the code that teams ship. The growth teams, on the other hand, are structured by outcomes. We talked about that already. Owning areas like acquisition, activation, engagement, monetization. These outcomes and team remits change over time as we talked about. But the teams here are often working on areas of the product where they don't own the code, which I think is the key difference between how we structure our growth teams and product teams with some exceptions. One of the growth teams actually own the onboarding flows and so on. So that does require a lot of trust. It requires very transparent communication mechanisms built into how we work. One of the meetings that we have regularly is experiment plan reviews. They're ad hoc meetings. They're led by the experiment lead, could be the PM, could be anyone else in the team. But the important thing is a bunch of people will be invited there, especially stakeholders from other teams where we might be experimenting on their surfaces and that won't be the first time they've learned about this. We'd like to try and actually include them in co-designing the experiment plan so they're fully on board with it. But absolutely kind of inviting them into those experiment and views really key. If we're going to run an experiment on that surface, we need to make sure that everything in that experiment plan is watertight, especially from a scheduling perspective because the last thing we want is a week and a half into an experiment for some change to happen within that surface from the product team unaware that an experiment's happening and completely invalidate the experiment. Cool. And then in terms of just org wise, do you have a lieutenant that is responsible for just say the product team and then someone responsible for the growth team or the directors report up to you and you have a bunch of reports? How's that structure?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.