The Pros and Cons of Community Reporting to Product

[music]

[00:00:04] Announcer: You’re listening to Community Signal, the podcast for online community professionals. Tweet with @communitysignal as you listen. Here’s your host, Patrick O’Keefe.

[00:00:21] Patrick O’Keefe: Hello, and welcome to the show. At CNN, I was a member of the product team and I loved it. Danielle Maveal, an experienced community pro, loves being a part of product teams too. We’re going to talk about the pros and cons of reporting into product on this episode of the show.

Thank you to our Patreon supporters, including Maggie McGarry, Carol Benovic-Bradley, and Paul Bradley. If you like to learn more, please visit communitysignal.com/innercircle.

Danielle Maveal is a serial founding team member. She’s been building community at Etsy, Airbnb, and Lyft for 15 years. She’s the chief community officer at Burb, a messaging, automation, and CRM toolset for community builders. Danielle also coaches community professionals and runs multiple support groups for community builders.

Danielle, welcome back to the show.

[00:01:04] Danielle Maveal: Hey, good to be back.

[00:24:44] Patrick O’Keefe: It’s good to have you back. We are people who have both spent time on product teams as community pros and it’s something that I recently had the opportunity to do at CNN. Really enjoyed it, really thought it added to my community experience, and it just fit. We’ve had some conversations off-air about the merging of community and product or kind of working at the intersection of community and product and how it can be to be a community professional on a product team.

Some community pros report up into marketing, some report up into operations, some report into, goodness, I’ve heard the CTO before, I’ve heard IT, so many departments, but product is another option. From the perspective of an experienced community pro, I want to talk about the pros and cons of being on the product team and reporting to a product head. Let’s start with the pros. When I say that, what pros come to mind?

[00:01:58] Danielle Maveal: I think that we understand each other in one crucial way and that’s we’re very user-centric. We care about what the user is experiencing. I don’t say that as like, “Oh, we’re so good-hearted. We’re so good-natured.” [chuckles]

[00:02:16] Patrick O’Keefe: We’re the only ones who understand what a user wants.

[00:02:17] Danielle Maveal: That’s just our job, to deeply understand what the user wants and what their motivations are, and how to get them from point A to point B. I think that’s the biggest pro.

[00:02:29] Patrick O’Keefe: How do you think product leaders are sometimes better equipped to have a community pro reporting to them than say, I don’t know, marketing or some other department?

I’ll talk a little bit about my experience. For me, at CNN, when I joined the product team, I hadn’t been a part of a product team before. If someone asked me yesterday, they were like, “What did you learn when you were on the product team at CNN?” In some ways, I feel like I was robbed because I feel like it was cut short because of the closure of CNN+.

What came to mind right away is like so many little things. The fact that it felt like my ethos as a community pro, how I view problems, how I document them, how I attack a problem, how I talk about community issues and iterating on ideas and features, just my career to date doing this work seemed to fit really well. I don’t know if that was just a consequence of the people who worked in the product team and us being really compatible, but the thinking that I had about community building and how you should approach those things, it just seemed to fit. It seemed to click. I don’t know if that makes any sense to you.

[00:03:34] Danielle Maveal: Yes, I’d say similarly, that happened to me. I was on the product team at Lyft and had just implemented these committees. We would team up product, engineering, data science, legal. Whoever on the team was interested in a gnarly problem, we would pair them up with community leaders who were also interested in that gnarly problem.

They would meet week over week to not only get to the root of the problem like how it’s impacting the user, we would share with the community leader what was happening on the side of the product and the company, but also building bonds. As you meet every other week over a series, you start to build bonds between the people who work at the company and the people who are using the product.

That was cut short. I was laid off at Lyft when COVID started and they had that giant layoff. I’ve been there in seeing something work really well and having it not been done before and me learning a lot from it and me figuring out how product and community can really play nice together, finally. I feel like I had tried a bunch of things that worked well, but not this well. I’m kind of hurt from that because that was cut short.

[00:04:43] Patrick O’Keefe: It does. [chuckles] It does from recent experience. Just for context for folks. At Lyft, you were on product. What are other departments that you’ve been on before?

[00:04:53] Danielle Maveal: I’ve been on customer service, I’ve been on marketing, and then a pillar, so our own vertical at Airbnb and at Burb, I’m building community as its own vertical as well.

