How we align our customer success and product teams to solve customer issues

Rian: 00:06 I think that a lot of success teams just stop doing the work of informing the other teams of what's happening because nothing happens, because the Product Team or whatever team might read the thing and say, "This is great," but then the report will look exactly the same the next month.

Marek: 00:29 Hello, and welcome to Talking Email with Postmark. I'm your host, Marek Loder, and in today's episode, Rian van der Merwe, the product manager for Postmark, and Brian Kerr, a member of the Postmark Customer Success Team, come together to discuss some of the hard work we've done to align our Customer Success and Product Teams to help solve customer issues and make product improvements. In sharing our own experiences, we hope that you'll come away with some ideas on how you might be able to improve the alignment between your Customer Success and Product Teams. Hope you enjoy the episode.

Marek: 01:03 Thanks for joining me today, guys.

Rian: 01:05 Hey, Marek. Nice to be here.

Brian: 01:06 Hey, Marek. How's it going?

Marek: 01:09 I'd like to just get started with some quick intros. Brian, you've been in customer success for the better part of your career. Can you tell us about your path to customer success and how you ultimately ended up at Wildbit?

Brian: 01:23 Yeah, I think probably like a lot of people, I kind of fell into customer success and customer support. I started my career working at a large bank in their internal IT department, working on their own support, so kind of a phone bank, average handle time type of situation. I enjoyed it, but I didn't really enjoy the exact situation I was in. Over time, I started looking into more of startups and that type of thing and ended up joining a startup that raised 8 million in funding. I worked there in their support department for a while and was enjoying it, but then somehow... I don't even really remember how now at this point, but Wildbit out onto my radar, and I saw a job posting for customer support. I really just fell in love with the company culture and applied and kind of ended up here. That's kind of my quick path to Wildbit.

Marek: 02:13 We're certainly lucky to have you on the team. Rian, you've worked in various roles, focused on user experience design and research, product management in companies all over the world. Can you tell us about your winding and exciting path to product management and ultimately how you ended up getting connected with Wildbit?

Rian: 02:34 Yeah, it's certainly a bit of a long path. I was born and raised in South Africa, studied there, and then moved to Australia to keep studying. Then I met a girl, and this girl was an American, so I followed her here, which sounds way creepier than it was because we ended up getting married. I think it's all okay now. But yeah, we lived in the Bay Area for a long time. I worked at eBay for awhile. Then we wanted to move back to South Africa, so I felt like I wanted to move into product. There wasn't much to learn about product at that point. I read some Wikipedia articles and bought a couple of books and faked my way into my first product manager role.

Rian: 03:16 Here we are, 12 years later, still trying to fake my way into it, but hopefully having learned a few things along the way. I learned about Wildbit through someone who works here, Chris Bowler. We've been internet friends for a long time. He reached out when he saw the posting. We always talk when we talk to each other, "Everyone has their Natalie moment," and it's when they have that first call with her and they're like, "Yeah, this isn't just a casual conversation. I really want this job." I had my Natalie moment as well, and I've been here for over three years. It's been great.

Marek: 03:56 Wildbit is certainly a special place, and I'm fortunate to be working with both of you guys. Really, I'd like to begin our conversation by painting a picture of the roles and responsibilities of both the customer success and product management teams at Postmark. Brian, do you want to tell us a little bit about what customer success looks like at Postmark and the overall responsibilities of that team?

Brian: 04:22 Yeah. The Customer Success Team here at Postmark works on two primary activities, and that's proactive work and reactive work. Reactive work is your traditional support, so we're working on an inbox queue, doing live chats, and sometimes we'll even do phone calls with customers if that's how they want to be contacted. Then the proactive work is more what's kind of considered traditional customer success work. I guess a lot of things fall under that umbrella, but that's reaching out to customers after they've signed up to see if they're having any issues or answering any questions that they might have told us when signing up, general education, so best practices on how to send email, and that's through things like guides or webinars, and then we just also do functions to reduce the support that's coming in. That's kind of like the silent hand that customers don't necessarily see, but that's work to reduce support before it even happens.

Marek: 05:20 It sounds like you guys have a number of different responsibilities on the CS Team.

