The Importance of Reporting and Documentation
We touched on this a bit, I just really want to kinda hammer this home. Because it's so incredibly clear. Proper reporting and documentation will prevent you from duplicating efforts and making the same mistakes twice. Okay, that's what proper reporting and documentation will allow you to do. If you want to establish a culture of growth and optimization, you must also establish a culture of documentation. Okay, you must establish that culture of documentation and use the reporting, and use the documentation as an excuse to celebrate, okay? Use it as an excuse to celebrate. Now I don't know if you guys, you know who are here, you know watching at home, if you do all-hands meetings, I really love a weekly all-hands meeting. We've found it's one of the most valuable things we do, again, just to encourage communication. But, it's also just a great way to celebrate, right? And so to have the growth lead present, and do some essential show-and-tell. Show-and-tell. Here's what we did, here's ...
what we've been up to. Right, allow those teams to show the work that they're doing. That's really what all-hands meetings should be. Your product team should be doing show-and-tell on, you know, some new upgrades and things that they've made so that people can clap for them, and your growth team should be there showing, and telling some of the tests that they've run. And they should be thanking all the people who helped get those projects built, so that the tests could be run. And then, win or lose, win, lose, or draw, frankly, you celebrate the win. Because, win is also learn, if you learned something, it was a win. If you learned something, it was a win. That was ultimately the way that I was able to be okay, because it used to be celebrate the losses. My team made me change and celebrate the wins, and the only way that I was able to rationalize in my head, and what I still say to people is, as long as we learn, it's a win. Even if the result isn't what we expected, even if the result isn't what we wanted, we win. And, I say that, what I just said to you there, I've said from stage probably 20 times at our office. Reminding our team, right? As long as we know why we did something, and I can speak to the hypothesis, as long as decisions were made, and we're owning those results. As long as we're learning from it, which we're doing at this very moment, and we document, share the knowledge, which is exactly what's happening at this moment as well, it was a win. Moving toward our goal of being a bigger fish, in a bigger pond. And we celebrate. I mean, we do. We celebrate, we're poppin the cork every single week, win, lose, or draw. And if you want to establish a culture of optimization, if you want to establish a culture of growth, then I highly recommend that you do the same thing. Remind your team that they need to be pursuing growth, and learning every day, that they need to document, and they need to be sharing their knowledge, and model that. Model that publicly at your all-hands meetings. Give them an opportunity to brag, and God dang-it, clap. Clap for each other. We so rarely get clapped for, in this day and age, and this is not me, by the way, suggesting to anybody, to clap here. I know we're not doing that thing. But, for your team, clap for them. Alright, clap for them. Clap for their efforts, clap for the fact that they allowed your company to grow, and to get a little bit better. And if you do that, then you'll absolutely, positively be able to establish that culture of growth and optimization.
So, more of a technical question, when you were discussing the difference between monthly planning meeting, and the weekly check-in, right, the weekly check-in has two new concepts. Which is, the project status report, and the task status report. So, what's the difference between them? And also, how does this relate to the growth idea sheet that you run monthly, I assume?
Absolutely, yep, so we talked about... So going back here, we talked about the types of growth meetings, meaning that, yeah, what you said, the monthly planning meeting, and then the weekly check-in, okay? So I think we're pretty clear on, you're pretty, everything's clear on the monthly planning meeting, is that correct? It was when we got to, yeah, so that's gonna be the formal report, going into these, it was when we were talking about the weekly, and I talked about the open projects status report? Yeah, so, we call these open projects, but really, a better way to put this would be builds. So, if you recall, going back to the testing process, you know you have to hypothesize, right? And then, you know, we're gonna actually build the thing. I didn't spend a lot of time talking about the act of building out the test, because it just completely varies. A build could be, alright, we're just gonna change the headline, on this page over here, and the build is two seconds of somebody going tap, tap, tap, post, right? That could be a "build," you know, to do a test, you know, they're gonna duplicate it, tweak something. Or a build could be, we literally need to build a new product to test. We need to role out, you know, going back to the podcast example, right, you know, the build that would be associated with launching a podcast is significant. So, we talk about the open project status report, think about that, you know, more in terms of open builds. What build do we still have open? Because as soon as something, you know, as soon as a build, or a project is completed, then it can move into the testing phase, okay? Build is completed, then it moves into the test phase. We build, then we test, these... We don't use any special documentation for these two things, they're generally tracked, and kept up to date on the growth idea sheet that you have. You know, the growth ideas sheet has the status area, where, you know, for the build it talks about, is it in progress, kinda what's the status, you know, there. But, as a company, your organization likely has some type of, you know, project reporting. But, again, it varies so wildly. Where a particular build, or a particular project, again, using those two terms synonymously, could be something that takes five minutes, or it could be something that takes five months, alright? Now, when we get into the test, and what's happening here, this is literally, we do this on a white board. I'm not saying that you couldn't create a separate Excel spreadsheet for it, you could create another tab for it. You could, kind of build this into, you know, build this into the growth ideas sheet where it has the status when you, you know, move out of build phase and into test. Where you could, you know, keep an ongoing running list. But like, every test is gonna have a beginning, and it's gonna have an end. You don't necessarily need to document what happened, you know, during the test, it's just important to update. So, we gather everybody in a room, with all the different tests that we're working on, the names are written on a white board, and it's just, here's what's happening, here's what's happening, here's what's happening there. Any question? Okay, good. Let's get out. Now, at the end of the test, you know, when the test is over, now that's when we're going to document on the growth idea sheet, what was that result, okay? So that's why we don't have any particular documentation for these two things. Although, you could add them to the idea sheet if you wanted to, and yeah, just to be clear, when we say open project status report, that's really getting back to, you know, the open build, so we had focus, analyze, brainstorm, you know, when we get into this test phase, that's when we got into, you know, making sure that we're gonna have a hypothesis, and then we're gonna actually get into a build. So that was, that was that process. Did that answer your question?
Yes, thank you.