# Lessons From Manually Onboarding Our First 50 Customers – Ben Orenstein – MicroConf 2016

Channel: Rob Walling
Video: https://www.youtube.com/watch?v=ToERsBjm2Q0
Duration: 11 min
Language: English
Words: 2340
Transcript page: https://viewrankai.com/tools/youtube-transcript/ToERsBjm2Q0

---

[0:11] Hello. Hey MicroConf. How's it going? So, I'm super excited to talk to you. I can't wait to get started, but before I do, I want to do something a little bit weird. So, would you please, at the very instant when my hands come together like this, would you please all clap at that exact same time? We're trying for a synchronized clap. Let's try it real

[0:29] quick.

[0:34] Good?

[0:41] It's all right. Everybody falls for that one. Don't feel too bad. So, this talk is consists of three stories. These are three true stories that happened to me recently and the lessons that I learned because of them. The first story is about a pivotal moment. So, 2 months ago, I created a brand new

[1:00] business with a good friend of mine. I flew to Austin, Texas. We rented an Airbnb and we coded our faces off for 4 days straight. And after those 4 days, we realized we were ready to bring in our first paying customers. So, we were very ruthless about our MVP. We kept it very simple and we're both pretty experienced programmers, so we

[1:19] were able to launch quite quickly. And we were getting all set to email our list and say, "Here's the sign up link. Let us know what you think." But on a whim, I decided, "What if What if we just onboarded a couple people manually while they were sharing their screen with us? Just so I can double-check and make sure that this onboarding flow that I had created was

[1:39] in fact as awesome as I thought it was." Now, I suggested this literally thinking that this would mostly just be a confirmation of how great a job we had done on the UI because I had worked pretty hard on it and I had been very clear and written a lot of text and I thought I I did well.

[1:54] So, we set up six calls in one day. 30-minute call, 1-hour break. 30-minute call, 1-hour break. All day. Uh all people who had never seen the product, but said they were interested in signing up. And during that first call, I had an experience that I think changed me forever in the way that I build software for

[2:15] other people. And the experience I had was I watched a stranger sign up for and try to use my product while I watched. And it turns out that you can't evaluate your own product. You cannot know if it's easy to use yourself because you know it's too well. Everything I thought was totally clear was not. If this person had not been on a call with me, there's no way they would have made it through the onboarding. They would not have become a customer. And this, by the way, was not a non-technical person. I wasn't like

[2:46] misjudging how technical our users were. This is another developer, but still our onboarding did not make sense to him. And so, after that first call, I said to my co-founder, I said, "Chris, I just took four pages of notes. We have to fix some of this before the next call." And so, we coded as fast as we could at for 57 minutes and then for 3 minutes before the next call, we pushed a brand new

[3:07] version out to production. Which is definitely a best practice that all of you should adopt. I highly recommend uh pushing brand new versions of your app right before important demos. Write that one down, Kai, please. Um And so, the second call, uh the good news was we had not introduced any major bugs. Nothing blew up. The bad news was we didn't actually improve the onboarding. All the stuff that we had fixed that we thought would make a difference did not. And that's when I learned that it's also hard to evaluate if you're making progress until you actually watch a user go through the new

[3:37] flow. After the second call, we had a little more luck. We made some different changes and made some different tweaks and reordered some things and suddenly the third call went a lot better. I got fewer questions. It took less time. Things made sense to this them. And the fourth, fifth, and sixth calls with each

[3:55] one was better than the previous. And so, there are a couple takeaways I'd like you to have from this very first story. The first of which is, if you have not watched a stranger sign up for and try to use your product, you absolutely must do this. And you're going to cry. It's going to be unbelievably painful. I promise you. You do not know the weird bugs that people are hitting in your flow. You do not know how ridiculous your site looks in Firefox on Linux. I like you don't know that your site doesn't work with the password manager they happen to use. There's so many

[4:28] little edge cases and interesting things and parts that you thought were totally clear that are actually not clear. And so, I promise you you will cry at the money you've left on the table. The good news is I have two pieces of good news. The first is that you actually don't need to spend a huge amount of time on this because three or four users will show you the biggest problems. The biggest problems will become clear fairly quickly. And additionally, the things you can do to fix them are actually usually somewhat simple. So, Chris and I had really great luck. We had the most leverage from making sure

[4:57] that two things were correct on each page and very clear. One was the page title, the H1, and the other was the button text. Because when a new when a person hits a new page, they will usually read the title and they will usually read a button before they click it. Usually. So, this brings me to my next story because while people do read those two things, they do not tend to read much of

[5:20] your copy. So, this story is about a question. So, the business that I launched that I've been talking about is called Briefs. Uh it's a little bit like audio Twitter. It's for making podcasts where each episode is limited to 3 minutes. And so, as part of the sign up flow, we'd ask people three questions. What's

[5:35] the title of your podcast? What's the description of it? And what cover art would you like to use? And in my mind, this is going to be the easiest screen in the onboarding. I expected no problems on this. But can anyone guess the question that I got from nearly everyone that hit this page?

