Ep #1: How we think about customer communication for our SaaS products

Chris Bowler, head of Customer Success for our latest SaaS product, Conveyor, and Ilya Sabanin, the product manager and developer on the Conveyor team, discuss how we’ve approached customer communication planning and development for our SaaS products. We’ll start by exploring communication requirements for early-stage SaaS products like Conveyor, and then take a closer look at how those requirements evolve overtime as products mature. Chris and Ilya touch on many of the considerations you need to keep in mind when planning customer communication for your product. Don’t miss out.

[Please use a browser to see embedded content.]

Helpful Resources:

Drip campaigns — How we do them differently at Highrise

C.A.R.E. – a simple customer onboarding framework

How to Write Engaging Transactional Emails, featuring Beth Dunn

5 Surprisingly Simple Practices of Stellar Customer Success

When to Send Purpose-Driven Instead of Product-Driven Emails

Lifecycle Emails Are Magic Pixie Dust for User Onboarding

Onboarding Isn’t About Signups, It’s About Long-Term Engagement

Full Episode Transcript:

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?

Ilya: 00:32:58 Everybody, it was Chris and Natalie, it was the guy who we brought in as a consultant, and it was me, it was Eugene. Yeah, pretty much the whole team was on this. We didn’t do anything else for like two or three weeks except for just working on onboarding.

Chris: 00:33:15 Just to add to it, Ilya mentioned, when I came on a team, I came in on 2015 so earlier your memory must be slightly off because you guys would’ve done it before I came on. The first thing I did was just take a look at Beanstalk and try to understand, what is this product, what are the customers? And then what I like to do is try to identify the ideal customer journey. Like what does it look like for a brand new developer who doesn’t have this kind of tool to suddenly have these things at their disposal and try, and recognize where that sort of different, we might describe this in different ways, but the wow moment or the aha moment. Where they really understand the value that the product is going to give them and then walk backwards and look at what are the steps that that person has to take to get to that moment.

Chris: 00:34:01 And then build your onboarding or your behavioral based campaigns around that so that you can help them to get to that point where they really get the value. So just to talk about with Beanstalk, you’re never going to get to the point of getting the value from a deployment or a code review if you don’t add a repo to your account, or you never, if you never make a commit to that repository, you’re never going to get to those points. So I built campaigns that were based around those things, making sure that people were taking that step. So if someone signs up and had the repo and three days later they haven’t added a commit, we’re going to send them an email message, just understanding what the steps are they need to take in order to get that commit into their repo and being stuck. So those kinds of things are what you want to do to help the people help the customer get the most from the product and have a really good journey from signup.

Ilya: 00:34:54 You’re right about the year, it wasn’t 2015, it was 2012.

Chris: 00:35:00 Beanstalk is really old.

Ilya: 00:35:01 Time flies. Yeah. I’ve Beanstalk is really old.

Chris: 00:35:04 It’s really nice, some of these tools like Customer IO and Intercom that we have available today are great because they do help people like myself who’s not a developer, work on these kinds of things and help get the customers the information they need.

Ilya: 00:35:16 Yeah, really it’s all about the efficiency because as soon as you have to bring in a developer, are you pulling them. Whatever they’re working on, you have to pull them out. And then as soon as you’re making any changes to the code base, that means it has to go through the QA process and then it just complicates everything so much. So whatever those services ended up costing, it still is cheaper than having to have somebody go into codebase to make those changes. And then as soon as you need like some more flexibility, like okay, for example, we need to send this message or this email when this happens, and our system happens not to support that. We have to ask support for that and that can go with like days or weeks of development time. Yeah. So it was pretty painful to have our own homebrew system for a while. So yeah, having cost to customer has been a breeze.