Brian: 05:26 Yeah. It's all over the place.

Marek: 05:28 More broadly, what would you say are some of the top-level goals of the CS Team as a whole?

Brian: 05:35 Yeah, so we have four goals as a team, and the first one is reliable availability. That's to be available for our customers when they want us to be available. That's through phone, email, or live chat primarily. Then the next goal is to provide a personalized, hands-on onboarding experience for our customers. All of our customers have unique needs. If they reach out to us with a question, we want to make sure that's tailored to their exact needs. The next is to focus on continuing education and feature awareness. That's making sure that we are teaching our customers about any new features that we release or just continuing to teach them best practices. Then finally is empowering our customers to help them through self-service. For those times that we aren't available via email, if somebody who's working at midnight or something like that, and we're not around, we want our self-service to be really solid so that they can get the answers to the questions that they might have.

Marek: 06:28 Perfect. Across the board there, the customer certainly is at the center of all of the work that you guys are doing on the Success Team.

Brian: 06:38 Most definitely.

Marek: 06:39 Yeah. Rian, do you want to just give us a quick synopsis of what the Product Team looks like at Postmark and kind of what your role as product manager is all about?

Rian: 06:48 Sure. Yeah. Our Product Team has two designers and then three or four developers and then honorary support members. Brian is helping us on a lot of stuff right now. It kind of depends on who on that team has availability and interest, based on the projects that they're working on. But my role has basically three focus areas. I think the first and most important one is actually team happiness and efficiency, which is very different from other places where I've worked, how to make sure that our team is working on the stuff that they want to be working on that is also useful to the business, "How do we improve our processes? How do we have processes and not just for processes' sake?" But I always liked that quote, "Engineers don't hate process. They hate process that can't defend itself."

Rian: 07:39 We need to have defensible processes. That's what we're aiming for. The second part is very much focused on customers. I do regular customer calls, usability testing, all kinds of different things there, and then I'm also responsible for customer outreach. I write our newsletters. I do less of it now since... But I used to do quite a bit of support. But I try to still be involved in that because it's such a great front line to that, and then try to be up-to-date on the industry news and things like that. The third area is what I would just call product, so that's what most product managers, I think, spend most of their time on, that's the strategy and the planning and the execution and the marketing of products. The day-to-day grind of product management is still a big part of my day, but I think it's a little bit smaller than at other companies because I also spend way more time on team and customer staff than maybe in other places.

Marek: 08:36 It sounds like similar to the Customer Success Team, that you are responsible for quite a lot across Postmark. Both of you, it sounds like, a common theme is this overall concept of improving customer experience and really asking what teams can be doing to help customers achieve success. Would you guys agree that that's a fair statement?

Rian: 08:59 Yeah, I would definitely agree with that. I think the important part for us is also to realize that we want to continue to stay profitable, and we want to continue to grow our business as well. We believe the best way to do that is to make sure the team is happy, and by working on stuff, it's also making customers happy. I always think about a great success metric for us would be our customers pay us without complaining about it. Customers who want to pay us, right? Because sometimes we see these tweets of people saying, "Postmark is one of the few services I don't mind paying for." I really love seeing that because it means that you provide an actual value, and then at the same time, you're doing it in a way that doesn't make a customer feel exploited or feel that they are held hostage. We're kind of in the center of those two things.

Marek: 09:50 Cool, so happy customers willing to pay us without complaining. Obviously, you guys on the Customer Success and Product Teams are both working to help shape the customer experience, but you guys are coming at it from very different angles with very different day-to-day responsibilities. I'd like to spend the majority of our time together exploring where those responsibilities overlap, where they diverge, and, really, where we've found opportunities for collaboration to exist between the two teams to generally improve the customer experience. Perhaps we can start with just the simple act of gathering customer feedback. Brian, can you tell us about some of the ways that the Customer Success Team collects customer feedback at Postmark?