[00:05:08] Patrick O’Keefe: Got you. I’ll just say for people like at CNN, I was on product. My past job, I guess, it was a smaller org. I guess I would say I was under ops technically speaking, which was a big department because of how it rolled up and it was like member success… what was not dev and not sales [chuckles] was ops, so events and customer service and all that stuff is under ops supposedly under a very community-savvy person. I say this just to contrast our experiences and talk about why we feel that product– we’re still talking about pros, why it was better than some of our past experiences and departments we had been under. I guess in my case, the boss I had toward the end of my time at CNN, he didn’t have past community experience. He worked on social products and had that experience, which is valuable and relevant and informs him and his perspective, but he was also very inquisitive about community work.

I feel like he had a good grasp of understanding where our expertises were balanced. I don’t know. Again, was it the unique people we had at CNN or just this is more common in product folks? He didn’t seem threatened by community or the things that make community unique. It didn’t seem like it was a threat to what he was trying to accomplish with the product team where, in other cases, I could see how… we’re going to talk about some incompatibilities between product and community in a bit, but marketing in my view has a goal, right?

It has some goals around acquisition and those goals don’t always speak to community’s goals. The tagline for this show is literally, “Marketing brings you new customers. Community helps you keep them.” One of our tag lines is that it’s very much retention and building relationships longer-term. I want to shut up for a second here. Just looking at some of the other departments that you’ve worked under, you mentioned marketing, customer service. Do you feel that product is sometimes more of an opportunity for our community pro to flourish? If so, why?

[00:07:02] Danielle Maveal: Yes, I think as close as you can get the customer to the people building the product, the better. The nice thing is that the product team is now going to have access to, not only research but to community conversations, so conversations between users about their problems, about the product. If you can connect those two really well, it’s just better for all the users, not only the community members who also happen to be users, so I really like that connection between product and community. I’m with you. I’ve heard you say this before.

It really depends on leadership because the structures don’t always work for a community team. Sometimes product teams are very much into launching features. They have a certain number of features that they launch and then feature usage. Community is a lot of repetitive tasks or maintenance. These things are important. It’s hard to fit under almost any team actually because we do have this kind of work where mostly, especially in tech, everyone’s trying to launch something and get awesome feedback on it. That’s not always the case in community.

[00:08:05] Patrick O’Keefe: You’ve given us a good segue to cons.

[00:08:08] Danielle Maveal: [laughs]

[00:08:08] Patrick O’Keefe: Let’s get into cons. Talk about that one a little more in particular. You told me about this the other day. Danielle and I had coffee the other day. It was about how we have these routine actions that we take in community, these repetitive actions that we continually do as we build a community, as we maintain that community. You mentioned the structure or product team versus how that meshes with community. Talk about that.

[00:08:31] Danielle Maveal: The problem that I’ve had there is having community work live under the same OKRs or goals as a product team or a marketing team. Customer service is a bit of a better fit in this way. They’re just very used to all the sub-teams under this umbrella to document projects the same way, to document progress in the same way. It just really doesn’t always fit well with community.

The other con is that you’re also going to have to educate people on what community actually is. I’m sure you’ve covered that a lot in this podcast. [laughs] You’re doing that and then you’re also needing to educate people on like, what does progress look like? What does it look like for a community project versus a product feature? You’re doing a lot of that extra labor, which we all seem to do in these roles anyway. That’s just stuff you have to continually do.

[00:09:26] Patrick O’Keefe: For those who are unfamiliar with product teams, which I think is a lot of folks listening, can you talk a little bit more about that documenting a product team seeks out? What is that MO? Paint the picture of how that’s maybe not compatible with the work that you and I usually do on a day-to-day basis.

[00:09:42] Danielle Maveal: It can range a bit depending on the organization, but a product team will figure out what features should be built next and then watch those features get built. Make sure that they get built, make sure that they’re launched on time. Probably have a hand in how the communication works with the user, making sure that that new feature has support. They’ll just go through that whole life cycle of a new feature.

They’ll create a roadmap that they’re the people who are deciding what’s going to happen with– I’m talking mainly about tech companies. Although I will say some product teams are just responsible for not the ideas, they might have someone else in the company that is like the founder who might be like, “No, I’m just going to tell you what to do and you make sure that this product gets launched.”

That’s basically what they do and then, mainly, they will work in sprints. “Here’s the three things we’re going to build in the next six weeks. Go and do it and launch it.” A lot of times, I guess I can throw a con in here as I’m talking about it, you really have to understand how things work and what that cycle is, and then you really have to know where and when you can inject yourself into these conversations to make sure that your community has a voice.