Chris: 00:36:03 Yeah, just to circle back to Conveyor for a moment, it’s been interesting for me. It’s the first time I’ve ever worked on a product from the ground up. So to have those decisions to make, I’m finding that balance between custom native onboarding that’s a part of your product and where do you do that and where do you bring in some of these other tools, that allow you to build these onboarding campaigns, whether they’re in app or email messages? It’s an interesting balance to find and I think historically Wildbit has been a company where they build a lot of that onboarding into the product itself. And of course the best onboarding is where you don’t have to tell people what to do.

Chris: 00:36:41 You design your app really well. So it’s understandable and people know what they need to do in order to get value from it. But it’s always a tricky balance. So with Conveyor we spent a lot of time deciding exactly where we need to put those resources, whether Eugene our designer or Ilya and Dima want to build those things right into the product or whether I can do some of that stuff using Intercom and tools like that.

Ilya: 00:37:06 Also, there’s something to be said about, I always felt uncomfortable using those services. So because we ended up sending a lot of information about what’s happening in our system to some third party. So we usually spend a lot of time looking like, can we trust that company with our data? And we also try as to make the integrations so that we don’t send any extra information when they send a bare minimum, assuming that if this information will get into somebody’s hands who’s not supposed to get this information, what the impact is going to be. So in some cases, as Chris said, it makes sense to have something on the inside to have like some part of the onboarding or Drip campaign on the inside of the product. So that you don’t expose that information to the third parties.

Marek: 00:37:55 So I guess with that, in terms of making that decision between that in app messaging versus let’s say an external tool like Intercom or customer.io, are there any clear delineations that can be drawn as to kind of which pieces of messaging are best suited for those two different channels?

Chris: 00:38:16 I think, and maybe we’re really blessed at Wildbit because we also run a transactional email service and so that’s true. Building some of those things right into the product, like the first welcome email, a signup confirmation, things like that. We just going to do that in Postmark because we own that anyways. So those are easy decisions. It’s after that point where it starts being focused a little bit less on just account details and transactional messages and becomes the sort of onboarding informational type of message where you’re trying to educate your customer. I think that’s where I start to draw the line.

Ilya: 00:38:52 And also if you look at churn, you see how often the content changes. If you see like, if you have a Drip campaign it has like seven emails and the content isn’t constantly improving or changing now it’s five emails now instead of seven or eight. I think that’s when you really start getting much more benefit by having it outside of the system because you don’t have to make those adjustments anymore. But at the same time there’s some type of emails like the unrelated stuff that doesn’t change as much and then having that stuff in the app, it’s just fine.

Chris: 00:39:23 Yeah, I think the most, Ilya touched on like one of the most important aspects of this whole discussion is that data and no matter where I’ve worked, that’s always been a challenge. Getting the data about your customers into the hands of your customer support or customer success, people, sales, marketing people. That’s a struggle for every company that I’ve seen out there.

Marek: 00:39:44 So I’m being curious, Chris, to explore that a little bit further. I mean, you obviously have experience working at campaign monitor and envision, which are certainly well-established SAS companies. How does data start to really factor in once products are fully at scale in terms of making those critical decisions about whether messaging is working and whether it needs to be refined?

Chris: 00:40:09 Yeah, I think it’s so critical even before we get to the point of messaging because you want your messaging to be accurate, right? Or to be addressing a reality. So you have to have the data in the first place. And that’s the biggest struggle. And of course, once your product has scaled to a certain size, you have a lot of data. So it’s difficult to even make slight changes or to get that data from one tool to another, right? So that you can actually act on it. I think from my experience, most products have a lot of data housed within the infrastructure of your product. But you usually get need to get some of that out somewhere to another tool so that your customer success team or support people can act on it. So for companies where you’re going to hire a developer whose main purpose is to do a good job of getting that data from one place to another and doing it in this safe, secure manner.