Brian: 10:38 Yeah. I guess the two kind of traditional ways are through surveys. We have CSAT surveys that just measure how a support interaction was. That's always just good just to check in to make sure that score is nice and high as it should be and there's no red flags there. For new customers that sign up, we also send them a survey, I think it's 60 days after they have started paying and become active, asking how they would feel if they could no longer use Postmark. This is maybe a little bit different than some organizations that might use NPS or a CES score or something like that, where we're asking the customer, "If you could no longer use Postmark tomorrow, how would you feel?" We give them three options of very disappointed, somewhat disappointed, and not disappointed. The point of that survey is to check to make sure that when a customer signs up for Postmark and they become active if we're meeting the job that they are hiring Postmark to do and making sure it's useful for them.

Brian: 11:35 Then kind of the third piece of feedback that we kind of collect, and I think we're going to dive into this more here in a little bit, is just looking at every support conversation we receive and starting to tag that and turn that into information that we can use to kind of figure out what customers are saying to us. Because if you're in the support inbox and you receive the same type of question four times in a row, it might seem like, "Oh my gosh. This is a big deal. But if there's hundreds of conversations that have come in in the day and those are the only four times it's happened, it's maybe not that big of a deal. It's looking at all the support that's coming in and trying to make that useful data.

Marek: 12:14 I certainly would like for us to dive into some of those in a bit more detail, but Rian, I want to give you a chance to share something, if there are any additional ways that the Product Team is also going about collecting customer feedback.

Rian: 12:27 Yeah. I think the big thing here is that once... I almost see the CS Team as this incredible filter of helping us figure out, "What are the actual important things that have to come through the team?" Once something seems like either an issue or a feature request that seems like it solves a real problem, that comes through to me and the Product Team through a tool called Productboard that we use to prioritize some of this stuff. When it comes in, it doesn't mean we'll immediately work on it. I'll probably come back to this a lot, but we're a small team so we can take on a bunch of stuff. We don't rely on a massive backlog. We know that there are only a set number of things that we can work on, so we try to work on the most important things that are coming next, and there's no 100 issue backlog for us to go through.

Rian: 13:21 What we do instead is as these conversations come in, as Brian said, we tag them, we will link them to feature requests or to bugs, and I know that once something is becoming an actual issue, that will bubble up, and then we can address it at that point. Then we also just, and like I mentioned earlier, do a bunch of customer calls, either proactive and through people who have a link that they just want to talk to me about stuff or through organized usability testing or interviews that we do with our customers.

Marek: 13:54 Again, it sounds like, frankly, across both teams there are a number of different channels by which we're gathering and collecting this customer feedback. For the sake of this conversation, what I'd like to do is actually talk a little bit about some of the work that we've done recently with respect to tagging and prioritizing customer support requests. Brian, earlier this year you created a reporting taxonomy to help our team and, perhaps more broadly, our company begin to track and understand trends and conversations with our customers on the front lines. Can you tell us about this project, Brian?

Brian: 14:35 Yeah. What we did this year, and this is kind of a cool thing that we started doing overall this year on the Postmark team, is we're kind of treating the Postmark team like part of the Product Team. What we're doing is every three months our Product Team meets, and they decide what they're going to work on for the next three months. The Customer Success Team does that as well. That's really great because it time boxes the work that we're going to do, and it makes it really focused. We can also take a look at our four goals that I mentioned earlier and make sure that the work that we're doing is working towards that. One of those projects that I took on this year was a tagging taxonomy. That's taking the support requests that we have coming in and assigning tags to them.

Brian: 15:16 The way we went about doing it for the initial version was looking at different parts of the product requests were coming in for. If a conversation came in regarding our API, we'd just simply tag it API, or if somebody had a conversation about sending via SMTP, we would tag it as SMTP. We'd kind of do that for all the different types of questions that come in about Postmark as a product, so that's templates or inbound processing. It's kind of all over the board. What that starts to do is it gives us a baseline of where our support's coming in from so we can start to understand what features are generating the most amount of support, which aren't really generating support. From there, as we're starting to look into now, as we're starting to look into the exact types of conversations, each piece of product is generating, and support requests so that we can kind of understand the type of support as a whole that's coming in.

Marek: 16:08 Tell us a little bit about the approach that you took to develop the tagging structure.

