Lessons From Building a 70 Person Growth Team — Jason van der Merwe, Strava

David Barnard (00:01.118)
Welcome to the SubClub Podcast, a show dedicated to the best practices for building and growing app businesses. We sit down with the entrepreneurs, investors, and builders behind the most successful apps in the world to learn from their successes and failures. SubClub is brought to you by Revenue Cat. Thousands of the world's best apps trust Revenue Cat to power in-app purchases, manage customers,

and grow revenue across iOS, Android, and the web. You can learn more at revenuecat.com. Let's get into the show.

Hello, I'm your host, David Barnard, and with me today, Revenue Cat CEO, Jacob Eiding. Our guest today is Jason Vandemerwe, Director of Growth Engineering at Strava. Jason helped found the growth team and has been integral in evolving it to where it is today, with five cross-functional teams totaling over 70 people. On the podcast, we talk with Jason about some of Strava's big growth wins, the importance of feature education,

and whether or not all product teams should actually be growth teams. Hey Jason, thanks so much for joining us today on the podcast. It's great to be here. Thanks for inviting me. And Jacob, always nice to chat with you. Let's talk about apps. I'm here to talk about apps. I'm here to talk about crushing KOMs as it is for the Strava heads out there. All right. So Jason, I wanted to ask you about your role as a growth engineer.

You know, I think a lot of people who don't work at bigger companies probably don't really fully understand what a role like that looks like, especially at an app company. Cause you know, how many app companies are there now with growth engineers and growth engineering teams? So tell me a little bit about your role as a growth engineer. I think a lot of it comes down to the goal and the mindset of the work you're doing. I always say growth teams, their goal is to connect users with the value of your product.

David Barnard (02:09.054)
and to continue to expand that value. And so that requires an orientation on user and business impact at the end of the day versus perhaps just delivering something you were told to deliver. And I think that orientation is really important because in order to understand and get to that impact, you have to do a lot of learning. And that learning comes in all different shapes and sizes, right? There's like the small optimization, like how can we improve this flow or reduce friction to this flow or...

How do we build something massive to really change the game for our business? But you're building something massive, not because you want to build something for the sake of it, but because there's a goal in mind, kind of a business and user outcome in mind. And so it's really, it's a little bit of a mindset shift and a willingness to sometimes go faster than is comfortable within engineering. Sometimes you do things that are super hacky in the short term so that you get that learning to determine if you do the bigger investment.

and a willingness to kind of almost break the rules at times. You know, growth engineers are not the best engineers to run your infrastructure teams. So it's a little bit different. And I think engineers who are very user-focused are great growth engineers. Engineers who think of themselves as, maybe I want to be a product manager someday is really great. So I often say, I want our engineers to think like product managers, thinking about that user problem they're trying to solve.

Yeah, that's fantastic. So you've been at Strava for almost eight years and Strava is almost 16 years old. So you've been there almost half the life of the company, which is really cool. Cause there's a lot of kind of water under the bridge before you joined, but then you've had a lot of impact and seen a lot of change as, as the app has grown and the company has grown over the years. So I'm curious what marketing was like before and growth was like at Strava.

as you joined and then, you know, I know you were kind of foundational in forming the growth team. So I'll want to talk a little bit more about that as well. Yeah, it's a great question. I mean, Jacob, you kind of alluded to this at the beginning when you talked about KOMs and you referenced our brand. And I think that's one of the coolest parts about Strava is we've had we've become part of the zeitgeist for first cyclists and then runners. And now we're trying to broadcast, you know, brought into

David Barnard (04:30.626)
to the whole zeitgeist of everyone who's trying to be active, um, regardless of your sport. And so when we got to Strava, really, you know, we were really big in the cycling community and then the running piece we were picking up a lot of steam on. And so then, and even now, majority of Strava's growth is word of mouth. People love Strava. There's a phrase that the community uses that if it's not on Strava, it didn't happen. And that's not something we came, like they came up with that and they use that. And so

That's amazing, right? That's an amazing position to be in where your growth is word of mouth and organic and you're not having to depend on paid dollars for growth. Obviously we do those aspects, but the organic piece is huge. So then you're thinking, okay, what's the point of a growth team? A lot of it is looking at our experiences, looking at our funnels and reducing friction and finding new novel ways to funnel more growth. You know, when we started, I joined Strava and two weeks later they were like, hey, we're gonna make a growth team.

We have no idea what this means. Oh, wow. So eight years ago, let me do the math. That's like, what? What are we? Twenty two, 2015, some 2015. Yeah. Around there. Yeah. So early. Just to center me like when were you guys on the app store? Because 16 years ago predates the app store. And then what was the product before the app store? There was a before the app store. There was a web app. Yeah. So web app. Interesting. The product started with kind of this insight from some of our founders of. So our two main co-founders, Mark and Michael.

were Harvard Rovers together, they run a business together, and they wanted to recreate the locker room camaraderie digitally. So they had this idea, and then they met this guy named Davey, who was starting to buy the Garmin devices and recording GPS. And he was trying all these crazy things with this Garmin device. And he was like, all right, what do we do with this data? This data is so cool. And then there was a web app. And so the way they started was they would take a van and they'd go to local cycling races. And then they would...