Chris: 00:41:05 You have different types of, whether there, I’m trying to think of the job title, but QA engineers and things like that. If once you get to a large team that’s a little bit different than how we work here at Wildbit, but once your company gets big enough, you start to make some of those hires so that people can specialize on those things. So you need someone who’s really focused and understands the internal infrastructure really well, and then can get the data that you need to the right place and then of course, every little change that you make has a potential impact on your system. So even Traditional IT, my experience there is like usually you’re going to make some kind of a replica of your production data so that when you go and do a query or something you’re not impacting performance or something like that. So once you get bigger, you start to have a whole lot of concerns that maybe you don’t have at a really small early stage product.

Ilya: 00:42:01 Yeah, I agree with [crosstalk 00:42:02]. The biggest challenge is the data, I agree. Moving the data, importing data, exporting data, really challenging to make it securely so it doesn’t affect performance of the app so that you don’t pump too much data because then it’s going to be just harder to work with it. You don’t put too much share personal information and stuff like that to really being careful with the data. And on Conveyor and the Beanstalk it’s been a constant struggle. As soon as like Chris needs something from you to add some something new to Intercom on Conveyor, he reaches out to me and say like, “Hey, we need this new piece of information,” and then I have to go and adjust integration to make sure we can send that information.

Chris: 00:42:39 I’ll tell you what though, as a customer success person, this has been the best situation for me because I was in on the ground floor, so I could say from day one this is the information we’re going to need in whatever place we need it so that we can act, we can understand what our customers are doing or not doing and we can act on it. So it’s been great. Everywhere else I’ve been, you’re always coming to the party a little bit late and you’re having to ask for access to data that’s already been created and get it somewhere else. Here we were able to just get that infrastructure in place right from day one.

Marek: 00:43:08 I mean, what’s interesting is it sounds like although getting that data can sometimes be a challenge as we’ve been able to expose that data to you Chris, but it’s actually been quite liberating.

Chris: 00:43:21 Absolutely, 100%. It’s been night and day compared to other-

Ilya: 00:43:26 You do love your data, Chris.

Chris: 00:43:29 I want to know what customers are doing right and not in a creepy way, but so you can understand where they’re, where they’re not getting value from the product or where they’re using it in ways you didn’t expect so that you can make sure you’re building something that’s going to be useful.

Ilya: 00:43:44 Yeah, I mean it is actually very important. And back in the days, go like 10-15 years ago I would build products. We didn’t really spend too much time looking at that data. I mean are some of the apps I’ve worked in the past they didn’t really get to a point when that was really important to look at that stuff. But being able to have that data because like sometimes when we write a new app or create a new app, we don’t think about collecting that data from the beginning, we just think about building the app. We don’t really know what the users are doing. We don’t really know how people are using the features in the app and that kind of ends up hurting us in the end because we don’t, when we actually come to the admin say, “Okay, let’s try to optimize these flows and we’re make this process less frustrating.” We don’t really have the data points to make any decisions.

Ilya: 00:44:29 And that’s why in Conveyor since the beginning we were very serious about the customer success in all of these processes. That’s why at the beginning, almost since the beginning we added all of the data points and the special system that tracks what’s going on, which takes privacy into account and stuff like that.

Chris: 00:44:46 That was experience [inaudible 00:44:48] was coming from InVision. They’re very fast paced funded startup. So a lot of customers, lots of data and just getting that information into the right places was always a lot of work. So when I came to Wildbit and started supporting Beanstalk, one of the very first things I wanted to do was, we had this onboarding, very minimal onboarding set up in customer IO and I wanted to get some of that user activity data into there. So worked with Ilya to start getting commit deployments, code review, getting that in there so we knew what people were doing. So we had that data inside the product. It just hadn’t been put anywhere that we could use it for some of that kind of messaging communication.

Marek: 00:45:26 For sure. And I guess for some of the listeners who may be had a smaller, earlier stage company, you often hear of this concept, kind of paralysis by analysis where there’s just too much data. I guess I’m curious since this isn’t our first rodeo and we’ve built a couple of different products, I guess what are some of the key ways that you can protect against that?

