Thanks for listening to Don’t Make Me Code, a podcast that discusses developer experience design and the unique challenges of building developer-facing products. Don’t Make Me Code is hosted by Steve Boak, co-founder and CPO at Opsee, and David Dollar, co-founder and CEO at Convox.

In this episode of Don’t Make Me Code, Steve and David talk about some of the challenges of onboarding developers, and ways to make that experience better.

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

[soundcloud url=”https://api.soundcloud.com/tracks/245152401?secret_token=s-4SUlM” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

Steve: So, today we’re talking about onboarding, and what a pain it is for developer tool companies. It’s weird to me that, in the consumer world, we’ve got products that we can happily onboard into in seconds, and in the dev tools world, we go in the range of minutes, you know, five or 10 minutes feels pretty good.

David: Yeah, we’re dealing with like, complicated things that people are integrating into these other complicated things that they’ve built, and it’s often not quite as simple as ‘just type in your email address and click a button.’ You know, you have to add some pieces to your code, or add some dependencies, or start instrumenting things—there’s all this stuff you might have to do to get started.

Steve: And those requirements feel just unreasonable at times, I mean I can’t stand going through it, having to write code to onboard into a product.

I remember getting stopped using New Relic for the first time, and having to actually write code before I could start using the product, and it’s discouraging, but required. And it’s just this infinite frustration and we, in our product, we’re trying to eliminate that as much as we possibly can, but, it’s a unique frustration of our world.

David: Definitely, I mean, we’re trying to deploy applications to the Internet and they can be, you know, the variation to those is so huge, and so we spend a lot of time focusing on making it work out of the box without you having to make a whole bunch of changes right out of the gate. I think that’s really important.

Steve: See, you and I are both at early-stage companies, we’re dealing with our Beta customers now, and that’s a very high-touch scenario, we’re interacting with them very closely and one at a time. But, we often have to deal with things like personal email addresses, where they’re signing up for the product as a company, but using their personal email, so, I spend about 10 or 15 minutes just discovering who the person I’m dealing with even is.

David: Yeah, I mean, we definitely see that a lot, and it’s actually not just personal email addresses, you know, they’re actually probably trying us out in the context of personal accounts to begin with, or personal, you know, maybe they’re coming to bring a personal project like their blog, or something like that, to begin with, and they want to like, ‘Yeah, is this thing going to work, before I actually start to try and introduce this at work?’

Steve: Yeah, and you’re trying to demonstrate value in an environment that, one, is not the intended environment, and two, might have totally different requirements around it. And, you know, for us at Amazon for example, we’re dealing with people’s personal accounts that have things like EC2 Classic support, which has been deprecated, and their production environments at work are a lot less likely to have that, but it’s something that we, as the makers of the product, have to consider just because of how people might onboard into it.

David: Yeah, definitely.

Steve: And even if we’re lucky enough to get somebody’s work email address, we still have to go through the whole test flow, where they put us in their staging environment, and give us a try. And it’s a tough constraint to be in a place where you’re going to have measurably less value, but still have to prove that you can be valuable to the customer.

David: Yeah, they want to see, is this tool going to work for me.

No matter how good your documentation, no matter how good your examples, most people are going to want to actually put their hands on it, and see how it works, and see where it falls down. And any experimentation is sort of like the name of the game for our target customers.

So I think providing some sort of backdraft for that, and making it really easy to play with your product is pretty important.

Steve: Yeah, and really considering how you’re going to provide value in these circumstances where you might be restricted is super important. Although, I have to say, this morning, we had a guy sign up for the product, put us in an environment that had literally nothing in it. It was an AWS environment with 0 instances and 0 groups, and we’re a product that health checks other things in the environment, and there was nothing to health check. That was a tough sell.

David: Now he knows that you’re not going to take down his Amazon account, I guess.

Steve: Yeah, and that too, the security check, right, like, half of the battle is convincing people that, one, you’re not going to break, two, you’re not going to break their stuff.

David: Yeah, I think, and that’s certainly another driver for why people try with their personal accounts first, right? It’s like, ‘I’m not going to install this tool into my production account at work that I don’t know anything about.’

Steve: Yeah, it’s been really funny actually to watch this, ’cause we do a lot of onboards in person over video chat, or even just watching their laptop screens, and we’re dealing with incredibly smart people. They watch, and they can see what our onboarding process is doing to their environment, and they go and audit everything, they’re checking every change to preferences, and they know exactly what’s happening. And they check us on everything, which is, you know, worrying, but also kind of cool to see just how good they are at what they’re doing.

David: We basically, we get the same thing, people trying to install us into their actual Amazon account, it’s a pretty tough sell, we’ve had a lot of luck getting early users to just either create a new Amazon account and install everything there. Or we actually, we will create a whole bunch of, we pre-create a whole bunch of Amazon accounts, and just hand them out to people to let them start trying stuff. Anything we can do to reduce the amount of stuff that they have to do to get in and get experimenting, I think is really valuable.

Steve: Yeah, that’s a really good point. Something we’re not doing yet at my current company but we’ve done in the past is create these real demo environments, where, you know, without creds even, people can try the product out online and get a sense for what it will be like without signing up, which has been a really useful tool for me in the past.

David: Yeah, it can be pretty tough to do that with developer tools, just because, you know, you are talking about complex integrations in a lot of cases, but yeah, I think hugely valuable, when you get that right. If I’m a couple clicks away from actually playing around with the product, and maybe even a couple more clicks from you know, taking what I’ve been playing with and going live with it, any friction you can reduce in that path is going to help.

Steve: Yeah, that actually raises an interesting point about the transition over the last few years from how enterprise software companies used to sell to how they seem to be selling now, which is the transparency, that now, things like pricing, and a real sense of what the product does. It all sounds pretty basic, but, these were things that you wouldn’t expect to see, five, 10 years ago. That selling a B-to-B product—you would have a button to contact the salesperson, and you might not even know what the product did on the homepage.

David: Yeah, that’s exactly right, I mean, you still see a lot of that today, and it’s incredibly frustrating as a buyer of software to run into one of those. We try and keep in that in mind a lot when, from the other end of that it’s knowing how much it’s going to cost to knowing exactly the value that it’s going to provide for you, and how it’s going to make your life better, is really important.

Steve: Yeah, it seems so obvious just to design your marketing at least so that people know what the product does when they come to your website. I can’t imagine a consumer company dealing with some of these issues, like the problem of multiple environments, and that we get people signing up with personal accounts, or with staging environments that are not the intended use of the product at all, but in order to win these customers over, we have to show value in them.

David: Yeah, it’s tough, I mean, those environments can basically be completely different too, right? Like, my personal IDS account maybe has nothing in common with what my company’s looks like, you know, it’s like almost as if somebody wants to test your iPhone app by installing it on their Android phone at home first. It can be wildly different.

Steve: Yeah, we were actually talking the other day about having kind of a ‘clean up’ button, where because we know so many people are onboarding this way, putting us in a staging environment or something first, that, they’ll have to kind of decommission some things and remove some things that they created in that first environment before moving to the other one. And so we’re trying to make that process easier for them too, as part of our onboarding. Which just seems ludicrous, but, it’s funny to talk about.

David: Yeah, it’s almost worth trying to, is there some way that you can, through permission sets or something, like actually introduce them slowly into the production environment in a trusted manner, as opposed to here making them go through this experimentation phase first.

Maybe if it was very guided, it might be possible to pull that off. So, you mentioned dealing with customers sort of on a one-on-one basis, in kind of a very high-touch manner, and that’s something that we’ve had a lot of success with, and we actually think is really important, you know. We have a public slack channel, we invite people to come in, we talk with people all the time, they ask questions about the product, that ask, you know, if they’re having problems, or if they, you know, even questions about Amazon, sort of things that are not even directly related to us, and kind of get a conversation going about that stuff.

It’s been hugely valuable to have that kind of real-time, you know, I can just ping somebody and kind of get to know our customers individually, and know what they’re building, kind of the problems that they’re having, and that’s been really helpful.

Steve: Yeah and, not only that we get to interact with them in real time, but we have a way of reaching out to them, and that, one of the issues we have, I think, as an early-stage company is that people are trying the product, they’re not necessarily engaged with the product, and they may not tell us about that.

And so, having every possible way to reach out to them, but also then making part of our onboarding process actively reaching out to them during this process, and making sure they’re getting value, and seeing if they’ve found bugs, and just doing everything that we can on our side to make sure that they’re happy and engaged.

David: Yeah definitely, I think, I mean reaching out, kind of keeping the engagement level high, and reaching out constantly, like, you almost always have to solicit feedback. I mean, you’ll get some really awesome customers that will come and tell you everything that’s wrong with your product, and those are great, but, for most people, you have to actually solicit that feedback. A lot of the best learning we’ve done in our onboarding process, and finding where the friction is, is just talking to somebody and seeing the questions they ask, you know, sometimes they’ll be like, completely off base, or weren’t even in the ballpark of things you were expecting them to ask, you know, you’re expecting them to ask, ‘How does something work,’ and they’re asking, ‘What does this thing even do?’

Steve: Yeah, I think you raised two really interesting points there: one is like, when I was new to this, both new to startups and new to designing technology products, I used to take offense from that feedback. ‘How dare you criticize my work.’ But, as you were saying,

The most vocal customers are the best ones. The ones who are going to tell you about every single bug, I cherish that now. That’s what we look for in our Beta customers.

David: Two reasons: one, it exposes all of the things that you hadn’t seen, and two, those customers are actually your biggest opportunity to make them successful. If they’re engaging with you enough to tell you what’s wrong, they want it to work badly enough that you can just help them a little bit and they’re going to be great.

Steve: Yeah, totally, if nothing else, if they’re complaining it means they care enough to complain, and like we were talking about earlier, partly because our onboarding processes tend to ask a lot of our customers, and because that can take significant time, it’s really on us to engage with our customers and figure out how we can help through that and how we can make it easier for them, and so, because of the burden on them, it’s a big thing for us to both learn how we can make that better, and also help them help customers through it as best we can.

David: One of the interesting things that we’ve been seeing is that we get not only really technical people coming through our onboarding process. We get some very technical developers that kind of understand the basics of what’s going on, and they have one set of questions.

We get other people that are maybe a development manager, or, in a lot of cases, I had one ops guy and he’s now AWOL and I can’t get in touch with him, and I just need help, and they have a completely different set of things that they’re looking for when they come to talk to us. It’s been really enlightening to be able to talk to all of those groups, and kind of see what it is that they’re looking for, because it’s very different.

Steve:  Yeah, we, in speaking to the different kinds of people using the product, there seems to be a transition happening in that way dev teams are set up. And so, we’re dealing sometimes with developers, sometimes with operations people, sometimes people who identify as DevOps, and it’s almost like we have to learn something about the organization first, how their team is set up, and how they deploy infrastructure to even get a basis for the level of conversation that we’re having. And the level of knowledge—yeah, like you were saying, it could be anyone from a manager, I even had a couple of product people contact me. And so yeah, just establishing how the team is set up has been really important to figuring out how to talk with our customers.

David: Yeah, understanding who makes decisions about that kind of stuff, understanding how new technology is deployed at their company, you know, it’s different for everybody. Like, some people are very gung ho, they just take new stuff and go crazy with it all the time, and some companies are very conservative, and it’s a lot different to get sort of the new shiny things rolled out for them.

Steve: I think the contrast of, and we were talking about this a bit earlier, broad vs. deep, and open source vs. SaaS, so I think, Convox’s case is really interesting because you’ve got both an open source product and a SaaS product. Can you talk a little bit about the contrast and the priorities of designing those two products?

David: Sure, yeah, I mean, so, it starts right at the beginning. Like you mentioned, we have the open source, we have SaaS, our SaaS product is not open source, so, there’s just fundamentally different ways that we work on those projects even, you know, with the open source we work in the open. We do a lot of discussion with the community before we make changes, you know, pull requests, and trying to get a lot of people involved in the changes and make sure we’re taking all kinds of viewpoints into account that is going to be useful for a broad range of people.

And then, with the SaaS layer we’re basically saying, ‘Okay, we know have this opinionated, this is how you should be using this, and this is we’re going to codify the happy path, the way that you, the easy, couple-of-clicks way into the product that uses all of this crazy technology that we’ve built.’

Steve: Yeah, and the contrast there is really interesting because open source tools almost by definition have to appeal to a wide audience, you want as many people as possible adopting them and contributing to them. That’s I think a big part of how they develop traction is you get an engaged community of developers who want to help, and SaaS almost seems the opposite, that, a really common startup mantra is this: ‘Make a few customers love you as opposed to a lot of people like you,’ and so, making a great, polished experience for a much smaller number of people seems really important to developing a SaaS business.

At Opsee we’re dealing with this too, we’re only SaaS, we have no open source component, and so we really are trying to focus on a narrow set of use cases, and then make them as polished and perfect as possible, and we are competing with open source tools. So, sometimes we will see these responses like, ‘Oh, why would I pay for your tool when I can get the open source for free?’ But then there’s this back and forth about the development time required to customize it, and the different nature of those kinds of tools.

David: And operating it, you know, it may be free, but somebody has to run it, somebody has to write a page up for it, and it’s easy to lose sight of that stuff.

If you’re interested in being a guest on the show, or if you have a DX topic you’d like us to dive into you can reach us at dmmc@heavybit.com or @dontmakemecode.