Brian: 16:13 Yeah. I think the biggest thing that I was trying to do when coming up with it is make it broad enough and easy enough that it's not extra work, because tagging nearly every support conversation that you have, if you're doing hundreds a week or something like that, that's a lot of tagging that you're having to do. It's trying to make it broad enough that it's simple enough to just easily quickly do, but also make it focused enough that it is actually generating useful information so that when we'd go on and report on the tags that we're seeing, it's helpful information for Rian and the Product Team to make decisions on the product.

Marek: 16:50 You created this tagging taxonomy. Our team tags support requests. Tell us how we begin to extract useful information from these tags.

Brian: 17:00 We do a report, and it's kind of a manual process. I actually like that it's a manual process. If it was some sort of monthly analytics report that was in some database somewhere that anyone could look at any time, it probably wouldn't get looked at too much just because it's always there and it's not something you always think about. But instead, it's a monthly report that I put together. We use Help Scout as our help desk. I just manually go through and look at the analytics there, I look at how many conversations each tag is coming up with, I kind of clean up the data, and then I start looking into specific tags if there's a lot of support for one.

Brian: 17:38 Maybe if we see that some tag is generating 20 support requests for three months in a row and then it jumps up to 60 or 70 report requests in a month, I dig into it to try and identify, "Was there something that broke? Was there maybe just all of a sudden some industry shift where there's a new feature that people are wanting?" or that type of thing to understand why that's jumping. But then I'm digging into the conversations themselves to get a better idea of the types of support conversations that we're seeing around each specific tag.

Marek: 18:09 Interesting. It sounds like a side effect of it not actually being an automated, neatly buttoned-up tool is that you are actually going through these conversations, especially when you notice a particular trend, to try and understand common themes or things that may be going on or contributing to that particular trend by actually reading through these conversations yourself at the end of the month.

Brian: 18:33 Yep. That's correct.

Marek: 18:34 Okay. These reports sound like they're loaded with information. Let's talk a little bit about how these reports are used by the Product Team. Rian, how do you approach these reports, and what are some of the things that you're doing with them at the end of the month?

Rian: 18:53 Yeah. I think it's probably one of the few Basecamp posts that everyone reads, because it is so useful, and so much interesting information. What's really interesting about it is how we are able to see trends. We're able to see some of the bigger things that we know we need to work on and see how it keeps coming up to just confirm our prioritization there. But then there's also some really fun things, where we're seeing issues that generate a lot of support that have a fairly simple solution and we can quickly work on that.

Rian: 19:28 An example I can think of is we have user names and email addresses, and people sign in with their user names. They sometimes forget their user name and sign in with their email address instead, and then that creates confusion and a lot of support and with that shut up in one of these reports. We just made a couple of simple changes in the UI to if we identify an email address in the signup box, showing them a notice saying, "Your username is probably different than your email, so just think about that." Brian, I don't want to lie, that did help with the support, right? It did?

Brian: 20:02 No. It was something that was maybe coming up, up to 15 times a month if not more. Now it's maybe one or two times a month.

Rian: 20:13 Yeah. There's quite a few examples of those things that just feel like such good momentum, where we always talk about these small annoyances that we want to get rid of, because, again, as a small team, we're focused on these huge things that we want to accomplish. It's so easy for a product team to just not worry about the smaller things, but it's those small improvements that help customers and also give the Success Team more time to work on success tasks and that makes that report really useful. To summarize, I think it does two things. It clarifies our priorities and that we're focusing on the right things in terms of the big things that we're focused on, but it also gives us opportunities to just slowly and methodically create a better experience for our customers and for the Support Team.

Marek: 21:05 So it sounds like these reports have been pretty vital in helping us identify and tackle some, effectively, low-hanging fruits, some things that are just frustrating elements for our customers, and being able to kind of knock them out quickly. I'm also curious to know whether these reports have helped us to identify more broad strategic initiatives.

Rian: 21:31 Yeah. I think it serves as a really good check on our plans as well. That's what I would call the main benefit, because we try to, at the beginning of a year and a quarter, set ourselves business goals and the problems that we want to solve and how we want to meet those goals through meeting customer needs. As we go, knowing that these are the issues that our customers write in about, it serves as just a confirmation that we're doing the right stuff. It helps us with sometimes shifting priorities from one thing to another, because we know that something is becoming more important than something else. As kind of a silly example that I sometimes call my crown achievement at Postmark is we didn't always support emoji in subject lines, and it became this running joke because it's silly. Right?