get all the cyclists to come over and upload, literally plug in their Garmin devices and they would upload to Strava for them. Oh, I guess that was, yeah, because that was right when bike computers were becoming like an accessible thing. That was probably the only real personal GPS device that was mass market at that point. Exactly. Because the phones didn't have it yet, right? No, and so our apps started in 2011. So a little bit after, you know, the rise of the iPhone and the App Store. Well, but the iPhone didn't have great.

David Barnard (06:54.198)
like location ability before that it was all skyhook and like sub GPS until maybe 2010 2011 so that makes sense. Right and it wasn't a great experience anyway but it was and there's also the cultural piece of don't want to carry a phone when I'm running. Nowadays we don't people for the most part don't seem to care but there was kind of this interesting I'm not going to carry my phone with me when I run. So 2011 in the App Store so yeah we were in the App Store for a few years when I joined and when I joined actually we had.

we had just combined our run app and our ride app. So when we expanded into running, we have made a Strava run app. The day there was Nike, we had the Stone Nike run, but there was Nike Run, there was Runtastic, Runkeeper. So we made the run app. I think that helped a lot with the communication to runners and the broadening to runners. So again, back to the question though, was there a marketing team? And is there still kind of a separate marketing team that's completely separate from the growth team?

Yeah, great question. So back then there was, um, there was a marketing team that was kind of, you know, all kinds of marketing, but kind of your classic grow local communities, um, go to events, develop, uh, relationships with professionals. I think that's one of the things that makes Strava so unique is, you know, every, you know, the major running and cycling professionals like Chris Froome or Molly Seydal are on Strava. You can go, you can go compare your wattage to theirs. It's pretty amazing. See they're just, you know, obviously we're not like them. Um,

But it's really inspiring to see the reminder. Right. And it's great way for them to connect on a very organic way with their fans. Right. Um, and so our marketing org has done a lot of, of that and, and just generally, um, supporting, supporting the, the world of sport and helping people become more active when we started the growth team, it was very cross-functional and it's always been cross-functional. So when we say we're a product team, we're the most.

raw definition of that possible. Like we have growth marketing functions where those, you know, ladder up to from a reporting perspective is kind of irrelevant. Our teams have always had growth marketers on the team, product marketers on the team. We've always seen ourselves as very horizontal versus vertical of a model. So it's, it's interesting that I guess, and you see this a lot with apps that break out like Strava that

David Barnard (09:19.326)
It doesn't necessarily follow the pattern we hear a lot in apps where it's like, you know, get a decent LTV, CAC and try to scale that way. You have some for you. It's organic. And because you have organic things like, you know, taking a van and going to a race kind of scale because you get five people on board, that's going to turn into potentially, you know, five more, et cetera, et cetera. And that's a really good place to start. And that's always just downstream of having a good product. And so I'm curious, like.

how much of the growth teams work. Because I imagine as a growth team, you're touching top to bottom sort of everything. How does that influence in the roadmap from when you started to, because obviously there's product folks who wanna build, oh, we're talking to customers and they want X, and then there's growth, which is, yeah, the customer is important. Obviously if you're not building stuff they want, but then there's also this goal of

you know, increasing adoption and things like this. So how do you guys work that tension? And was there resistance when you came in to be like, oh, we're gonna be a team that's focused on numbers, you know? Yeah, it was definitely hard at the beginning. I mean, we kind of started this team, and to be fair, we didn't know what we were doing. We were told, I think we were told kind of by the board, like, hey, you know, talk companies have growth teams, go figure this thing out, right? I read this in the Inflite magazine. You guys need a growth team. Okay, cool.

So the first, the first experiment he ever ran was adding the ability to add your profile photo to the onboarding flow. Um, I remember that, um, classic classic, you know, and then of course later on removed it because we realized like it asks too much friction, right? But we know we read and I think a lot of, for people out there, like when you're starting growth teams, don't over index on the impact slash importance of specific tests, like there are times in the growth journey where we have.

new people join or a new team join where the first few months I'm like, just run AB tests. Figure out as a team how to go from idea hypothesis, running the test evaluation, determining. It's okay if you didn't knock the ball out of the park or the metric you were pushing for wasn't that important. What matters more is you have a metric you're going for, you're thinking about it, you're brainstorming, that piece. So at the beginning, we were definitely like, what do we do? But one of the great pieces...

David Barnard (11:43.71)
I think that the beginning was the inclusion of user research on our team. And we would run, we didn't have a big team, so we would run tests using usertesting.com and we watched them as a team, small team. And one of the things we had looked at, our product analyst had found this insight of, you know, the most important thing for a new user is to upload. Yet, we see a big drop off. We did a funnel analysis, big drop off. So we did a bunch of, you know, user testing to say, you know, give a bunch of people.