Chris: 00:45:51 I think for me that really starts with identifying that user journey, like mapping that out beforehand so that you can then identify what are the most critical things. For Conveyor if it’s very similar to Beanstalk in a way that if a person signs up for an account and creates a project and makes a task, if they never get to the point of committing, they’re not going to get value from the product. So understanding that is important, whereas if they do or don’t set up an integration with Slack or something like that, that’s nice to know, but it’s not critical piece of information.

Chris: 00:46:22 So I’m not out there every week evaluating how many people are setting up integrations, right? We’re really focusing on those core events that are needed and in order for someone to get value from the product. So I think just focusing on those things. And then of course, you’re getting into a whole big topic about planning as a team, identifying what your key objectives are and how do you measure those, that’s a big topic also.

Marek: 00:46:45 We’ll save that for another episode. Yeah.

Ilya: 00:46:49 And so my point of view, I mean, as a developer, my goal is to make it as flexible as possible. So I actually, when I built the system to pass that data to Intercom, I basically, I try to record as much information as possible. So that’s when Chris can make a decision on his side of like, okay, I don’t care about this thing, I don’t care about this thing without having to go back to me and say like, “Hey, this is missing, this is missing.” Yeah.

Marek: 00:47:16 Can you just elaborate on what you mean by that? Recording as much data as possible.

Ilya: 00:47:20 Well, whenever a user does something in the app, unless it’s like really minuscule, I just record that just in case because we might not care about specific action right now, but two months down the road, we might say, “Okay, actually we underestimated this action that the user makes and we actually think it’s important to track this and maybe incorporate that into a funnel or something like that.

Ilya: 00:47:44 And then my system already records that and we already have some retro data for that. That’s great. And so I really try not to make, because Chris… customer success is Chris’s [inaudible 00:47:56]. So I try not to make a lot of decisions about that at my side when I implemented the integration. So I try to give him as many tools, as much data as I can without compromising privacy and stuff like that. And then Chris and his side can go into customer IO and then do with that data, whatever he wants.

Chris: 00:48:11 Sure.

Ilya: 00:48:12 And I’ll tell them if I need something else.

Marek: 00:48:15 And Chris, you touched on, I think it was Chris, you touch on this concept of having a data warehouse to be able to play around with these things without breaking the core product. Ilya, with respect to the recording of these data sets, where are you doing that or do you have any preferred system for that?

Ilya: 00:48:35 Well, so we record the events internally because we’ve learned over the years, running Beanstalk that these systems that we use for customer success stuff, they tend to change. So if today it’s customer IO, tomorrow it can be Intercom and then the day after that it’s going to be some other thing. So it’s important for us to own the datasets, so that we have it, no matter which system we end up using in the end. So we always have the internal way of storing that information in the database, and then when the time comes we can import that into the system or another system by excluding some personal information again from that, because that’s very important.

Ilya: 00:49:17 When we talk about the integration with Intercom, a lot of the events that we generate happen in the background, in the background processes and stuff like that. So we use the Ruby API to talk to the Intercom directly to import and export stuff.

Chris: 00:49:28 Yeah. I think with traditional or enterprise type of applications. Marek you often have a mere database or something like that where people might be writing crystal reports and things like that. A lot of SAS products I don’t think get to that level of complexity but you of course now have a whole set of tools out there like Segment IO and things like that. Where you can bring your data because you’re using, your customer success team might be using Intercom, but your sales team is using close.io or Drip or, there’s just so many different tools that now we see this sort of tertiary products coming to the market where they’re trying to, okay, put your data here so that you can use all those services together. Right. And I like the concept, but of course then just adds more security concerns overall.

Ilya: 00:50:17 Yeah. You don’t know where the data ends up being eventually. Like where does it go? But I still like this approach more than somebody having access to [crosstalk 00:50:25] they read only access because database contains much more information than anybody needs to build any kind of Drip campaign or onboarding process. And I feel much more safe knowing that I built the Intercom integration and I know exactly what I do send and I don’t send and it’s not going to expose any more data or any more information about our customers unless I explicitly go to the code base and say, “Okay, we want to send this new piece of information,” and that makes me feel better about it.

