How To Run a Growth Team Meeting
How To Run a Growth Team Meeting
19. How To Run a Growth Team Meeting
Class Introduction18:01 2
Class Introduction Why You Need a Growth Team05:13 3
What Is a Growth Team?07:09 4
The Mission of the Growth Team15:31 5
Types of Growth Teams08:45 6
8 Critical Skills Every Growth Team Must Have08:25 7
How To Establish Communication and Accountability08:44 8
Growth Acceleration Process08:00
Focus on the Goal05:29 10
Analyze the Opportunity08:40 11
Brainstorm Possible Solutions18:46 12
Prioritize the Team's Ideas05:25 13
Demo: The Growth Idea Sheet09:34 14
Run the Test16:51 15
Report the Results02:53 16
The Tools We Use06:13 17
How To Establishing a Culture of Optimization17:50 18
The Great Testing Tempo Myth05:47 19
How To Run a Growth Team Meeting19:40 20
Who Should Attend a Growth Team Meeting12:50 21
The Importance of Reporting and Documentation07:51 22
How To Pilot a Growth Team in Your Company06:46 23
Auditing Your Existing Capabilities09:03 24
Make Any Essential Hires16:38 25
Get a Quick Win03:55 26
Get an Integrated Win02:17 27
Decide Where the Team Should Live03:04 28
Formalize and Announce02:57
How To Run a Growth Team Meeting
Now let's talk about how you run the actual growth team meetings. So we talked about the growth accelerator process, those six steps that are happening. How do those six steps factor into the meeting cadence of a growth team? First of all, there's two primary meetings that the growth team is gonna have, that's gonna be exclusive to the growth team. The first is the Monthly Planning Meeting. This meeting is typically 90 minutes long. It's a biggun. We'd like to hold this meeting the last Thursday of every month, because this meeting is going to generally inform the activities of the month moving forward, so I really wanna know, going into a particular meeting, going into a particular month, what are we working on that month. I wanna know the theme, I don't wanna show up the first day and be like, "Okay guys, what are we doing this month?" Get some momentum going in, and the attendees of the growth team, plus, and this is a biggie, anyone who attended the growth idea the previous month o...
r who wants their idea considered. This is a relatively open meeting, but if you wanna attend this meeting, cool. You got a growth idea? If not, and you're not on the growth team... You're just here to watch, got nothing to do that day? Right? What's there? So, it's optional attendance if somebody submitted an idea and they wanna be there. The second is the Weekly Check-In Meeting. These are generally about 30 minute meetings Monday morning, and the exact days you can move around, there's nothing magical about it, I just like... We've had this Monthly Planning Meeting, having that at the very end of the month was better, we also do our weekly all-hands meeting, when everybody's there together, we do that on Wednesday, that's why we did this the day after. The Weekly Check-In Meeting Monday morning... I generally don't like morning meetings, they tend to just wreck the entire day, let's show up on Monday and play business, 'cause that's oftentimes what meetings are, but this is an incredibly efficient meeting and depending on what's going on, it absolutely can change the priorities of that day and that week. We tried a bunch of different times, eventually settled on Monday morning. This is the one exception I made. Generally, at my companies, no meetings before noon. And "who", we got the growth team, plus any project stakeholders. So project stakeholder would be anyone who is involved in an active build of a test. Maybe it's some designers, maybe it's somebody on the product team or the dev team, they're gonna maybe need to deliver an update, and they run that as a stand-up. Those are the two main meetings. Now, again, I've seen a lot of people out there talking about how this planning meeting should be weekly. Every single week you need to be resetting and running new tests. Going back to what I said before, if tempo is your goal, then weekly makes sense. If your goal is to run meaningful tests, you're gonna be hard-pressed to find a meaningful test that doesn't need at least a couple of weeks to run. So if you're meeting every single week to plan what the next set of tests is gonna be, you're meeting too frequently. Generally the builds aren't there, you gotta leave some time to let the cake bake. So we do the planning meeting, then the check-in meeting, the other thing that isn't so much a meeting is the Project Spec Submission. After this Monthly Planning Meeting, once we pick exactly what's going to be... the big tests that we're gonna be running, once those have been selected so we're beyond the brainstorming phase, we've actually selected the test, now we're moving on to the build phase, then usually, they're gonna follow up with "Here's the project spec," 'cause we need to make sure that the tests we're planning on running, the builds we're planning on doing, they can, in fact, be done. So this Project Spec Submission, that's gonna be close of business the Monday following the planning meeting, so if we have the planning meeting on Thursday, the growth team lead has Friday, and all day Monday, to spec out the different builds that they're planning, and the biggie is getting cross-departmental approval. You don't want your growth team deciding unilaterally what the product team's gonna be working on next month. That is not good, and that will super piss off your product team. Right? They'll be like, "I'm not gonna do that." So, (clears throat) they might leave the growth team meeting saying "Okay, we need to build new walkthrough, a new onboarding process, and I think we get the product team involved, hopefully that'll work, we talk about who's there," maybe somebody in the product team's like "Yeah, we should be able to pull that off," but they need to actually spec it out and get full approval to know that it's gonna go. So these are the types of meetings and check-ins. Now let's go through the agenda of that Monthly Planning Meeting, so the big, 90 minute meeting. It starts off with the formal report. So remember we talked about, from the growth accelerator process step six: the report is presented to open up the meeting. Now everybody at the meeting should have a copy of any of the written reports that happen, and so the growth lead should open up with "Generally here's what happened." Hypothesis; was it right or wrong, key learnings, big wins, and reasons to celebrate. Now, if you recall from the circle in the process, why do we want to open up this meeting with the report? Anybody remember what reporting can inform? Was it focus? Yeah! So after you have the reporting, remember the circle comes back. So based on this report, maybe what they say is "Team, great job, we knocked it out of the park last month. We were able to really move the needle on activation, and for this month, I think we can shift our focus to something else." Or, "Hey guys, we were able to really move the needle last month in terms of activation, we still have more ideas and I think there's additional opportunities to be had. I recommend we keep our focus here." Or, "Everything we tried failed miserably. Activation is still terrible, we need all the ideas that we can get because last month they were bad." Whatever it is, it should be in the context of what you did, and that's when the team starts to feel like, "Okay, cool, there's a rhythm, there's a cadence. We did this, now we're doing this." Know the "why" cuts both directions. Your people who are making decisions need to know why they're doing it, but you also need to make the case for why you want to do something. Why you suggest the team is doing something. If you want to, as a growth leader, have people excited about what's going on, tell them why they're doing it. Explain the reasoning behind it. With this formal report that is a baked-in opportunity to explain the "why". Good, bad, indifferent. That's how I open up. Then, discuss any open projects that potentially need to be extended, so the open projects are essentially "builds", we have the build process, so we're still working on prepping. The projects and the tests hasn't even started yet, it's still in the build phase. It is very common, if you are doing tests and growth projects, that they don't meet the product spec guidelines, just like anything else that you would build, on product side, on that. So this is where you need to look and say, "Hey, we said that it would be done by this time, it isn't, so we're gonna be extending it." Sometimes what you say is, "It's not done yet, we've missed our opportunity, we gotta abandon." Sometimes you say, "It's not done yet, and the product team is having to move on to something else, so we'll pick this back up in 30 days." You don't wanna leave projects just to linger, 'cause people are gonna wonder, especially if it was their idea. You wanna really be able to address... And hopefully it's like, "Yeah, yeah, we ran a bit long, we're gonna extend it, push the start out date up to this," but you gotta acknowledge, always always always have to acknowledge, so discuss extending any open projects, then, discuss and "vote" on next month's projects. So discuss. So what we're doing right now is, this meeting is not a brainstorming meeting. The storming of the brains should have already occurred, and it is now sitting on that growth idea sheet. So what you're doing, is you're pulling up the growth idea sheet. Now, the growth lead should have already reviewed that and have a general sense of what the recommendations are going to be, so the lead's gonna make some suggestions, if the lead comes up, is like "What do you guys think we should do?" They're not leading. So the lead should show up, but still invite discussion. The reason that "vote" is not vote, but it's "vote" with the air quotes or the real quotes here, is because it's not a matter of opinion. Here's where we're focusing, which was informed by what's going on over here, these are all the ideas that have been submitted thus far, and based on the ideas that have been submitted thus far, and narrowing down the list based on where our focus is, these are the ones that scored the highest. Does everybody agree, does anybody have anything to add, let's discuss it, let's talk about it. Let's talk about these projects, do we feel like there's something that can get done. Does that make sense? This is not a democratic process. People can voice their ideas and their opinions, but there needs to be one person who's ultimately responsible for this, the leader. They're the ones that are ultimately responsible for it. Now let's talk about the agenda for the weekly check-in. So here's kinda how that meeting goes, again, the growth lead is there, leading this meeting, the people that are all involved in open projects, as well as members of the growth team, they're all there and in attendance. First they open up with an Open Project Status Report. Again, we're not talking about tests, we're talking about open projects. If you are running a growth team, you are simultaneously a project manager and an optimization expert. You're having to manage projects with the best of them, and you're simply saying, "Okay, this project," remember how every project has a name? "So, this project, on track, behind schedule, or in danger." If it's on track, great, this projects on track, this one's on track, if everything's on track, that part is incredibly brief. Delightfully brief. If it's in danger, then that's where there's a bit of a discussion about... 'cause all the stakeholders say, "What can we do to speed things up? Are we gonna be able to pull this off, or do we need to abandon or backburner it?" But everybody who's involved is there, and they can make the call. So we start with the projects, things that are still in build. Then, we move to Open Test Status Report. What are the tests that we are currently running. These are the tests that we're currently running, and remember some of these tests are gonna overlap. You're gonna have tests from previous months that are still going. Previous months, previous themes that are still going, so you're doing a comprehensive test, this one's over-performing; over performing is it is 10% above the hypothesis. 10% or above is generally what we're looking at. That's a meaningful difference. On target, it's at or near the hypothesis, so it's a rounded, maybe a couple points below. Under performing is it's well under the hypothesis, and danger zone is "Oh, God, what happened. This is doing horribly." I'll give you an example. When we tested 30 day, versus 14 day trial, we watched our trial rollover rate, so the people who signed up for a trial, and then the people who rolled over and became a full-paying member, we saw it drop by 2/3, when we did that. 2/3. That's a problem. You don't wanna let that run forever. So danger zone is "Holy crap, something bad has happened." Oftentimes when you see something that's in the danger zone, what has actually occurred is, something broke. During the test, something broke. During the test, somebody put a wrong identifier in a place, it is not tracking the data correctly. So ideally your growth team lead has looked at this ahead of time and if something's in the danger zone they've already investigated, so they're more saying, "We got this one that's in the danger zone. I looked into it, I put the wrong Google Analytics thing in the wrong place. Sorry about that, we gotta reset the test." That make sense? So quick, everybody knows what's going on, from a project perspective, and from a test status perspective. If you wanna hand things out, we actually keep this on a whiteboard, all the open projects and all the open tests, and we go around with the little colored marker and put red yellow green next to it, so that anybody, if they didn't make it, or if they forget, wanna come back by, they can see it. We tried doing it with a Google Doc for a while, it was easier to do it on a white board, 'cause it was a standup, and everybody's writing stuff down, and we just want it to be quick. So now let's go back to the meeting schedule just to kinda hammer this home so you can get a sense of the cadence, this assumes a six-week cycle, so generally, that last Thursday is where you're gonna have the Planning Meeting. The Planning Meeting, that's what's going to inform what are the projects and the tests that we're gonna be running for the next 30 days, what's the theme. On the 4th, or the following Monday, the growth lead is supposed to turn in the project spec for everything that was discussed here, and they also do the first check-in on that day. The project spec is due at the end of the day, the check-in is that morning, alright? Weekly check-in, weekly check-in, weekly check-in, now we're at the end of another month, and so it's time for another planning meeting, and then we have another weekly check-in. So that's the general pace. I know that most people hate meetings, and there's a whole anti-meeting movement going around, meetings are great. Meetings are when people get together and they communicate, what's wrong with that? There's nothing whatsoever wrong with a meeting. That's not how we treat any other meaningful relationship in our life, "I have these friends but we never get together, 'cause it's just a waste of time." "I love my family, but we never have dinner together, it's a waste of-" like that's not how we treat any other relationship that's meaningful, where we're working together, and yet for some reason, when we are working with people, we declare that meetings are awful because nothing gets done. It's possible that it's not meeting's fault that nothing's getting done, it's possible you just kinda suck at doin a meeting. So if you follow the cadence and do the process, do not allow that growth planning meeting to turn into a brainstorming session. That's the way those meetings get off-track. If somebody has an idea when you're at that planning meeting, tell them "Hey, love it, open up your laptop, enter it in, and if you get it in there pretty soon we can discuss it." I can't hear anything unless we're talking about something that's on here. You're a moot. Nothing's happening. That's where that one can get off track. Don't let it turn into a brainstorming session. That's not the purpose, alright. Get it on the sheet, we're gonna discuss, make sure these project specs come due here, because that's when the weekly check-in can get off-track. If you don't have project specs, then the weekly check-ins just become a discussion about project planning. That should all be documented, should all be written out. What all these need to be, and then these other ones it should be, "Here's what we're doing," red yellow green. "Here are the tests," red yellow green. Or bright red, holy crap, in which case, it shouldn't be a discussion, it should be, "This is what happened, here's how we're fixing it." That make sense? All told, with the exception of a week where there's both the check-in and the planning meeting, you're talking about less than two hours in a planning session, in a meeting. That's not that much for a dedicated meeting time for a team that is dedicated to growing your company. That's not a lot of time, okay, it really isn't. Any questions about this on the timing structure? I will tell you, if you wanna play with... The only thing, if you move this to a Tuesday, it'll fail miserably. I'm just kidding, it's fine. It doesn't matter. I'm giving you when we do it, because we tried a lot of days and this is what we found works the best. If something works better for your company then by all means, change it. Yeah. Have you ever tried check-in meetings on Fridays. We have tried check-in meetings on Fridays, we found that Fridays are when everybody takes off, so we kept having to re-schedule the Friday check-in meetings to Monday, and whaddya know, they just wound up on Monday. I know, believe me, I had one mandate when we started this process: you may not do a Monday morning meeting. That was the only thing I told 'em. I said, "If we're gonna do this, we're gonna figure it out, but you may not have a meeting Monday morning, Monday morning meetings are toxic, Monday morning meetings start off the week flat-footed, you're gonna be there, screwin around, talkin about what you did over the weekend for the first half hour, nothing's gonna get done, it's gonna be lunch time, and we're gonna start of the week-" And now it's on Monday mornings, 'cause that's what wound up working the best. Dogma is expensive. So I was very dogmatic about not doing Monday morning meetings, they were like, "Can we just move it to Monday?" "Okay, fine, but it's gotta be after lunch." and I found out, they were meeting Monday morning anyway if something happened, like, "Hey we gotta get everybody together Monday morning, 'cause stuff happened that's gonna change what we're working on today," and so each time, where it just naturally ended up was Monday morning. But, try it in your organization, and if it naturally ends up in another spot, put it there. Don't blow the bugles. No (bugle noises) "I declare that this is what we're doing." I did that, and the one thing that I said they couldn't do, it's now there, 'cause I was wrong. We used to open up the month with the planning meeting, but that made everybody feel flat-footed, so they said "Let's move it to the last Thursday." We used to try to do this planning meeting on Wednesday, but that was too much meeting time in one day 'cause this is when we have are all-hands and when our managers' doing their one-on-ones. So we tried doing it on Tuesday, but then people felt like that was too much meeting in the middle of the week, so they moved it to Thursday. Everything that you see here is because that's where it wound up after doing this for a while. But, if you wind up putting it at a different time, by all means, do that. But yeah, great question 'cause, yeah, we did do that. I wish it woulda worked on Fridays, but, in Austin, people are like "I'm done," on Friday. Okay.
Ratings and Reviews
Course was amazing! I'm a startup founder & the content was perfect for stage of our company. Ryan is a fantastic presenter & I found both his delivery as well as his ability to answer pointed questions to be extremely helpful. I'd recommend this to any company looking to build a growth team!
This was an incredibly helpful class & i found many of the frameworks & suggestions immediately useful. Well worth it.
Amazing class !! Really complex issues are simplified and put together in a systemic and practical way !! Just take into work and reap the benefits !!