ability to go through the onboarding flow. And we watched it as a team. Very important to do that. Everyone should be watching user interviews. And we saw people would get to the record screen and say, what is this? What am I supposed to tap? And the problem there was skeuromorphism was really big. And so all the buttons on our record screen, like where you record your bike or run, had taken homage from an actual remote from a TV. So it had...

The record button was round with a little red button in it. Right? And the stop button was literally like a square, right? Things that you would find on your DVD remote, but users didn't know what to do with that. So we were like, what are we going to do? We're going to put text on every button. We're going to make it so obvious how to use this. Oh, okay. Yeah, yeah, yeah. That's the thing. I was like, well, I think round is still pretty useful, but if you don't have labels, I fought .. You know my designers I've fought with over the years because it's like, it's not going to hurt. I know it makes your design look bad, but...

It's necessary. Right. So funny. And you know, we went back and forth on like, where do we, where do we put the text on the label buttons and how do you localize copy to go into a small button? Turns out you can say go, you know, geo in many languages that are in English and they still, you know, that works pretty well. So we did that and that was one of the biggest wins we've ever had in reducing the friction to upload, increasing upload rate for new users. And that results in a huge increase in retention for new users. And so since then we've kind of.

So a lot of our work has been kind of reducing friction to that first kind of upload moment. Yeah. Cause then after you've recorded your first thing, you've got data in Strava now and you're starting it's building value as a repository. And I mean, I think that's a one of the, again, those things that create, take a, take an app and make it something that becomes sticky forever. It's building lock in through data and Strava does this so well, right? You build history, you have all this, you're not, not only like you have the data points of each.

David Barnard (14:09.458)
ride but within the rides you have like all kinds of depending on what kind of sensors you're running. But even now with just the phone you get a lot right just from the GPS and maybe like a watch or something like this. And so I can see why I it's interesting that you found that the bottleneck was the user interface and not just the friction of I download the app. Am I like ready to go for a run right now or a ride which I'm sure has its own challenges.

Yeah, I mean, that's one of like our activation metric is getting you to upload once and follow one person in your first seven days. And it's a tough activation metric because we need you to go outside. Yeah. And our metric actually, nobody wants to do that. Right. And we actually have a minimum distance of an activity that we also look at because we want to make sure that you were just hit it right. And then we asked it. Okay. And it's a bit challenging because

you know, when you compare it to like other companies activation metrics, they're like, well, you can, you know, you can set your profile up in bed. You're lying there using the app for the first time. Three videos, add a friend, you know, all the things you can do from your, from your seat. But for us, it's amazing. Like our users download the product, about half of them are ready to go right now and go outside. It's like a, it's like an impulse thing or like, Oh, I need, I'm going to do running, I need an app. Exactly.

And that kind of makes sense. Shout out to the app store for making that even a possibility. Right? The fact that you can be like just in time need for software and then you can find it. That's pretty cool. But that's crazy. It's half. But that's good. That's great for you, right? You have a user who's completely primed to buy when they open the app for the first time. That's great. So Jason, stepping back to the growth team.

I did still want to understand how you went from, Hey, we should probably have a growth team to now five separate multidisciplinary teams with over 70 people. Like that's, that's pretty incredible. And I would have just never, you know, guess that. So I'd love to hear a little bit about that kind of evolution and then what those, those teams and functions look like today at Strava. Yeah. So the first team for a while, we were just called

David Barnard (16:29.666)
growth team, right? But if you looked at the work we were doing, you would classify it as an activation team. So new user activation. And I think for the majority of other companies and organizations that I talked to, that new user kind of optimization tends to be the place where you can get the most wins from early and like a very important place. And it's connecting your people that have shown intent to come to your product with the value of your product. If you don't have that, then you're in trouble. From there, we kind of expanded to

new user acquisition. And so we would like support paid, we would also do kind of referral loops through activity sharing mainly, but basically UGC sharing. And so we kind of expanded saying, okay, we want to, we had this insight of, we have the ability to share a link from activities that generates several hundred thousand shares a month. Let's try bump that number up and then convert on the other side. And so I think early on we were, because we didn't have a strict

definition of what the team we could bounce around from different areas. And our, um, our head of growth, it was actually the CTO founder of Strava. He decided to one day he just came and sat next to me. He's like, I am now the head of growth. And he, he really created the ability for us to try, try things out in different areas. And so we're like, okay, social sharing, let's try this out. Oh, it's driving new reg. Um, let's work on this. Um, and so we kind of expand it to like activation and acquisition. And then while the whole, that was happening, we had.

Our business model was subscriptions mainly. We mainly make our money through a subscription model. That was considered separate to growth, but really for a long time, it wasn't growth-focused. It was more built features for subscription. Then eventually, that became a little bit more growth-focused on like, okay, let's increase the value of our conversion over upsells.

like a friction and they kind of started to do growth works over time that kind of shifted into the growth org and became a classic kind of growth monetization team growth subscriptions team through kind of like because of the success we had in the other areas of the business with the growth team of reducing friction increasing conversion expanding value and so those are kind of like the three main areas the two other areas in growth were comms like we call the communications and personalization team and that was