Marek: 00:50:55 So I’d like to kind of wrap things up. I mean, I imagine as more and more messaging automation and tooling begins to set in with a later stage product that it can be quite difficult to then get that holistic view of all of the customer communication. Can you talk about some of the challenges that we may have faced with that either at Wildbit or past companies that you worked for? With respect to being able to try, and see the forest through the trees as it were?

Chris: 00:51:24 Yeah, that does get to be hard. I try to document what I’m doing and then, not just what you’re doing but the reasons why behind it. That obviously gets to be hard when you’re a 200 person company working on a product with a lot of different aspects. But hopefully there’s somebody that, that’s why you see things like style guides and pattern libraries and things like that being put into place by companies so that there’s a better understanding across all the design team or all the developers on how we were writing code or doing design. And I think the same thing comes around customer communication, right? You have a voice and tone guide as you get to a certain size, those things become more important because there’s more people doing the work.

Chris: 00:52:07 And then it becomes more of a leadership concern or responsibility to have someone who owns that overall holistic picture. I think the most important thing is always coming back to talk to your users, right? Like actually no matter what you’re doing, and no matter how big you are, at some point you need to just get down to talking to the customers directly as much as possible. So that’s always hard, right? Going from the high level down to the trenches and coming back up, is difficult for any role on a product team. But for the customer-facing people, I think it’s always important to make sure you’re doing that. And then when you’re at the high level trying to somehow, I don’t know, just document what, what’s in place.

Ilya: 00:52:54 Actually, this is a very important point that no matter what you do with a Drip and onboarding is that it’s important to really talk to people directly, like human to human interaction. Because when every time we design or build this campaign system or email system or messaging system, we never pretend that it’s the human talking to customers. We always make it clear that it’s just an automated email. We’re trying to make it look nice. We use HTML templates and stuff like that. So we’re trying to be helpful with trying to meet people to make sure they are not frustrated, not confused with the product, make sure they’re successful with it, but at the same time they’re always one or two clicks away from talking to a real person.

Ilya: 00:53:36 Which I think is very important and what made Wildbit different from many other companies, many other products, at least back in the days. Now it’s more common to have somebody you can talk to, is that you can always speak to people from the team and not just some customer support representative from another country but developers and designers, everybody on the company was always doing support, which I always thought was super valuable. For me as a developer it was super valuable to talk directly to people that use the product that I built.

Marek: 00:54:08 So clearly regardless of the stage the company is in, that human to human connection and line of communication is always the best.

Chris: 00:54:19 Absolutely.

Ilya: 00:54:20 Yeah. I mean, Beanstalk got quite big. We had thousands of fan customers and then there was a lot of stuff going on, but like I never stopped doing support for it even though we had very, very busy iterations working on a lot of different stuff. I still did support for it every day because as soon as I would stop doing support for it, that’s when the distance between me and the end user would start growing. We’d be living in two different worlds, I would be living in my imaginary world with my systems that I designed and created that look so beautiful and amazing. And those people across the pond would be having so much trouble using all this crap. So it’s, I think it’s very important. Like I talk to those people and I feel their pains because sometimes we launch something, we feel like, “Oh, this is going to be amazing. This is the best system in the world.” And we’ll talk to people and everybody’s frustrated and they don’t understand that what works. So unless you have that direct link, you can get really detached and just live in a ball.

Marek: 00:55:23 Cool. Well, this has been an awesome conversation guys and I feel like we’ve certainly touched on a lot of different topics. I’d like to end off with some key takeaways. Ilya, perhaps we could start with you.

