How we think about customer communication for our SaaS products

Ilya: 00:00:07 When you're talking about the onboarding, and we're talking about Drip, yes, you can really lose touch with reality, and you go into like really optimizing so that get the most clicks, and the most purchases and your churn as the lowest because re-optimizing for people, becoming better customers, you having more revenue. But as Chris said, we really try to look at it differently. We try to say, "How do we make people more successful?" And it's not always by adding more features or something to the product. Sometimes it's about communicating and helping people at the right time at the right place.

Marek: 00:00:36 Hello and welcome to Talking Email with Postmark. I'm your host Marek Loder and in today's episode, Chris Bowler, head of customer success for our latest product, Conveyor, and Ilya Sabanin, a developer and product manager on the Conveyor team. We'll discuss how we've approached customer communication planning and development for our SAS products. We'll start by exploring customer communication requirements for early-stage SAS products like Conveyor and then take a closer look at how those requirements evolve over time as products mature and sharing our own experiences with customer communication. We hope that you'll come away with some ideas on how you can improve your own customer communication workflows for your business or side project. Hope you enjoy the episode. Thank you guys for joining me today.

Chris: 00:01:17 Thanks for having us.

Ilya: 00:01:19 I'm very excited to be here.

Marek: 00:01:20 Cool. Well, let's get started with some quick intros. Chris, a fun fact that we discovered about you on our most recent Wildbit retreat up in Vermont is that with respect to longitude, you working from home and Prince George Canada actually makes you the Westernmost employee on the Wildbit team.

Chris: 00:01:42 That's a prestigious award for sure. Thank you. Thank you.

Marek: 00:01:46 And you've been a customer advocate at some really amazing organizations throughout your career. Can you tell us about your path to customer success and how you ultimately ended up at Wildbit?

Chris: 00:01:59 My career kind of started in a more traditional IT but eventually I started my own business and [inaudible 00:02:08] about it eventually had a chance of working for some really great SAS products who were all customers of mine when I was running my own business. So started a campaign monitor and then went to envision before coming to Wildbit. And I think just during my time in those companies, I started off in customer support but became more interested in the sort of strategy, the proactive side of things rather than just the more reactive side of customer support. So thankfully at Wildbit I had a chance and vision to focus more on that side of the house and just understanding your users and making sure that your team and everyone on the team is able to know what the customers need the most and make sure that the product you're working on meets their needs. So it's been a long road for me, but a really fun one.

Marek: 00:02:56 Cool. Certainly, I'm excited to talk a little bit more about that later on in this episode. And Ilya as one of Wildbit, earliest employees, you actually began working for the company while you were living in Siberia. Can you talk to us about your path to web development and how you ultimately got connected with Wildbit from across the world?

Ilya: 00:03:18 Yes, so me and my brother were one of the earliest Ruby on Rails Developers in Russia and we were fairly active in the Ruby on Rails community. And that's how Chris, the CEO, and founder of Wildbit stumbled upon [Dima 00:03:34] my brother, and he was a... So Chris was looking for freelancers, and it was not uncommon to look for freelancers in Russia back in the days. And that's how he got to, Dima got recruited into the company and then eventually he pulled me into the company as well. So there's no fancy, amazing story here.

Marek: 00:03:54 So you followed your older brother?

Ilya: 00:03:59 I just followed my brother.

Marek: 00:04:01 That's cool. And just a side note for those listening, Dima is actually still with the Wildbit team and uh, Ilya and Dima you guys work alongside each other on Conveyor? Yeah.

Ilya: 00:04:13 Yeah. And it's actually a funny story because Dima pulled me into Wildbit and then he kind of left Wildbit for a short period of time and then I pulled him back into the company. So he hired me, and I hired him back.

Marek: 00:04:24 Cool. Well before we jump in, I'd like to give our listeners a quick backstory on Wildbit. So Wildbit our parent company was founded in 2000 and is the proud creator and owner of three distinct software products. Beanstalk, a hosted version control service that was launched in 2007. Postmark, a transactional email service that was launched in 2010 and Conveyor, a task based workflow tool layered on top of Git, which was launched earlier this year. I'd like to begin our conversation today by discussing the customer communication that we have in place for our latest product Conveyor. Ilya, before we go too deep on this, can you give us a quick overview of what Conveyor is and really what problems it was designed to solve?