David Barnard (18:51.93)
Again, a way to invest in the notification, email, and in-app messaging lifecycle, knowing that was an important area that we could improve on. A lot of the inspiration here came from Pinterest and their Growth Comms team. Again, a lot of the times these areas start off as one person trying a bunch of experiments in an area and us being like, well, that's working. Let's invest more in here. Then also, while we're doing all the Strava, still having crazy success and growing.

And, you know, reaching more and more and more users. And so naturally the teams slightly start to get slightly bigger as you need to build the growth tooling infrastructure to be able to do it. And so it's not as like, I kind of tell people who join now, like back in the day, I was an iOS engineer, I could just basically write a whole bunch of tests without really wondering about the scale of it. And now we have to think about, Oh, is this test I'm going to do? It's going to scale, do I need tooling?

You know, what's going to happen when we launch this, like those kind of things necessitate growth tools. I mean, part of the, you know, the cell of, you know, you were describing a, what a good growth engineer looks like. And somebody kind of who could be a PM is like very fast. So it sounds very, to me, like very early startup person, right? Like somebody who's like rapidly iterating to find products as a good engineer to hire in your first like five or 10, right? Somebody who's, who's can, can move independently and very quickly. Yep. Um, but how does that.

You know, you go from one little scrappy team of five to 70 people with multiple teams and things like this, like I imagine in the microcosm of a growth organization, you probably still have some of those scaling issues, right? Where suddenly like teams are conflicting on tests and stuff like that. Did you have, was there like a crossing the gap as you spread these and then, yeah, and then I have a follow up question. So I'll answer that one first. Yeah, no, totally. Um, I mean, I think.

People ask me why I've been at Strava for so long. And I kind of say every year it feels like a new job. So I don't have to go somewhere else for a new experience. Like as you're growing, there's also new people coming in and you people, you know, people leaving. And so there's a little bit of that life cycle of, of teams that allow you to change as key people leave, you can kind of make shifts that, you know, that maybe we're just easier when you have someone new coming in into a new role. But yeah, there's definitely been growing pains. I mean, I think.

David Barnard (21:09.034)
In terms of like, how much do you know about what the other teams are working on? How are, you know, product managers interacting, collaborating? What are the overhead of some of the meetings and stuff we've had? So instance for one, one way we're still working through right now is this meeting or this process we call Experiments Weekly. So forever since the beginning of Strava, we've been on my journey at Strava and the growth team at Strava, we've had this meeting once a week called Experiments Weekly, we represent all the experiments that the Growth org team has run.

And amazing meeting early on, it's five people and you get to debate. Why did this happen? No, this happens. Here's my thing. Here's the follow-up. And then like, you know, within two days, you have another one running. Um, as you grow, it becomes a bigger meeting, right? And you have a lot of people like me being bureaucrats now, uh, as I kind of call myself in the meeting and you have someone who's, you know, me eight years ago knew the role, not really wanting to speak up and be like, Oh, I disagree with that hypothesis. Right? So then you're like, Hmm, okay. What do we do? And.

So we got to the point where we had like 70 people on this invite last year. And the only people that were speaking were, leads of leads kind of thing, right? So I oversee growth, all the growth teams, we have a head of analytics who supports all of growth, the growth teams and like we were talking, but no one else was. And so we started seeing one of the growth teams that started the exact same meeting on their own and they were having so much success with brainstorming and everyone being together and in the weeds. So we're like, huh, what do we do about this?

When we canceled the big meetings that all the small teams have their own meetings and that's been great apart from for people like me and I'm like, what's the bigger learning, how are we talking? You know, and so we're still trying to figure this out and like, what's the right process? Meetings are tough. I now live in Ireland. So time zones are tough. And yeah, it's time, you know, it's, it's how do you, how do you create that, that narrative or figure out that narrative of learning that matters? And, you know, especially on a growth team, right? Where it's by definition, it's rap.

rapidity and testing and experimentation. And I think there's benefit, and I don't think everyone agrees with me on this, which is good, but I think there's benefit to a team being laser focused on a specific set of areas and almost not wondering about the world around them and getting to move fast. But then you need to have someone who's pulling out those threats. Yeah, because I imagine there's collisions and things sometimes where two teams are testing or in different directions that don't work well and stuff like this. Or yeah, and it's like, hey, this learning here and this learning here together, that's a pretty huge insight.

David Barnard (23:33.846)
Right. Um, and like, how do you do that? And that's something that we haven't figured out fully. Um, I see it as part, part of my job. I get to do that. So I fly a lot for work and I pull up all of the experiments that we've run recently before my flights. And some of my flights, I'm just like reading through experiments. And so the poor, poor people on my team, you know, I, I land and I just sent off s tons of slacks, I pre-write slacks and I just, I'm hammering them with like, why this, I just agree with this learning. What about this? This is cool. Why are we, you know, let's talk about this. Let's celebrate this. Like.

Did you know this is one of the best results I've ever seen? Like why wasn't, you know, why weren't you running around screaming about this test? This was awesome. And you know, it's making it overwhelmed. So I think that's one kind of like good problem to have. Sure. I would say another one is in the tooling that we've built. For a while, we didn't have people doing feature education, teams doing feature education. Teams were very much focused on like the core user, the engaged user.