Rian: 22:30 But also as emoji picked up, it became a thing, and it shifted our priorities at some point because it became such a hassle to not support it in terms of... There are a couple of examples of customers just not even choosing Postmark, just going to a different provider because they couldn't use emoji in subject lines. It sounds silly, but that's an example of how us and the Support Team staying close to each other were able to solve that need. Obviously, that support dropped to zero, but also it doesn't come up anymore, and knowing that it's a problem, I think, has really helped us over time.

Marek: 23:13 Clearly, these reports have filled a really pretty important role for Postmark in terms of keeping the Customer Success Team and that customer feedback top of mind and front and center for you on the Product Team, Rian. Are there other ways that the CS Team and the Product Team at Postmark are able to stay connected beyond these monthly support tagging reports?

Rian: 23:38 Yeah. I think what I would add is kind of related to your question. The other thing I like about this report is that it's not just our team who finds ideas and things to work on. Everyone kind of chimes in on these. For example, maybe a solution is a UI change and an additional help doc. Or I think some webinar ideas or video tutorial ideas came out of these reports, so that it's easier for the Support Team to say, "Hey, go watch this two-minute video, which will help you figure this thing out." I think what I really like about it is that it's kind of a multidisciplinary solution to the things that get brought up there.

Rian: 24:24 Then on a higher level, I think, from our leads team perspective, so Dana, who heads up Customer Support, is we are all responsible for making sure that we're aware of what's happening in our teams, I think. In our planning in our weekly calls with our leads team, that's another really important point. We'll always talk about customer headlines in that call. Then I would certainly then bubble up some of the more important things that happen in Support or that happened in Success, and so that, again, it helps us just confirm our prioritization, and we can look through things based on what that customer input is.

Brian: 25:04 To build on what Rian was talking about there about how it's not just the Product Team's responsibility to kind of build on this, it's not like the purpose of these reports is to drop a 2000-piece Lego kit on the Product Team and say, "Go. Go fix whatever came up this month." It is really for the entire team to understand what types of support's coming in. A good example is there was a situation where support was coming up a lot, and we had to help doc on the article. Not only did somebody on the Product Team step up and right away say, "Hey, I'm going to make a fix to kind of clear up this confusion," when I went to go look at the help doc for that, it was very wordy.

Brian: 25:47 It was kind of hard to understand, even if I knew what the help doc was saying. There's something called a gunning fog index so that you can tell how hard something is to read. It registered a 14.5 or something like that, which means it's super hard to read. The purpose of this report is also for the Success Team to know, "Hey, let's look at all this stuff that's coming in and take that back to what we're doing as well to know if it is rewriting help docs," or something like that. It's a very collaborative thing.

Marek: 26:18 It sounds like it really informs both teams in quite drastic ways as to kind of, "Where are opportunities for us to help improve the customer experience?" whether it be, to your point, the help docs, Brian, the clarity of the document itself, "Is this clear enough? Does this convey what we're trying to have it convey?" all the way through to a potential flaw or bug in the product.

Brian: 26:41 Yeah. Definitely.

Marek: 26:43 I guess one thing that I'd like to explore a little bit is how the collaboration on the CS Team at Postmark and the Product Team at Postmark, how that stacks up to perhaps some other environments that you guys have worked in. Brian, maybe we could start with you?

Brian: 27:00 Yeah. From my past experience at other organizations, sometimes it's very siloed, where there's really not a direct line of communication, where Success could even put up a report that the Product Team would like to read or enjoy to read or look forward to read. There's been walls or silos between the two teams, where maybe a product's shipped and then you just find out about it that day or that week. That's definitely unique to Postmark, which I think helps us be able to kind of have a report like this be successful, where there is that collaborative nature between the teams where we know that we are working together.