Ilya: 00:05:15 Yeah, sure. So Conveyor is a continuation of some of the ideas we had with Beanstalk. So over the years of running a version control hosting service, we gained a lot of knowledge and expertise and we decided to build a new product that... what we are trying to do with Conveyor now is marry version control to task management, instead of having two separate worlds where project management happening in one tool and then all the virtual controllers happening in another tool and then trying to set up some hooks and integrations to make those two pieces work. We tried to deliver a single product that provides a seamless, cohesive experience for people in a single workflow when two of those things work together side by side.

Marek: 00:05:59 All right, cool. So I mean certainly sounds like a really pretty ambitious vision for the product. Just so that we're on the same page, can one of you guys give us an idea of where are we now with Conveyor?

Chris: 00:06:13 Sure. And Ilya could speak to this as well, but we've spent a lot of time over the last few years. This is a completely different product for both Wildbit and that we've never created a desktop client before or product before. But it's also new in that no one else is really building something like this. So it's been a lot of experimentation through the process. And so at the point where we're at now we publicly launched in a sort of a soft launch kind of way earlier this year, and we let people sign up, and we've had people using the app and checking it out. And then we were taking that feedback and trying to just understand how to best sum that all up so that people understand what Conveyor is.

Ilya: 00:07:01 There's also, with Conveyor, there's also some struggle in terms of people trying to understand exactly the concepts behind the product because it's a novel approach to version control. We ask people a lot, we ask people to move aside the existing things that they know about the way you work with the different repository and all of the existing assumptions we're trying to, we ask you to set them aside to give this new product new workflow and chance. It's been a challenge to echo what is the right way to explain Conveyor to users so that they understand it. Because obviously there's so many new products these days that people don't usually dedicate a long time to each product. So it's been a challenge to like, how do we, exactly, how do we give it to people so that it's understandable.

Marek: 00:07:58 So I actually want to touch on that, Ilya, so this concept of communicating, division and explaining the value of this product. Can we go back and talk a little bit about what some of that early communication with perspective users look like?

Chris: 00:08:15 I think in terms of the original vision, like when I first started at Wildbit, it happened to be at our annual retreat and that was when Ilya pitched the idea of Conveyor. And right off the beginning I didn't have a name at that point, but the idea was, people get into trouble with their development workflows specifically with version controlling and Git and we needed... By the time they come to us we couldn't help them because they'd already gotten into a mess. So we wanted to help people by building a tool that guided them through their workflow in a consistent manner.

Chris: 00:08:45 So our early communication was reaching out to people, talking to them, and during that conversation that we would have with them, we would just share that, "Hey, we're working on something different here. We think we need to go..." We had to decide between sort of redoing Beanstalk or trying something new, and we decided to try something new. And right away those were sort of the first people who we shared the idea with and who expressed interest in seeing what we had to build.

Ilya: 00:09:13 We also did a series of blog posts when we were trying to introduce people to the concepts, and we're trying to explain the need for something like Conveyor when there's a Beanstalk, Github, Bitbucket, they exist, and they kind of solve all of the version control needs of all the people right now. So we needed to prepare the ground core for a new product.

Chris: 00:09:41 Yeah.

Marek: 00:09:42 Can you talk to us about some of the messaging itself?

Chris: 00:09:45 I think in that messaging, the focus for those posts was really about the pain points that we would hear people talk about. Things like, doing a proper branching process in Git, or having to communicate with your team over and over again on the same thing, having to do one piece of work but update documentation in multiple places. So we just tried to talk about all those things and how Conveyor or at least our vision for Conveyor was going to help with those pain points.

Ilya: 00:10:15 Yeah.

Marek: 00:10:16 So it sounds like we had to do a lot to really create that vision? I guess as you think back on that, what are some of the things that we did well with respect to that early communication and trying to garner interest in Conveyor and what are some of the things that you would do differently?