with their features. And so the new user experience or the win back experience, um, resurrection, if you call them those instead are similar, right? It's like someone's coming back to teach them about how to use this thing. And so we, and I write about this in my blog, which you can, you can read later. We built a service for this growth team. For this growth product we have to do, we were working on the feed. So we built the service to allow us to do feature education. And for a few years.

But probably two years, no one really used it apart from Growth Team. So we would add coach marks and feature education pop-ups and tool tips and kind of do things around the product and it was great. And then teams for many kind of cultural reasons, different product managers, different focuses, everyone started being like, this is important. We're going to do more feature education. And now it's funny because I was just in like a roadmap review and one of the teams, one of our activation team, their test is to remove all of the feature education.

In a test, you know, we call those negative tests to see, you know, what is the overall impact of something? Do we need to take a step back? And it was so wild to me because I was like, I tried for so long to get people to do feature education. Now we have too much feature education and we need to take a step back. I mean, this is a, this is a classic, like not to get late stage, but you always hear this joke about Facebook and things like this, about how, you know, like, um, there are, there are certain real estate and apps that become super overcrowded, right? And I especially imagine when you have federation is good.

David Barnard (25:54.518)
But then at some point, you know, you talk about they don't see the small teams might not see the externalities of the competition they're having. And it's good. I mean, it's great that you guys have a culture where you can test that. I was going to ask is kind of related. But my following question was, are there any just normal product teams left at Strava? It's just like all because I'm like thinking I'm like, yeah, you just kind of named all the parts of your app. I don't know what.

there's left to do, which actually, if that's true, it's fascinating to say like, yeah, we don't have products because we just have growth teams that focus on different parts, which probably for a startup is what you should mostly be doing. Yeah, no, and it's good that we don't. There's always that core value that you need to be investing in, right? And I don't think that's the growth teams necessarily job. I think we can sometimes find ways to expand core value or extract more value, but I don't think it's necessarily expanding it. So we have like the activities team.

that's focusing on the core noun of Strava, which is the activity and all the features and analysis around that. We have the GEO team, which is focusing on Raph recommendations, exploring the world around you. We just made a big acquisition of Fapmap, which is a great company that has amazing software and amazing user experiences. And then we have another team that's focused on more of the social experiences, which right now is a lot around, kind of just the social experiences, clubs, challenges, those kinds of things. And so,

A lot of how we think about this, and this is definitely not something we're perfect at, but a lot of the teams think of themselves as platforms. We're creating the ability to use the activity, the club, the follow, the route in many places in the product. We want to be able to surface this through an email, through a push notification, through the feed. We want to be able to really modularize our product. And so a lot of the work we do is to...

We're just going to view ourselves and view teams with themselves as platform, create a platform, and then use that platform to optimize and deliver a user experience. We kind of went down this rabbit hole talking about feature education. What does that look like tactically? Like, like a little pop-ups in the app. Like what, what is the feature education discipline look like? Cause this is something I think from onboarding to all sorts of

David Barnard (28:07.574)
parts of the app, I think a lot of developers miss some of these kind of fundamentals. Yeah. And one of the blessings and curses of Strava in a way is that everyone, most employees use the product every day, which is great, but you're not using the product from the perspective of a new user, right? Or a win back or someone who uses it as once a week or twice a week, like an average person, not everyone is running and cycling every day, et cetera. And so that kind of empathy is tough.

We have some things that we've built to help with that. Like we have a switch that you can just make your whole profile free. And most of our subscriptions teams just sit in that mode. So for feature education from us, it's tool tips, kind of coach marks, it's in-app, you know, all the units of saying like, this is how to work. It's push notifications, it's emails. It's all so many different channels. Of course, the next question you might ask is how do you manage all those channels? And the question is, we don't do that very well. No, we just hired a new chief design officer.

She's fantastic. Her name's Anita from Twitter and she's asking me these questions about can I have the user mapping and can I just see the user journey? And we're like, we'd love to see that too. And I think here, I'm not, you know, I probably just, I think a lot of people feel relieved when they hear that there's always chaos, right? There's always a little bit of chaos with it internally and it's easy for people to look at Strava and be like, oh, they have their stuff together, right? Clearly, they know what they're doing. And it's like internally, it's like, man, like sometimes we don't even know.

know, exactly what every user is seeing at any time. Observability is hard. That's a hard problem. And I think I appreciate the people around me being willing to still move forward and still make decisions even if we don't have that perfect observability. And, you know, it's something we're trying to solve for. But, and this is, you know, it depends on your enneagram or your personality. I like to live in a world of like managed chaos. This management philosophy by Eric Schmidt, where it's like, let people do their jobs and like...

maintain just enough order in the chaos so that you can still make decisions, but be okay with chaos. Yeah, I mean, if you spend as a leader or a team leader, whatever, your whole time trying to make sure everybody's coloring within the lines, you're just gonna end up spending your whole time trying to cut off downside and miss a whole bunch of upside opportunity, right? Versus, like you were saying, I'm sure this has happened many times over the last eight years. Somebody ships something that does something they don't expect is bad.