[00:10:58] Patrick O’Keefe: Yes, and just to add to that, I think at CNN and I’m sure this is pretty common elsewhere, I think a lot of us are used to having engineering resources available to the company in some way, and then those resources either being overtaxed or not available to us or just a mystery of how to tap into those resources. One of the roles that a product team can play and often does, I think, and did at CNN and being the direct line to the engineers and then being the funnel through which the ideas from other departments came in.

I obviously was concerned with the interaction aspects of CNN+’s Interview Club and the moderation tools behind the scenes and how those worked. Me and my team would certainly have ideas around how those features could work, but those ideas, especially at something like Lyft, Airbnb, CNN, are not just one person saying, “We build this,” and then it just happens. That brings together different teams. It brings together research as you mentioned. It brings together design. It brings together engineering. Sometimes it brings together stakeholders who might be using those tools. If you have a user management team when you’re touching login, it might bring in the user management team. If you want to ban people from a product at a company like this, you might deal with a user management team or some sort of team that just deals with accounts, which most people might not be familiar with if they’ve worked at smaller orgs, but a big org happens.

Product is that funnel that brings together all the stakeholders, writes how the feature could be developed, what is needed to develop it, communicates with engineering, understands where the availability is, what the priorities are, when things can get built, and then helps to communicate that clearly to all the stakeholders. It is a lot of documentation. In a sense, it’s its own repetitive process.

Once you have a really good product process, then it will duplicate that over and over again with each idea more or less everything from, I would submit a brief for updating our community guidelines. [chuckles] I would submit for updating this text on this website because someone on the end had to do it at that stage we were at. Yes, I think that’s some insight into the product process again from someone who is admittedly fairly new to that.

[00:13:04] Danielle Maveal: Right, good additions.

[00:13:06] Patrick O’Keefe: Let’s just assume that’s a process. When you’re talking about the work community does, well, I’ll just give an easy example. Approving questions and rejecting questions that come in in these submissions and applying community guidelines. It can break down if the product leadership that you report into doesn’t understand the problem you’re facing and expects you to conform exactly to the processes or processes like what we’ve described instead of building your own processes and documenting them because you can document things in a way that makes sense.

To your point, a lot of the stuff we do isn’t building a new feature. It’s not updating anything. It’s simply taking some sort of action against a member. Thankfully, I didn’t have this problem, but it sounds like you’ve maybe encountered it. I don’t know. I haven’t had to do with people who wanted me to put that into a rigid product process. Just having good documentation and explaining how it worked was enough.

[00:14:02] Danielle Maveal: Yes, that’s something that I’m actually pretty good at. When I worked at Airbnb, I worked in New York and my team was in LA. I would come in once a month and I would make sure that I was physically in every meeting that I could with that, including the product team. It was not part of my job. My manager walked past me once while I was in one of these meetings and looked at me and was like, “What are you doing in there?” [chuckles]

I love figuring out what that process is and how to plug in. I think not enough people on your team might do that. If you take that extra time to really figure that out and figure out how you can play along, that can do wonders for the community and for the features and tweaks that you need to do your job well.

[00:14:49] Patrick O’Keefe: You mentioned OKRs, “objectives and key results” for anyone not familiar. I think what’s interesting about product in a lot of cases and ties into what you said earlier about, we care about what the user thinks or what the user wants is that products’ goals– I’m sure there are product teams where revenue is a constant measure of success in some way or another, right? We changed the product there for X.

Ultimately, I think my experience in product teams, limited experience, was around successful adoption of features of the product returning to the product. Do people use it? Do people want it? Does this matter? Surveys, research, split tests, data. It wasn’t like, yes, all those things tie into revenue down line, where if we have engaged product people are returning, then they’ll return as subscribers and continue to generate revenue, but it’s a step or two removed from that.

That’s a fun area where community often can thrive is if we build this community product and you’re looking for successful adoption of the product, then we know what successful adoption of our community looks like and how we want people to ideally use it. Then we can measure it and make changes based upon what the data shows and that, I think, can be a much more friendly area. I realize I put this in the context. I don’t know why I’m talking about this, but the opposite is that it’s not the case and things are busted. I think that that OKR structure can actually be a more friendly place for community builders to play.

[00:16:16] Danielle Maveal: Yes, absolutely, and that’s a big benefit that the product team can see is that you can give them feedback around usage. When they go to report on a feature that they’ve launched, they can say, “Oh, so many people did click the button.” You can give them this extra layer of data that’s all around the stories, what people are saying, quotes. You could even have them talk to the community and record feedback that way. You can show the product team the benefits of working with you in that way can help both sides.