Chris: 00:10:33 I think first is just listening to the people talk about their own situation. Just asking a lot of questions rather than just saying, "Hey, we've got a vision, and we're going to, here's how we're going to solve your problems." We listened to those problems to make sure that people consistently had the same problems, and I think also, I didn't mention this earlier, but Wildbit over, as people who've worked in the web industry for a long time, you build up a bit of a network, right? So Wildbit has an audience outside of its specific products, and I think each of our team members also has that sort of network. So we definitely reached out to a lot of the people that we know in the industry. A lot of them had used Beanstalk in the past but maybe weren't active customers anymore.

Chris: 00:11:15 But just getting the word out there that we're working on something and talking to people about what they were using, what are their workflow currently look like? And again, where were they feeling pain and having those conversations. So just being proactive in reaching out to people to talk about just what does development look like in 2017, 2018 and listening to what they have to say. And then maybe Ilya can talk a bit about this, but something we could have done better is maybe, if listeners aren't familiar, we started off by building a native Mac client, which we thought would be the best experience and then we had to switch to go doing electron. That maybe you could say it was a two-year experiment or mistake that we did at Florida.

Marek: 00:12:01 Detour.

Chris: 00:12:02 Yeah.

Ilya: 00:12:04 Yeah, that was definitely a very interesting experiment that we did, insight 2020 of course, that's building for Mac was a big mistake for us. But I think Marek was asking [inaudible 00:12:16] communications mistaken, it's solely on you Chris. It was a development mistake. It's completely outside of the scope of this.

Chris: 00:12:24 Absolutely.

Marek: 00:12:26 Technology hiccups aside. I think one of the things that you both have established is how vital those lines of communication were with early customers. Speak to some of the back and forth that took place early on with those users?

Chris: 00:12:43 Well, I think as we got to points where we felt ready to share something, we would then reach out to some of these people, and we would invite them to participate in Beta testing or even at some point we called it Alpha testing because it was so early. But just to get it into people's hands, it was more than a mock-up prototype. It was an actual working client or at least most of the time it would work. But we would get people to use it and test it and share their feedback and then we'd go back and work on what was next. And because of the, Ilya can probably talk a little bit about how that look when we had the native Mac client as compared to Electron. But one thing that we did do right off the beginning is when we said, "Hey, this is our next product, sign up if you're interested."

Chris: 00:13:39 We didn't just let people throw out an email address, we actually asked for some information. So many startups today they just want the bare minimum information, so they get as many people sign up as possible. But we wanted to make sure we were getting people who fit, people who had the pains that we're trying to solve. So we asked for a lot of information. Like how big is your team? What kind of team? Do you work with Git or SVN? Do you work on Macs or Windows computers or Linux? Just so we could get an idea of what kinds of people are interested in these problems.

Chris: 00:14:11 And then if we're building a Mac client, we're obviously not going to be able to help Windows people right away. So we wanted to be able to break those interested people up and make sure that we were talking to the right kinds of people. So that was kind of the thing that we did early, it was just segment those interested people up and reach out to the ones who we could help them most right off the bat.

Ilya: 00:14:31 Yeah, I can add something here. One of the main goals, what we're trying to achieve since we started building Conveyors to not build it in a vacuum. So as soon as we compile the list of our soon to be Alpha testers, we immediately started reaching out and talking to people. And as soon as we gave people access to the Alpha product alpha version of the product, we were basically holding their hand throughout the entire process. We'll go to manual onboarding them, and we were trying to get feedback directly from those people using the products and everybody on the development team, design team, everybody was involved in talking to those people, which I think was very important. So there's no insulation between who's trying to use your broken things while they were still being developed, and the people who are actually developing. I think it's very important that this connection is very direct. As direct as possible.

Chris: 00:15:24 Yeah. Through the entire process we've had, everything's been very manual. And then also we've made sure that there's no filter in between the people using the product and the rest of the team. So we did things like set up our email address so that it goes out to everyone on the team when a customer sends an out request or has some feedback just so everybody can see everything.

Marek: 00:15:47 So it sounds like being selective about who we invited to the product was important as well as establishing those early lines of communication. Can one of you speak to the struggles that arise when it comes to navigating that early user feedback?