[5:53] Can I change it later? That's what everyone asked. Can I Can I change these settings later? And so, I would say, "Ah." I heard that question a couple times and I said, "I know. This is an objection. And the way you deal with objections is you write some microcopy." And so, I wrote a line beneath the title of the page that said, "Don't worry, you can change these

[6:08] settings later." And I onboarded a couple more people and I got the same question continually. People would miss it. People would ask me, "Can I change this later?" with their mouse partially obscuring the sentence that said, "Don't worry, you can change this later." This is This is true. I added again, so I said, "Maybe I'll just double it. If I put it on there twice, people will see it. I'll put it above the submit button." Didn't work. People missed it. And then I said, "Ah, I will be a clever UX ninja. I'm going to put it as the placeholder text inside the form fields. So, that when you see

[6:37] podcast title, the next thing you see right next to it is you can change this later." And now I set it beneath the title and then three times, one for each field. I promise I swear this is true, people would still ask me, "Can I change this later?" This, by the way, is a problem I would not have known if I hadn't been manually onboarding these people. But so, at that point, I stepped

[6:52] back and said, "Okay. I could pull out all the stops and eventually make this thing so unmissable that people will stop asking me this. But what's the core problem here?" The core problem is anxiety. I'm asking people to name their podcast. The last thing that most people were asked to name was their child. Right? This is like it feels like a big decision. And so, I decided instead, I I asked myself, "What if we just defaulted this? I know from a previous step that this person's name is Mary Smith. Why don't I just call it Mary Smith's podcast, put a reasonable default description, and give them some some uh

[7:27] plain cover art? And just rip this page right out of the onboarding flow, get them to success quicker, and reduce that anxiety." Because there's something weird in the human psyche. People do not have the same amount of anxiety around editing something that already exists. If you ask them to create something fresh, it feels scary. It is less scary

[7:45] to edit something that's already there. Don't know why. It just seems to be how we're wired. So, my takeaways from this these these two stories are defaults are great. If at any point in your onboarding flow, you can just default something in, I highly recommend you do it. And the second thing is uh people skim. You are writing copy on your pages and explanatory things and you think people are reading this and when you watch them use your app, you will discover they are absolutely not. People skim skim aggressively. They want to read as few

[8:14] words as possible to get the job done. If the text isn't in their way or they're not stuck, they're not going to read. And you'll see this this borne out if you if you do this testing. So, this brings me to my very last story. Now, this is MicroConf, so I feel like I would be remiss if I didn't talk

[8:27] at least a little bit about money. So, as I was doing these calls, I would be on a Google Hangout with people and my co-founder would be sitting at a kitchen table out of sight with his laptop open listening. And often uh this is in the very early days, our pricing page was not public. We were telling people a rough range of what we expected to charge for the plans, uh but we didn't have the pricing anywhere public. And so, on the calls, I would say, "By the way, what are you expecting to pay for this?" And they would throw out a number and usually we

[8:54] were roughly right in line, but sometimes they would say a number that was like twice as much as we were planning on charging them. And I was like, "Oh, this is opportunity. We're leaving money on the table by charging these people less than they're willing to pay." And so, we said, "Would it be possible to write our app in such a way that we could change our pricing so fast that when they tell me they're willing to pay X on the call, we can change it in 30 seconds before we

[9:16] even get to the pricing page?" And the answer is yes. So, you can do this and we did do this. So, the way our our we deployed to Heroku and we set our Stripe plan names and dollar amounts with Heroku environment variables, which you can change without deploying any new code. Now, we never ended up doing that little thing where we like would change the

[9:41] price right before someone got there. That felt a little bit scammy. But what we did use this for is to experiment like crazy. So, Patrick was up here yesterday telling us we should be experimenting with our pricing and changing it every 3 to 6 months. But if you know it's going to take you a week to try to a new pricing point, you're probably just going to not do it, right? Like if it's just a pain, you're probably just going to push it off. I think of this a little bit like the gym clothes thing, or if you want to go to the gym in the morning, it's a really

[10:06] good idea to put the gym clothes out ahead of time and pack the bag and get everything all set up as it should be, because when the thing that you know you should do is easier, you do it more, even though you know you should be doing it. So, I would encourage you to ask yourself, how long would it take me to

[10:20] change my prices if I started right now? I would not be shocked to learn that there are many of you in this room where the answer would be about a week. I would not be shocked to learn that 3 days, maybe I I guess that the median would be about 2 days in this room if we actually looked at it. I would encourage you to get to the point where you can change your prices without deploying

[10:36] code. That's how you know you've got it. I change my prices with a single line in the terminal. Takes me 10 seconds. So, I think it'd be awesome if you could get there, too. So, that is my talk. Those are my three stories. I hope this has been useful for you, and if not, you can always change

[10:49] this later. Thank you.

---

About this transcript
Read from YouTube's own caption track and laid out by ViewRank AI (https://viewrankai.com).
ViewRank AI finds the videos already beating a creator's own average on Instagram, TikTok and YouTube Shorts, transcribes them from the audio itself in more than 60 languages, and turns what worked into new ideas and scripts.
Free transcript tools, no account needed: https://viewrankai.com/tools
How to read any video this way: https://viewrankai.com/llms.txt