[00:16:52] Patrick O’Keefe: Yes, and just talking about the result a little bit more is like if you have an agreed-upon result of what you want, it’s not always 3.7% increase in whatever. A key result can be our interviews have productive questions and it’s a safe place for people. If you have a product lead who really understands that you’re here to create X, Y, and Z within the product and you can do those things and accomplish those as a community pro, then, ideally, that product person, especially if you’re experienced like we are, they shouldn’t nitpick the process, right? It’s the result.

I have the experience of what it is to build healthy, successful online communities. Let’s agree on the result we want and then trust me to get there. That was what I found at CNN. It was like we had an interview with Dr. Fauci. It went great. Bad actors follow Fauci around everywhere online. People tried things. Certainly, people tested us. Ultimately, the process for which we designed moderation and how we review content was successful. It was a great interview. It was excellent to see Dr. Fauci mention the names of our members. It was amazing. Because the result was successful, then the process can be trusted. If it had gone a different way, if the interview had been littered with problems, if we had let things slip in, then I think a product lead would have justifiable means to question the process and ask me what I’m doing.

There’s something there about agreeing to a result and then trust in the community pro to get it done, because having community in your product team is an opportunity for product leaders too to increase their mandate and increase their influence, right? It’s not just one way. It’s not just community influencing product. It’s increasing the influence of product within the wider org too.

[00:18:29] Danielle Maveal: Yes, absolutely.

[00:18:32] Patrick O’Keefe: I think where we’re going is talking about being good partners, being a good product team member and partner on our end, and, of course, the product and for someone who’s new to a community team or community folks. What does that mean to you, to be a good member of a product team, to be a good partner on a product team?

[00:18:50] Danielle Maveal: I did talk about understanding their process, understanding their motivation and goals, and plugging in there where you can. You would be surprised. One of those big names that I worked for had no consistent process for launching a product. I think it’s actually okay if you’re good at this stuff to come up with your own way of plugging into product and telling them, “Hey, I meet with you once a month and this is what we cover and this is why it’s beneficial for you. This is why it’s beneficial for me,” and if you have a lot of people coming to you to build a process, so not letting the other people who you think maybe are better at this create processes. If you’re good at it, do it yourself or even if you’re not good at it. You just think it needs to be done. Show that you also have chops in this area. That’s helped me a ton.

[00:19:42] Patrick O’Keefe: Yes, and if you’re on a product team as a community builder, you’re having meetings more frequently with those folks. You’re spending more time with them. I loved our product team members at CNN and I really enjoyed working with them. Something we had talked about the other day was, and you touched on it here, learning the way they talk, the tools they use, their priorities, the way they work. I think you described it as empathy and understanding for what they’re doing, understanding what they may need.

I think that’s important and it’s important both ways. One of the things that I feel needs to happen for community within product or this is for community within any team to be successful, but community within product for the sake of the show is that the traditional product folks and the traditional community folks who are now blending their experiences together need to have respect for the expertise that they each have and where those soft lines are and asking questions, being inquisitive, wondering about things, asking why is good, but then also not respecting what someone else knows. Dictating to me how moderation should work or me dictating to you how a product brief should be written. I can offer feedback. I can ask questions. Ultimately, if I don’t trust the product team members that I am also a part of, but if they don’t trust the community folks that are part of that team, either way if that trust breaks down, it’s just not going to be a good process.

[00:20:56] Danielle Maveal: I can tell you where that trust has broken down for me in the past and where I’ve seen it with other people that I’ve coached is you are so emotional about the community, the user, and the experience that they’re having, especially if it’s part of their livelihood and this feature is broken, or it just needs to be tweaked and it’s really causing a stir in your community.

You go to the product team, you go to engineers, and you’re like, “This is broken. It needs to be fixed or this needs to be built. Everyone’s demanding this.” That’s exactly how you get trust broken because it’s just not the way things work. Things are put on a roadmap and they’re prioritized, not only based on what users are saying but the company goals and the company’s objectives.

Honestly, I think all of us have done it because we get into this job because we’re empathetic people. We want to make sure our community is well-served, but that’s just really how trust starts to break down is like I know I did that at Etsy a ton because I was just so passionate. I was an Etsy seller before I even joined the company. I would just roll in like a bat out of hell telling everyone what needed to be done. Nobody wanted to talk to me by the end of it.

That’s just like a warning for people out there. The way I discover, the way you should do it, right? What product and engineers want are problems that need to be fixed. They don’t need the solution. That’s like someone coming to you telling you, “Hey, here’s the outcome we need to see from the community and here’s exactly how you’re going to do it.” You would say, “I’m the expert here. Why are you telling me how to get that done?”