Ilya: 00:16:04 Yes. I mean that's not a first product, so we learned long time ago that feedback, that you have to be really careful processing feedback because it can really screw up the product. You can listen to one person who really needs that feature. If you just run and quickly add that feature that person might not even end up using that feature for one reason or another reason. So we're really trying to look for is to look for patterns. We're trying to collect as much feedback as we can, and we're looking for patterns and everything that we received, we've discussed internally, and some things were put aside and some things, yeah, I had a pretty big effect on the direction of Conveyor.

Ilya: 00:16:46 As soon as we started doing alpha testing, as soon as people got on board using our alpha clients, we immediately started filing tickets about the experience not being correct, the performance not being right or things being confusing, navigation being confusing. So this is like a low level UI, you ask stuff. But we also got a lot of questions and problems with like the overall structure of the product. How do I use it? How do I use this? Why is this so confusing? So yeah, a lot of the changes inside the product were driven directly by the alpha and beta users.

Chris: 00:17:24 Yes, sure. I wouldn't necessarily describe that any of that feedback caused us to pivot. But I think we learned a couple of things. I think number one, when you're going to run a beta, and you're going to invite a group of people you learn pretty quickly that you have to kind of invite a lot more than what you expect. I mean, people are busy. So the amount of time that they can invest into trying tools is pretty small, right? So to get a healthy amount of testing from a small group of people, you have to really invite a larger group of people. So sometimes the feedback that you get was no feedback at all. And so we had to spend time digging in, okay, here's a group of people, 10% of the people that are using the product, what happened to the other 90%?

Chris: 00:18:11 And so trying, when it comes to the communication is really, really doing your best to get to the bottom of why those people aren't using the product and having those conversations with them. And of course, when we started to identify some pretty big barriers that would stop people from ever even trying a product like Conveyor, some people just want it to work with Github. That's where their repos already are, that's where their projects are. So right away we knew that that was a big barrier for a lot of people. So that was something that influenced us experimenting on whether we could make that work. So sometimes that communication isn't so much of people telling you what they want, it's them just not trying at all. And then you have to spend the time figuring out why.

Ilya: 00:18:53 And another challenge as we're talking about feedback actually. So another challenge is sometimes people are being very nice because all of our users actually are developers. So they know what it's like to build a product, especially as complicated as this one. So when we reach out to somebody to like jump on a call to give us some feedback about the product, people are really sometimes trying very hard to give us feedback, even though sometimes it's cassette it's not really feedback, and you can see the person just trying to be nice and trying to be useful.

Ilya: 00:19:24 So they would pick on like small UI pieces here and there. So we have to be careful about that as well because if we go into constantly adjusting UI based on all of these random pieces of feedback or would be like in an infinite loop of UI adjustments when in fact this is not what is going to make or break this product.

Marek: 00:19:46 So I'd like to zoom out for a second. A lot of the communication that you've described for an early stage product like Conveyor sounds really manual. Is that typical?

Ilya: 00:20:02 I think it's not only normal. I think it's essential because we developers are kind of afraid to talk to people. And I see a lot of products being launched, smaller products, small teams when people just don't talk to anybody and developers don't talk to anybody, don't reach out to anybody. They just build something that they think will work and then they get very surprised when then they launch it nobody is interested in this. So it's very important to reach out to users, potential users, alpha users, beta users, to talk to them as much as you can to try to see the product, try to see the experience from their point of view, from their eyes.

Ilya: 00:20:40 Because as we are building it we're getting used to it. So if there's some confusing or frustrating pieces, we just glance over them because we've seen them a hundred times. But when you jump on a call with somebody, and you ask them to maybe screen-share and ask them to show how they do something in the product. You see things that you've never seen before. And I feel like, unless you are really dedicating yourself to have this direct connection to the users on a daily, weekly basis, you're really missing out, and it's going to be really a big struggle to build the product the other way.

Chris: 00:21:15 Yeah, I agree. As a customer facing person, it's tempting always to, if I've had to write this a similar sort of response to two or three people, I want to right away, automate that or save myself some time. But on an early product like this, I want to have those conversations over and over again so that I'm feeling keenly where people are struggling or confused or anything like that or whether there's a particular, a very, like we said, threads, common themes occurring. So, right, everything we did was manual from supporting people to inviting them to onboarding people when they were going to start using the product. We tried to be as hands on as manual as possible so that we can see what people are doing and get a feel for the experience from their point of view.