Rian: 27:34 Yeah, I would agree with that. I think the two things that I would want to point out that I find is a little different is, one, we try to always have a Success person part of our project as we were working on it so that when there's going to be help docs, there's going to be API doc updates, and, like Brian said, we can't just tell them, "Hey, surprise. This thing is live now. Go figure it out." We want them to be part of that process, right? We want all of those things to be live at the same time or roughly at the same time. I think that that's more on the proactive side. But on the more reactive input side, I think that a lot of success teams just stop doing the work of informing the other teams of what's happening because nothing happens because the Product Team or whatever team might read the thing and say, "This is great," but then the report looks exactly the same the next month.

Rian: 28:32 I think what's different here is because of, I guess, the manual effort in the report that points out, "These are the most important things that are an issue," and then the willingness of the team to just jump in and do stuff to fix it, because we all want to see that problem not show up again next month, and then the satisfaction of having it not show up the next month, that creates, I think, this momentum, where it's like if nothing happens, you can't expect Support to create this report. If things change, then it's a virtuous cycle that's just going to continue to keep going until we don't need a report anymore, I guess, one day.

Brian: 29:13 That'd be nice.

Marek: 29:16 Rian, is there anything that... not to say that this is all the Product Team, but I feel like to some extent, clearly there's been a lot of work that you've done to help lead a product that kind of fosters an environment of openness and sharing. Are there particular things that you focus on or work on to create that kind of an environment?

Rian: 29:40 Yeah. I think this is where the discussion probably drifts more into Wildbit culture in general, which, I don't know if it's a good or a bad thing, but I'll start the answer, and then we'll see if we want to go there or not.

Marek: 29:52 Please. Let's see where it goes.

Rian: 29:54 But the answer to your question is that a really important value for us is that we don't step on each other's toes here. It's not a thing. We don't try to build fiefdoms. We don't try to have ownership over things that no one else can touch. I think that's very different from a lot of organizations, where I don't think anyone here feels the need to build some kind of empire. I succeed when the product succeeds. I don't succeed when my ideas get listened to. That's great if one of my ideas helps the product succeed, that's great, but if my idea is stupid and someone tells me so, and they're right, then I don't win anything from standing on that idea and standing strong on it. I think we try to have a culture where we are really trying to all pull in the same direction.

Rian: 30:50 When I talk to some of the staff too, some other team members, the word that I keep going back to is care. I think that we care for each other, we care for the product, we care for our customers, and I think if that's the basis of things, then the silos disappear and then we celebrate these wins together, especially, for example, coming back to the report, when that report looks different next month because we fixed something. We celebrate that together. It's no one's one win. I think the culture we're trying to create is that we're not in it for ourselves here, and I think that makes an enormous difference.

Marek: 31:34 There's clearly a shared ownership across the Product Team and the CS Team to really improve the customer experience. What are some of the tactical and operational ways that we work to keep these two teams in sync?

Rian: 31:52 Yeah, for sure. I think our planning is really set up to work in this way. We kind of try to plan in quarterly cycles. Like I said, we don't work off a backlog. It's not like we're starting from square one, but we make changes as we go based on what's important. But as the leads team meets and talks about our business goals and some of the things we could do, we present that to the team, not as, "This is what we're going to do," it's a proposal. There's been many times where that direction has changed or the way that we want to approach things have changed based on feedback from the team. But once everyone kind of agrees on the general plan, the execution of it, the specific execution plans, becomes the autonomy of the individual teams working on it. You have designers, engineers writing the first drafts of specs, which is... If any product managers are listening to this, they will freak out.

Rian: 32:57 I don't know if I want them to hear it but... My role is more to come alongside them and help them figure that out and answer any questions or ask questions most of the time. We do that because in that way the team really feels that ownership, because they understand the problem. They are the ones creating the solutions for it. We have a template that people use for these project plans where we want to make sure we answer the right questions, like, "What problem are we solving? Who are we solving it for? How are we going to make money or measure the success out of this thing?"

Rian: 33:32 But everyone on the team has their stuff that they're working on, and they have the responsibility and the autonomy to do that. Once those drafts are done, it gets circulated, and everyone on the team comes in and asynchronously ask questions or clarifications, but again, not to try to find gotcha moments, but to truly try to improve on the plan that's already there. From the strategic level all the way to, "Now I'm writing a thing in a document," it's set up for people to have ownership and also for the rest of the team to help them succeed.