It’s really important to bring problems, bring as much data as you can, make partners with other teams who are also getting this feedback and data like customer service or trust and safety, things like that. Have as much support as you can around this problem. You can even tell stories from the community about this problem, but just don’t barge in with the solution that the community wants because it’s never going to get people on your side. It’s not going to motivate them to want to work on that project.

[00:23:02] Patrick O’Keefe: I think that can vary within product teams when it comes to community. You might be a key stakeholder if you’re a leader on the community team. You might be someone whose opinion matters, but still, the ideas have to be put through the paces and you don’t want to be the person who cries wolf. You just admitted to doing this. I’m guilty of it too, I’m sure, in the past. You want an emergency to actually be an emergency for it to hit the right way and to be prioritized the right way.

If every problem you have is an emergency, requires that tone from you, then something’s not right because half of your issues, half of your tickets, half of your briefs, half of your whatever should not be emergencies. An emergency is something that it’s a true blocker. It stops you from doing your job right now. Again, if you’re a moderator and you’re moderating things, if you can’t approve and reject things, that’s a blocker. That’s an emergency. We need to get that sorted now.

Just because you would like, say, a third column on the page to sort your submissions into, that’s not an emergency. That’s something that can be built and go through the process. It’s like even on the best product teams with the nicest people who will be so kind and respectful to people coming in from all other places. Because, ultimately, if you’re on the product team, you’re probably empathetic. You are the product team. You’re part of that team and you’re empathetic with the people on it. You’re probably not doing this once you’ve been around the block a few times, but you’re seeing it from other teams all the time. You’re seeing other teams come in and build where they just throw their problem on the table, say, “This is an emergency. It needs to be fixed.” It’s just not a good partnership. Ultimately, even though the product team might be kind and the engineering team might be kind, acknowledge it respectfully, they’ll come up with their own perspective on how much of a priority your “priorities” actually are.

[00:24:46] Danielle Maveal: That can be really hard to swallow, especially if your community is in an uproar. It’s part of your job to figure it out. Even if somebody comes back and say, “We cannot fix this. We cannot change this right now,” it’s part of your job to figure out, I’m not saying you have to talk to the community on behalf of product. Maybe it’s your job to figure out how product and community can talk together.

I’ve seen it happen where I’ve thought something is a huge deal in my community. It keeps coming up. Fires are burning. People are fighting. People are upset. If I really take a bird’s eye view, no one’s writing into support about it. Users are using the feature. There’s no bad feedback, but something happens in community where you’ve got a few people and you might not even see it. A great community manager with tons and tons of experience will see it, but you might not even see what’s happening that there’s a little community formed [chuckles] that’s making this thing look like an emergency like you said and it’s not always an emergency. Really important to have those partnerships with other teams, data science, research, customer service, and make sure you have a really bird’s eye view of a story before you go to product or engineering or trust and safety, legal with your requests.

[00:25:59] Patrick O’Keefe: I think the last thing that really comes to mind here from our conversation is just you underscore the need to have an open mind on both sides. I think we’ve talked about that a little bit from the product side. I think one of the things is from the community side, at least how I approached it, was– and, again, I mentioned earlier. I felt like I was robbed because this year, I had really wanted to dig into the product team in a deeper way and really contribute in a more meaningful way to the product side of things. Community-wise, I trust myself. I know what I’m capable of doing.

I get impostor syndrome like anyone else. Ultimately, I’m confident in my abilities. That isn’t how I feel on the product side of things. That’s an area where I can improve and get better. I didn’t have that opportunity this year, but I was inquisitive and I was curious. An easy example of that is just we would write product briefs, which are essentially descriptions of a product, how it should work, why we need it, how we won’t measure the success of it, what the stakeholders are on it, what resource needs to be done, what testing needs to be done, who needs to be brought in, et cetera, everything that goes into building this thing.

We had a great product manager that I had a great partnership with. I love working with them. I would see other teams come in and they would have ideas much to our point a moment ago. He would ask them to submit it through a particular form. It wasn’t a big ask, but they would not do it in a lot of cases. There wasn’t a desire to learn how to do it. Being on the product team myself, I was like, “Okay, here’s the thing.” First of all, he would offer to write my briefs and I’d be like, “No, I don’t want you to do that. I want to write my own briefs.” I am a member of the product team. We’re not separate. I’m on the product team. I should be able to write my own briefs, communicate my own ideas. That’s part of doing the work here and being a good partner. If I’m simply passing off the product-related stuff, whatever the traditional product-related stuff is, off to someone else and not participating in those processes, then am I really committing to the product team in a true form, or am I simply shuffling work off to someone else? I think it’s important if you’re a community pro coming into a product team for the first time like I was to just be genuinely interested in what they’re doing and see how you can take on a little bit of that work, at least when it comes to the things that you’re requesting, that you’re asking for, that you want to bring to the table.