Marek: 00:22:09 So it sounds like there's just a tremendous amount of value that we were able to get out of that. Those manual communication touch points with early users?

Ilya: 00:22:18 Yeah, because I mean, if you automate everything, and you have some sort of automatic Intercom or whatever system you use to like email people and message people and send those like canned things and everything is scripted out. You can really go into like a complacency mode one. Like it's just all happening, and you're not really sure who is signing up for the product, who is beginning a beta today or yesterday and how it's going for them. Plus it's not really clear immediately what those communication points should be, what the some boarding process should look like because you're not really sure yet what are the most frustrating parts of the process? What is the most confusing pieces of product?

Ilya: 00:23:00 So I think those manual processes that we had set up like us reaching out and having calls with people and screen share with people allowed us to actually map out how our onboarding should look like and allowed us to build some sort of like an early framework of okay, if we're going to start automating this process, these are the things that we need. If we automated right away from the beginning, I'm not even sure how this would work.

Marek: 00:23:28 So based on what you guys have shared, it sounds like establishing personal lines of communication with early users and conducting that communication manually has not only been incredibly valuable. It's been vital for us as we've worked to bring Conveyor to market. I imagine however, that as product scale and begin to gain traction, that manual communication can become somewhat unsustainable. I'd like to spend our remaining time together discussing how customer communication requirements change over time as companies scale. And specifically I'd like for us to focus on the customer communication we have in place for Beanstalk while that product that's been around since 2007. Ilya you worked on Beanstalk, can you tell us about what the product is and where we are with it today?

Ilya: 00:24:17 Yeah, Beanstalk is a version control hosting service that supports deployments and code reviews. And for the longest time it's been the biggest, most successful product for Wildbit. Beanstalk is what has been driving Wildbit to grow over the years and these days as we moved on to developing the future of Beanstalk, which we call Conveyor, Beanstalk kind of went into maintenance mode where for us as a company, it's super important that we continue supporting the product as long as it has any active users. So at this point we're just fixing issues, making sure the infrastructures solid, making sure it's secure and safe and stable, but we're not adding new features because we're focusing on Conveyor at this point.

Marek: 00:25:04 Okay. So it's at this point a pretty self-sustaining product?

Ilya: 00:25:08 Yeah, I mean we've built it over the years so that it doesn't really require a lot of intervention from our side. It just works. And we'll just have to make sure it's up to date with all the security stuff and we have to make sure that our customers who are experiencing any kind of problems or issues with, they get support that they deserve. So every week, we still go into Beanstalk and adjust and tune things here and there to make sure it's running smoothly.

Marek: 00:25:36 So I guess with that, it's clear that Beanstalk is in a very different state than our Conveyor product. I'd love to explore how customer communication changed from a more manual process to, sounds like very automated process, as Beanstalk grew into a more mature product. Can you speak to some of that?

Ilya: 00:26:02 Yeah. It's actually funny because when Beanstalk started, it was an instant success. So it was a fire hose of people signing up and our infrastructure was not able to support that. So in the beginning it was all about customer support. All of our customer communication was all around supporting the people, answering questions and fixing issues.

Marek: 00:26:23 I guess that's a good problem to have.

Ilya: 00:26:26 It was an excellent problem to have, right? It was all around customer support. We didn't even get into having like Drip campaigns and onboarding emails and stuff like that until later when we got more mature. Yeah, and that middle phase is when we'd gotten into onboarding, which we can talk about later about the stuff we did for the Drip campaigns and stuff. And then now we're back into maintenance mode again, the focus, the priority now is to support the existing customers. So we have the fast response times to their support tickets and stuff like that.

Marek: 00:26:56 Okay. So I guess diving then into that, when we kind of moved from early on with Beanstalk and more manual Ad Hoc process of communicating with customers to more automated workflows, what were some of the key things that we have to consider in that transition?