David Barnard (30:30.546)
My experience is you often catch it pretty quick. Right? Like if it's that bad, customers will tell you, you will find it, you can roll it back really quickly. Ideally, you have that infrastructure in place where you can roll it back really quickly and a culture and you built some tooling that lets you roll it back really quickly. But you can think of it like, you know, as a microcosm of how the greater economy organizes itself, right? Which is through like chaos and competition and stuff like this. It's not dissimilar to how, you know, when you guys reach a scale, you know, obviously you guys have, you know.

70 people just on the growth side, you can do this. But if you don't preserve that, you end up with, yeah, the opposite, which is waterfall, top-down bureaucracy, slow behemoth, never innovating, at the cost of never upsetting anybody, which I just don't think works. It works maybe if you're Oracle, does not work if you're Strava. Yeah, I mean, that's so key. And also something that I have to learn and remind myself every day. I was running tests.

You're like, what is it? What's a bureaucrat's job in this world? And it's funny because I remember being the, you know, being the guy that was just running tons of tests, like I was looking back at the spreadsheet of tests. I ran, you know, eight, almost eight years ago now, just, you know, from that year, like what did I run and what do we do? And just remembering how fun it was just to like turn out test after test after test, and so many of the tests were just my ideas and my ideas worked and the bureaucrat, you know, maybe they just didn't work because they weren't as close to the problem or thinking about it night and day. And now I have to think to myself like.

all this context and I have all these opinions, but I'm so far away from it now that I need to trust the teams to do their jobs. Even when it looks like chaos, I need to remember what amount is okay. Am I just making people's lives harder? By the questions I'm asking, how do I empower them to do their jobs really well? Because the people on teams become the experts and they want to do their job really well. They want to see business impact and my job is to kind of...

help them do their job really well versus tell them what to do. And that's why I, I engineers thinking of product managers, some of our best wins have come from engineers six months out of college, a year out of college who was like, I want to try this. Um, and we actually do, we used to do this thing. We haven't done as much recently, but we used to, especially when we were in person, all in person, we used to do this thing called experiments day where like once a quarter, there was a day where the team was allowed to run whatever experiments they wanted. There were some rules like

David Barnard (32:56.854)
don't take away a subscription upsell and don't crash the app kind of thing. And it has to be only 10% of users, but there was no, there was no buy-in, no, no necessary buy-in needed from a, from a engineering manager or product manager. And of course the risk averse folks would see that as, um, Oh, they're just going to chip whatever they want. It's going to be hacky. It's going to be bad. They're not going to collaborate. You know, we just took a step back and the team still worked together. Like they all worked literally every single person still work together, design analytics, engineering. It came off the ideas.

And a lot of the ideas were things that we had not prioritized because the data said probably not a lot of juice in that squeeze. So an instance here, um, and shout out to Annie, who worked on the growth team for a long time at Strava. She really wanted to run a test where if someone followed you and you saw their profile anywhere, it said, follow back. And the data said the majority of relationships in Strava were as reciprocal. So what's the point? But she was like, all right, I'm going to run this on experiment's day. And she ran it.

and resulted in the most, the biggest increase in fall rate that we've ever seen. And again, it was small, reduced friction, the simple insight, nothing mind blowing. Do you remember what the miss was on that? Like, I mean, cause I was just, you know, you show people a button, they're going to push it, right? So I mean, it might be long time gone now, but I see that can happen all the time. You just, organizationally you.

I always like to say a whisper becomes a myth becomes a legend becomes like just the truth, right? This happens all the time. And like, you can see how somebody ran a half experiment five years ago and it failed and then it just becomes knowledge. Like, yeah, I don't know if you're having to remember for that case. I don't remember exactly. I, you know, in one of those things that was so simple and so low cost to do that you think of yourself like, why did we ever, why did we even talk about that? I think that's, that's the thing that probably

I try to do the most now is where do we talk about something more than it would cost to just build it? Yeah, yeah, yeah. Yeah. And I think, you know, that's ultimately probably what my philosophy, I think my role is at Strava is to make it easy enough to test any and every idea rather than us having to self-select here of the five designs you have as a designer. Here's the one you think is going to work. You just reduce debate by making debate the more energy consuming thing.

David Barnard (35:16.106)
Like just, I think it's more inclusive, right? I think because you are, if you move fast and you're able to test a lot of things in a very scientific way, you remove the bias of someone, you know, someone, the, you know, the loudest voice in the room, right? Becoming the person who, yeah. Right. And you instead say, we want everyone's ideas and we're going to test every idea possible. And obviously there's a limit to that, but we would like, we want to test things. You want to create safe spaces to do that. And some amazing stuff comes, comes out of that.

Do you guys, I imagine the answer is yes in some form, but did you design, I can remember looking at these old user models from Twitter back when they were really growing a lot and stuff where you have sort of like a, you know, it's maybe not a perfect model, but you have some sort of activation tied to retention, tied to all those things. Do you have a mathematical model that you sort of run your tests on top of, like some set of core metrics that you think are interrelated in certain ways? Did you build that first? Did you arrive at that? Do you have that?