Ilya: 00:55:35 Yeah. So from the implementation standpoint, because I’m a developer, I have three takeaways. If you’re using a system that relies on the data to send Drip emails or onboarding, make sure you store data on your site. Don’t just rely on a service like customer IO or Intercom to store your data because you might eventually end up using another service. And you can lose your dataset or you can maybe export it, but it’s not in the right format and blah, blah, blah. So it’s always much better to store your data so that you own the data and then you can do whatever you want with it going forward.

Ilya: 00:56:11 Another point is I take privacy very seriously when it comes to personal information over the customer’s, treat it as your own personal information. So if you don’t have to send an email address or a phone number or a physical address to customer through Intercom, don’t send it. If your Drip campaign doesn’t use that data, yeah, it’s better not to expose that data. And the last point is that, again, as a developer, you have to do as much as you can to empower our customer success people. So like Chris, I make sure, but when I build the system, it is as flexible as possible so that he can go in and then do whatever he needs to do for the onboarding and the Drip campaign side. And yeah.

Marek: 00:56:55 And Chris, how about you?

Chris: 00:56:56 I guess the first place I’d start is try to find a company that puts the customer at the core of everything you do. We use the term customer-centric, part of the design process or developing a product. I think Wildbit has been amazing that way. Like Ilya hinted at that, that interaction with the customer, that meeting the customer’s needs have always been the forefront and everybody’s involved. So I think that’s key because then it enables you as a customer success person know that you’ve got the support you need. It’s a struggle to see people who work in an environment where a customer support or customer success is like a call center where they don’t really get the support from the management or leadership of the team.

Chris: 00:57:39 So that’s key, is being able to be in the right environment. And then, I think just whatever you’re doing, it’s always going back to what does success look like for your customers. We never wanted to make a better Beanstalk users or better Conveyor users. We want to help people be the best developers that they can be. So how does your product do that? How does it make them better at what they do? And always being focused on that. And then last of course is just taking the time. It’s really hard sometimes when you’ve got big objectives underway. It can be hard to sit there and think, “Oh God, I should get on the phone for half an hour to talk to someone.” But that usually is the best value of your time is actually just sitting down with people and having face to face conversations. So incorporating that into all the different objectives that you have is critical.

Ilya: 00:58:27 And we don’t talk about it actually, but I think it’s important to say that being honest with people and being really honest about your product and the process. So when somebody reaches out to us sometimes and they’re struggling with something, sometimes I would spend like half a day trying to really solve a pain for that problem because I understand. They bought into our product, they are really trying to do something on their side and they’re really struggling. So maybe not a very efficient for me to spend that much time helping that person. But I still do it because we really put a lot of pride into our products.

Ilya: 00:59:05 I know it sounds very fishy and sketchy, but when you’re talking about the onboarding and we’re talking about Drip, yes, you can really lose touch with reality and you’d go into like really optimizing so that you get the most clicks and the most purchases and your churn is 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 products. Sometimes it’s about communicating, helping people at the right time, at the right place. I think it’s very important to keep that in mind.

Chris: 00:59:40 Yeah, and that honesty gets even to the point where you can see that your product isn’t going to really work well for someone, they’re not going to get the value. And so you tell them that upfront. So that’s a really important thing too, actually understanding who are the types of people that you’re trying to help so that you’re not just adding someone who’s going to turn when they get frustrated down the road.

Ilya: 01:00:02 Yeah. It’s better to say no and say like, “Sorry. I mean just use Github because Beanstalk is not going to solve this for you.” And that’s again, yeah, being honest about it.

Marek: 01:00:11 Cool. We’ll wrap things up. I’d just like to thank you guys for being with me today.

Ilya: 01:00:16 Yeah. My mom always told me that eventually I’d be a very popular and famous and I’m glad this is where it finally happened.

Chris: 01:00:23 Yeah, we definitely have to put that in the show.

Marek: 01:00:29 And 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 useful tools and articles to help you plan customer communication for your app. Lastly, if you’re ever looking for help planning out customer communication channels for your app, be sure to reach out to us @supportatpostmarkapp.com, and we’d be more than happy to help. See you soon.

Source: Postmark