Ilya: 00:27:16 Yeah. So this was a long time ago by internet standards. The amount of products that are designed for customer communications was not that great. So, in the beginning, we actually implemented our own subsystem for Drip campaign delivery, so it wasn't emailed based systems and would look at people who sign up and would create funnels inside and see what people are doing inside the app. And it would send the emails to like time to emails to those people based on their actions. And then slowly we outgrew that and we switched to custom IO, which Chris Bowler can talk about. Yeah.

Chris: 00:27:57 Yeah. That's interesting to hear that because I think when I came on, I don't know if those internally build campaigns were running anymore. Because I started making everything, set up in customer. So that's interesting to hear that, basically what I was doing was kind of replicating what they'd had in the past. That's funny.

Ilya: 00:28:16 Yeah. I mean, the system we had was not as advanced as customer IO, not as many functions. And the biggest issue with that is that every time we need to change something in the way Drip campaigns are sent, emails are sent or like the order of those emails or change the funnels, we would have to call in a developer to go inside the code and like do a lot of changes which obviously is not as efficient. So when you joined the team, you started moving everything to customer IO and that's exactly when we phased out our internal thing because it just wasn't as flexible.

Marek: 00:28:52 And just to be clear, I guess, with kind of our home-built system and also it sounds like what we eventually built in customer.io, were these emails, were they presale emails or were they onboarding emails? What were these emails exactly?

Ilya: 00:29:09 It was the onboarding campaign. We call it a Drip campaign. So after somebody signs up and starts using Beanstalk and they would go start using different features of Beanstalk or not using specific features, they would start getting like an email every three days or like we would try to get them introduced to the concepts of Beanstalk, try to introduce to the pool, and pull them into using certain features we would want them to use.

Marek: 00:29:34 Okay.

Chris: 00:29:35 And then that was basically what I built in customer IO, not knowing exactly what we had in place before. Basically we have an onboarding series that's, I think three or four emails long that just kind of informs the new user who has signed up. It's completely after signup of what's available, how Beanstalk can help them. And then also some separate behavioral campaigns that are based on activity or lack of activity that will help people get the most from the product. And then I think for me it's really important whenever you build these things, you don't know if this is what we're going to get into, but it's all about their success is not about, "Hey, we want you to use these features so you are happy with Beanstalk and you pay us more money."

Chris: 00:30:20 It's about you have a need, you're a developer, you have to deploy your codes, and you need to review your code before deploying. So we want to make sure that people who signed up didn't think of Beanstalk as just a good hosting service or subversion hosting servers, but it's actually a workflow development platform that helps you really manage that entire workflow. So the emails are based really on helping people understand that.

Ilya: 00:30:47 Yeah, definitely. And actually I think in 2015 is when we actually got very serious with the Drip onboarding campaigns, that's when we actually hired a consultant who came in and like we had dedicated multiple weeks to just polishing and improving that flow through the signup into like making your first deployment or making your first commit to make sure everything is as smooth as possible that people don't have any questions, don't get frustrated. Yeah, so it was a very interesting, very long process.

Marek: 00:31:21 Do you remember at all what that process looked like in terms of actually identifying those key touch points and making sure that, to Chris's point that those touch points were customer centric, right. That it wasn't about us and what we wanted them to be using. It was about making sure that they got the most value out of the service. Do you remember what that process of liked Ilya?

Ilya: 00:31:44 Yeah. I mean, what's interesting about this whole process is that instead of just being one single thing, usually when you work on the one onboarding it, it touches everything on the product. It touches the landing sides, the marketing side, the messaging, how you talk about the product, it touches the sign up flow, exactly what you're asking for on the signup step, how do you deal with a credit card and then it goes into the app, it goes into the email. So usually it's like multiple dozens of small changes all across the product just to get some points across. And for us it was important that the vision is correct for the product.

Ilya: 00:32:20 As Chris said, it's not just like a good hosting place where you just throw your repository and forget about it. We also wanted people to adopt some of the best development practices by using code reviews and having a more solid to deployment process for their projects. So when we worked on the new onboarding flow for the product, we ended up refining the vision, refining how we presented and then going changing the signup and changing some pieces in the UI, and the product just to make sure this whole thing just made sense.

Marek: 00:32:54 And who were some of the stakeholders involved in that process Ilya?