That's always a work in progress. Sure. We, early days, the product analyst on the team, Dave, shout out to Dave, was basically running the same SQL query over and over for tests. And we had a very, we were very, I think we've always been pretty good about a very small subset of metrics to run after. And again, we got a lot of help from the early growth people at Facebook and other companies and Pinterest who came in and helped us say like, this is what an activation metric is, this is what an output metric is. Teams should have clear metrics, right?

And so we always had that. And then, um, by teammate Dave built, um, our internal reporting experiment reporting framework called one ring. And it's an ode to Lord of the Rings, one ring to rule them all. So it's like one secret query to rule them all. Yeah. Building stuff. It's always named after the star Wars. It's great. Um, and it's still called that. It still has a little ring in the tableau dashboard. And that allowed us that became like the source of truth. Every experiment for the most part, obviously these exceptions has.

metrics in there. And now we have, I think so many metrics that our data engineering team, it's like, we got to stop like these, you know, the jobs to run the experiment analyses overnight are taking forever. But for the most part, we've been pretty static in terms of like measured outcomes, not modeled outcomes. We have now, we now are trying to do a better job. And we've been, we did this all of last year of when you move a certain output metric, typically for us it's week two retention in many cases. What is...

David Barnard (37:41.186)
the impact on wow over the course of a whole year or whole 12 months. And so there's like a decay built in, this modeling built into, you know, if we increase week two retention for a win back today, what does that actually mean in the course of 12 months? How many more wow are we going to see in the product? So you're actually looking in some ways at like leverage of certain metrics versus like they're just face values. Yeah. But we were trying, like we have a long, I think a long way to go to keep.

doing that with ideally with our input metrics. Yeah, errors amplify as well, right? When you start to model out. Yeah, and I always get a little nervous on too much reliance on modeling because to create the model, you build it on data that you had. And after a certain while, the data you have was generated by the model you created. So there's definitely a balance. And I think things like holdout groups, long-term holdouts can help you with the source of truth.

Yeah. And being simple, right? Remaining simple. And I think when you talk to think about the folks listening to this podcast, who probably don't have 70 FTE sitting around ready to put onto a graph organization, it's like in the early days, like define a few really core key ones and don't go test crazy. I think I've made the mistake in the past during experiment design of wanting to design measurements as close to the experiment as possible. When I think that's, you know,

Be like, okay, well, if we're going to change this button, let's specifically change the measure of this conversion rate of the button. And that's the only thing we can really attribute. And maybe there's some value in that, but really what you should probably be tracking is how does this affect the overall output? And if it's not measurable, then it probably doesn't matter. One of the things I wanted to dive into before, before we have to wrap up.

is a couple of tactical things. And one of them is that, and we just haven't talked about this enough on the podcast. And I know you've thought a lot about this on the growth team at Strava, but the app store is such a black box. How do you think about that inside of Strava from a, and thankfully the app store has evolved now with custom product pages and stuff like that, but you have to send this.

David Barnard (39:53.07)
who got a referral, not to something you have control of, but to the black box of the App Store with screenshots and a title and the icon and all this. How do you think about the App Store black box as part of your kind of growth journey? It's a great question. Definitely not my forte. So I'll answer as much as I can to represent the growth marketing folks on my team. Well, there's always optimization, App Store optimization, right? Classic ASO.

If you've written ASO in articles and still don't know what it means, it's App Store optimization. I feel like there's a lot of that in growth, right? There's a lot of acronyms that get never defined. It's like that. It's changing your App Store photos and images and testing that now that you can actually test, right? For the most time, you couldn't test that. You didn't have that functionality on the App Store. And so we tended not to really change it too much because it was hard to attribute. And it's...

Is it worth spending time on things that you can't measure? So now you can, so that's a little better. The problem there is novelty effect, right? Anytime you change something, as you said, like with a button earlier, like it can, you know, works the first time, but what about in two months? Yeah. It's hard to do that. I think we've, we've tried things in the past where you have, you know, some companies can provide services where you create a fake app store facade, and then you optimize that a bunch and it's really just a webpage and you just optimize that and then you take the win of that there.

It's a lot of work. And so I think what we've really stuck with is like app store ads, making it very clear what you're doing on Strava. Videos really helped us. And then app reviews. Apple really takes into account how many five-star ratings you have in terms of how well they'll rank you. And so we've really, two things. One, try to have a great app. So when it comes to like foundational metrics, we always go for four nines, four nines of...

crash-free sessions, four nines of availability from our services and that helps a lot. And then also prompting our users to rate the app. Apple has nice functionality and Google has nice functionality to tell you, hey, you're using the product, why don't you rate us in the App Store? So we've tried to do things like that, kind of to be good citizens around our App Store presence. I don't necessarily know if I, again, with the Strava being a big organic growth engine, I don't know how much I would give.