[00:28:08] Danielle Maveal: There’s so much we can learn from a product team like this sneaky, little tip that I tell people that I coach was in there when you were just talking. That’s putting up a bit of a buffer for people who are– especially people who have a ton of teams coming to them wanting access to the community all the time. Ask them to fill out a form.

Most of us are running around just trying to make all these requests happen so that you have good partnerships with people, and then we get overwhelmed and burnt out. These little tricky [chuckles] processes can make sure people are serious and that they’re going to engage and that they’re committed and that they are going to show up, so filling out a form is just such a good idea.

[00:28:48] Patrick O’Keefe: Being closer to product, actually being a part of the product team, can set you up for a better relationship with the folks who ultimately have an important hand in building the thing that you’re working on or building the thing that you’re a part of or building the thing that you are the key person on community products. The community head is the person who’s the lead of that product. Your team has to deal with it as much as anyone else. The tools that are built are tools that your team will have to deal with. They allow you to build a more healthy relationship with product leaders and a closer relationship.

[00:29:22] Danielle Maveal: Yes, I totally agree. Right now, I’m partners, like I’m working- there’s three of us running a startup and the CPO, chief product officer. I’m the chief community officer and we have a chief technology officer, so we’re at similar levels. Drew and I work on the product. He fully trusts me and my experience to build this product. I think all this work that I’ve done gaining trust and learning about product and learning about community, of course, and community principles has been such an interesting partnership.

I feel so much trust, more trust than I’ve ever felt from a leader. I actually feel I’m just at the table with everyone else building this product for community folks. That’s been really cool to have an idea and watch it be turned into product and launched. Just having the trust along the way and learning from each other along the way has been such an amazing experience.

[00:30:16] Patrick O’Keefe: Right, because I think a lot of us can identify with a defensive experience where we see the need for something and maybe there are other considerations, right? The ideas can be refined, but feeling as though we have to go into a call with all the possible scenarios lined up in front of us of all the counters of why this is bad or why it won’t work.

That’s not to say because it’s a fine line between being questioned and wanting people just to agree with you. There’s a separator there, but I’ve been in companies where it felt like I never had a spot in the sprint or I never had room for community to be improved in some way. It was always fighting for a place or it was talking about like, “Oh, we can always prioritize growth. We can always talk about how we can build something that gets us a hundred more people.

That seemed to always come with the cost of refining the community product or refining the administrative features, which don’t get the attention they deserve in a lot of cases but are important because you’re paying people to sit in front of them. That time can either be productive or it can be not. If you’re never improving the admin side, you’re just paying people to spin their wheels in a lot of cases. It’s nice to have relationships where you don’t have to feel that way always, where you don’t always have to feel defensive or on guard, right?

[00:31:36] Danielle Maveal: Yes, it’s such a shame because I think when you’re spending a lot of your energy and time and mind thinking up all those defensive points and the defensive positions and backing up everything you say, there’s little room to come to the table with someone and actually dream up something better. Usually, you’re just defending like the bare minimum. If you can build that trust and if you have a team that will trust you and work together to build that trust, you can use that time to be creative, right? Go leaps forward versus like, “Ugh, we just need to maintain the status quo, so I need to fight for this one little thing.”

[00:32:16] Patrick O’Keefe: Ultimately, I think that being on a product team can make, with some exceptions, you a better community person, a broader community person. I think a lot of the processes like you’ve mentioned, speak well to our work, can help us think of things in a different way. Hopefully, we’ve painted that picture today. Thank you so much for spending time with us, Danielle. I really appreciate you taking the time to chat and share your experience.

[00:32:37] Danielle Maveal: Thanks for having me, Patrick. I’ll come back any time.

[00:32:41] Patrick O’Keefe: We’ve been talking with Danielle Maveal, chief community officer at Burb. Visit Burb at burb.co.

For the transcript from this episode plus highlights and links that we mentioned, please visit communitysignal.com. Community Signal is produced by Karn Broad and Carol Benovic-Bradley is our editorial lead. Until next time.

[music]