Marek: 34:10 I assume that the CS Team is heavily involved in some of the planning that's going on, yeah?

Brian: 34:17 Yeah. Kind of the cool part about all of that... so Rian saying that the developers and designers are writing these product plans, but when they're doing that too, the Support Team can go in and look at the product plans that they're writing and figure out if there's going to be support need from this feature, so writing new developer docs or maybe some sort of educational material that we need to create, all the way to raising any concerns, saying like, "Hey, from talking to customers, this might be a problem." Everyone's involved, which kind of creates that collaborative ownership culture even more because we're invested in it. It's not kind of what Rian hinted to earlier. It's not something that we're being told that's happening. We actually have a voice to raise any concerns or make sure that when a new feature is released the launch is really successful.

Marek: 35:05 It sounds like this collaborative planning is something that has contributed to keeping, really, all teams in sync as we move forward through our development process. Was this always the way it was done at Postmark, or is this a new development to have these kinds of collaborative team plans at the onset of quarterly planning?

Rian: 35:27 It's definitely been an evolvement over the years, and it'll evolve again, I think. We're about a year into this particular way of working, and I think we all like it very much. But in the past, we had sometimes... I know with planning we went all the way down to six-week planning like Basecamp does, and Then this is just the format. Natalie and Chris created this operating system, which we'll write about more, I think, in the coming months, but that is set up in this way that I think we all really like. It evolved to this point, and I think we're all really comfortable with how it's working now. Not that it won't ever change, it's just this is where we're at, at the moment.

Brian: 36:09 Also, as an individual contributor, I think something really powerful about the quarterly planning is we have a little bit of a show and tell at the end of each quarter where we actually show all the work that you worked on. That just kind of creates a little bit more ownership too, where not only that you're shooting this work into the void, but you're going to be able to kind of turn it back and show it to the team and really show off what you worked on.

Marek: 36:31 Just to kind of wrap this up, gentlemen, I guess, in your own words, why would you say... We've talked a lot about this, but I'd love to hear you guys kind of just recap why it's so vital to keep Customer Success and Product Teams closely aligned. Brian, maybe we could start with you?

Brian: 36:51 I think it's just so important because we're kind of all in this together. We're supporting the product that they're making, and we're also hearing kind of the fire hose of customer information that's coming back. There's just so much good feedback in there. To kind of business goals and all that stuff, if we want to continue growing the product, if there are little product annoyances that come up 15, 20 times but we're growing our customer base, those little issues just become not sustainable. If you hit a certain user amount in SaaS where you're just growing customers, well, you don't want your support growing as much with that, just cost of support, and you don't want to hire more people as your support grows. I think it's just good to always remember that you're in it together and it's a collaborative environment to really work together to solve any issues that come up.

Rian: 37:42 Yeah. I think from my perspective it's the channels in a business that a product manager usually has most access to are the technical needs and the business needs if we talk about those three things again, but these channels to understanding user and customer needs are often just closed off for some reason, silos or whatever it might be. The fact that we encourage everyone to have direct interaction with customers, including... Our developers do support when some of the issues get really technical. They get to have that direct interaction as well. Then for us to see this as an important input into our products, we have to put our money where our mouth is. In that sense, we have to stay extremely close to each other to make sure that those needs are always being made known. I don't see it working any other way if you want to be a company that has people that are happy to pay you. There's no other way to do it.

Marek: 38:44 Wonderful. Well, I just want to thank you both for carving out some time to be with us today.

Rian: 38:50 Thanks so much.

Brian: 38:51 Thank you for having me.

Marek: 38:54 To our listeners, thank you for joining us today for this episode of Talking Email with Postmark. If you enjoyed the episode, please leave us a review on iTunes and subscribe to receive updates on all future episodes, and be sure to check out the resources section for this episode, where you'll find helpful articles and resources to keep your CS and product teams aligned. Lastly, if you're ever looking for help bridging the gap between your customer success and product team, drop us a line at support@postmarkapp.com, and we'd be more than happy to help. See you soon!