David Barnard (42:17.214)
advice to other people based on that because we, people are often searching, you know, this is the brand it's search, searching for Strava. Right. So you have a brand and you have channels that are not dependent on it. That's the best app store optimization advice you can give is like, don't depend on it, right? Just make it a small multiplier into what you're doing. I'm sure you guys get some amount of like organic discovery and features. Have you been successful with, I'm sure you have like over the years with partnering with Apple and just working the app store as a growth channel? We definitely benefit from.

having features with Apple, especially different countries. So often, yeah, hey, we're going to do a feature for you in Germany. Can you provide us special assets? The one interesting thing, I think you can actually learn a little bit from your logged out pages, both on web and mobile, in terms of just what we call Strava, the front doors. So before you've entered the Strava ecosystem, what works? One of the early tests we did...

the activation team was changing the photos that you would see, kind of a welcome experience before you signed up. And we discovered that back then Strava was very much cycling or running. So we used to ask you, are you a cyclist or are you a runner? We don't do that anymore. But that was really interesting because we ran tests where we had, for the most part, cyclists. We showed a lot of cycling photos and we tested cycling versus running photos. And we discovered that runners were put off by photo, you know, when the splash screen was a cyclist.

Cyclists didn't really care about seeing a runner. And then obviously men didn't mind seeing men or women and women preferred to see women. And so that was a very interesting kind of realization of like, we're trying to expand who we serve. We're trying to serve runners. We're trying to expand the brand around Strava, not just be cycling. Maybe we shouldn't lead with cycling photos everywhere. And so, you know, it's simple things that you can test either on your website or on your mobile app that then you take those insights into.

the black box of app stores and for better for worse, hope that those learnings persist. Yeah, I was gonna say, I mean, that little nugget right there, for better for worse, you hope that learnings extend? Cause I feel like that's something in growth teams you end up doing a lot, right? You test something and then you get a result, but then it's still up to you what you wanna do, right? You can even override potentially a neutral result or like, how do you think about that? Like, how do you think about...

David Barnard (44:35.786)
applying beyond just data, like applying gut experience, like just one, two things. Yeah. I mean, we have an amazing brand and marketing team, right? We're experts at, you know, telling the story of now, but also the story of tomorrow, and I think that's something that I very data-driven person, I want to optimize for the user of the now that I know that I know the data of their, the tension there is what about the user that isn't here yet?

or the one that is here, but we're not really serving them yet. Um, and can we make Strava feel like for them? And so there's an aspect of, of that tension, which I think is really healthy, um, with everything from like, you know, brand images to the copy you write, you know, that welcoming experience. It sounds like you can inform and help them, right? Like you ran tests on how do these different images, but then you tell your brand team, no, like, Hey, like, here's how these different things perform. And then they can go and decide like, okay, what do we want to weigh in and things like that? Which we've had a great partnership with like the

power of copy. Like the power of copy is huge. Often, yeah, for us, copy is being huge. And sometimes images actually detract or distract users, especially like we have amazing brand photography that is really useful in many places. But often when we have brand images in product settings, it lowers conversion rate. And the theory is like, it kind of maybe feels like an ad or it's distracting. And so there's times where like that brand image is so powerful. But

the copy, no matter where it is, has a huge impact. Like the difference between continue with versus sign up with on like your login buttons. Yeah. That's really cool. So that's, and it's really fun with the copy team to like run copy tests and see those impact and they can be huge. Yes. I wish we had a consumer company, David, sometimes like it sucks. We only get so many signups a day. We have almost enough now to do more testing stuff, but.

it's so much harder to do with Revenue Cat than it would be with Strava. So that was, that was such a great nugget. And unfortunately, I wish we had like three more hours to talk, but we're going to have to wrap up there. As we are wrapping up though, we're going to include links to of course Strava and your Twitter LinkedIn. But anything else you wanted to share as we were wrapping up any job posts you're especially excited about hiring or anything else?

David Barnard (46:57.718)
We're hiring a RobotoStar hiring a server engineer for our comms communications and personalization team, which also happens to own our experimentation platform that we've built internally. Um, so if you're into anything like that, it's one ring. It's one ring. Yeah. And it's really cool, I think, because it's user facing, um, like actually external user facing, you were touching like communications and push notifications. But it's a scale and data problem, which, you know, a lot of engineers really love because we're dealing with over a hundred million athletes and

They're uploading, we get over 40 activities uploaded every second. And so the volume of notifications and emails and that whole system and the number of analytics coming in that we're piping into our machine learning algorithms, like the scale of things is unbelievable, but you're also directly impacting both internally from a shared platform perspective, but also to the user and how we're kind of scheduling notifications or feature educations. I think it's a cool place. But.

Yeah, it's a cool place to work. Yeah, that sounds like a super fun role. I'll make sure and get that link from you and include it in the show notes for people and then include the Strava's career page as well. But Jason, thank you so much. This was fascinating and learned so much chatting. So thank you for being on the podcast today. Yeah. Thank you for inviting me. I love talking about growth. So this was a, this was a fun hour. Thanks so much for listening. If you have a minute, please leave a review in your favorite podcast player.

You can also stop by chat.subclub.com to join our private community.