Artwork

Content provided by Patrick McKenzie and Keith Perhac. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Patrick McKenzie and Keith Perhac or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Kalzumeus Podcast Episode 9: Customer Onboarding With Samuel Hulick

1:15:54
 
Share
 

Archived series ("HTTP Redirect" status)

Replaced by: www.kalzumeus.com

When? This feed was archived on December 27, 2016 06:31 (7+ y ago). Last successful fetch was on September 22, 2016 05:26 (7+ y ago)

Why? HTTP Redirect status. The feed permanently redirected to another series.

What now? If you were subscribed to this series when it was replaced, you will now be subscribed to the replacement series. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 51702781 series 10661
Content provided by Patrick McKenzie and Keith Perhac. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Patrick McKenzie and Keith Perhac or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

Samuel Hulick, one of the guys I trust most with regards to SaaS user onboarding, joined us for this episode of the podcast. I met Sam first when he was writing a book on the topic. The best evidence I can give you for the proposition “Sam knows more than the vast majority of people about user onboarding experiences” is the fact that he’s written up 25+ of them publicly (e.g. Basecamp’s) and that the writeups are of very high caliber. Check them out sometime.

[Patrick notes: The transcript below has my commentary inserted like this, as usual.]

What you’ll learn in this podcast:

  • What mistakes SaaS companies frequently make with regards to user onboarding.
  • How to start preparing users for success pre-signup, using site copy and appropriate expectation setting in marketing.
  • How SaaS companies often botch product tours, and how you can make yours serve the user rather than serving the product team.
  • How to use lifecycle emails to make customers more successful.
  • How organizational issues at SaaS companies often directly cause problems in the artifacts given to customers, and how you can avoid this.

Podcast: Customer Onboarding

MP3 Download (~75 minutes, ~110MB) : Right-click here and click Save As.

Podcast format: either subscribe to http://www.kalzumeus.com/category/podcasts/feed in your podcast reader of choice or you can search for Kalzumeus Podcast in the iTunes Store.

Transcript: Customer Onboarding

Patrick McKenzie: Hideho, everybody. This is Patrick McKenzie, here with the ninth episode of the Kalzumeus Podcast. Our guest today is Samuel Hulick, who is behind useronboard.com. My usual co?host, Keith, couldn’t make it today.

I moved down to Tokyo recently [Patrick notes: And will talk about that more some other day.], so it’s a bit of logistical nightmare getting everybody together, but hopefully that’ll work out itself over the next couple episodes. Anyhow, it’s great to have you here, Sam.

Samuel Hulick: It is wonderful to be here.

Patrick: I think today we’re just going to talk a little bit about what you’ve noticed in your experiences as a consultant/author on the topic of user onboarding, what software companies typically do well, do poorly, how they can improve on it.

Also, on a meta-level, I’d like to ask about your experiences of building up the reputation as an expert in this emerging field of dev?related topics, and how that’s worked out for you personally in your career. Sound good?

Samuel: I would be delighted to cover all of that.

Patrick: Awesome. I guess, first question. Sam is one of the few people I trust on the topic of user onboarding. I trust Sam largely because he’s done maybe 20 public tear?downs of websites, saying, “Hey, this is a SaaS company. I signed up for their product.”

He makes copious screencasts/screenshots of the product during the onboarding phase. If you’re not familiar with that term of art, onboarding is basically the experience immediately after you sign into the product for the first time. It’s analogous to unboxing in the retail world. Sometimes we call it the first?run experience, too. Anyhow, onboarding is getting someone shoved into the software.

Sam did public tear?downs about this for various websites, ranging from Gmail and Basecamp, down to no?name websites like mine, and just highlighted, “OK, here’s what they’re doing well. Here’s what they’re doing poorly. Here’s what my recommendations would be for doing it better.”

One of the things that I noticed as I was reading a lot of Sam’s write?ups is that they’re really, really good. These are the sort of things that I used to do for consulting clients. Mine were not nearly so in?depth or detail?oriented. I would just say, “I A/B tested things around this before.”

I would do X, Y, and Z, but I had no, really, theory of the mind of the customer that was informing X, Y, and Z, where Sam is much better at the theorizing behind it. Anyhow.

[Patrick notes: I think I was excessively self-deprecating here with regards to not having a theory of the mind.]

Samuel: I’m honored that you think so.

Patrick: After building you up so much…

Samuel: [laughs]

Patrick: What’s the general takeaway for software companies about our onboarding processes? What are the easy ways that we fluff things up right now, and how can we do that better? Hmm, that sounds too generic, but let’s roll with it anyhow.

How You Structure Your Teams Spills Over Into How Your Product Is Experienced

Samuel: I think that probably the biggest mental hurdle to get over ?? well, a couple things. One is I oftentimes will look at how the organization is organized. There’s the term Conway’s Law, which is that the output of a team will be reflecting the way that that team was organized. If one department doesn’t talk to another, the parts of the application that they’re in charge of will likely not talk to each other. Things like that.

[Patrick notes: This observation is almost painfully on-point at larger software companies.]

I find that a lot of times, when you’re looking at how a product is produced or how it comes to be, there’s typically a marketing department or team, where they’re organized around driving awareness and acquisition, sign?ups, and whose responsibility just ends after sign?ups a lot of the time.

Then you’re looking at a product team, where they’re driven around creating new features and driving ongoing engagement. There are often really any humans in the organization that are really incentivized around bridging the gap from sign?ups to highly engaged users.

Much of the time, if there’s an onboarding issue in the user experience, it’s a lot of times derived from the way that the teams were split up to begin with.

On top of that, a lot of times, onboarding seems to be something of an afterthought. I look at a lot of similarities between onboarding in a product, like a SaaS product, and tutorials in a video game.

[Patrick notes: I would explicitly point out Blizzard games or the Half-Life series, which quite literally have this down to a science. Play the first 5 minutes of Diablo 3 or World of Warcraft or Hearthstone or Half-Life and observe how they’re simultaneously effective at telling a story, manipulating the player’s emotional state, and also introducing several core UI elements of a piece of software whose user-visible complexity rivals that of MSWord or MySQL.]

A lot of times, people seem like they get really carried away about making the “core” game, or the essence of the software product, without really looking at the problem to be solved as, how do you even get people engaged, to begin with?

I wouldn’t say that onboarding is necessarily something that I would recommend waiting till the very end, when all the resources and time are exhausted and trying to staple something on after the fact.

I would really look at your product as the essence of what you’re doing is creating some amount of success in people’s lives. The onboarding process is getting people transitioned from a situation that’s probably frustrating them, because that’s why they’re trying out a new product, to a situation that they’re a lot happier with. Then, they pay you money for that pain relief.

That is my general take on the matter, as a brain-dump.

Patrick: Sure. I largely agree with everything in that general take. It’s something that I often went to clients and other people in the SaaS industry and try to impress upon them.

Again, for reasons like you were talking about with Conway’s Law, and the fact that this is not tracked anywhere in the organization, most companies are unaware of this.

Depending on the SaaS company, if you have a free?trial sign?up model, where folks can have a way of testing your software out, somewhere between 40 and 60 percent of the people who start a free trial will never log into the software a second time. They get that one free?trial experience, and then they’re out of there.

Given that the first five minutes of the use of the software is all a lot of people are ever going to see, you really have to make that first five minutes absolutely sing if you’re going to convince, literally, half of the market for your software that they have to do just a bit more work to get the change in their life that your software is promising to them.

[Patrick notes: I occasionally experience pushback from the phrase “change in someone’s life”, but I honestly think that that is about where we should aim as software entrepreneurs. You don’t need to have the impact of a religion or their spouse, but you should be at least aiming at “washing machine.” Take a person who has never had a washing machine, introduce them to a washing machine, bam, that is a major improvement in their quality of life. That is, approximately, how much you want to revolutionize a business process with your software offering. (Or you can try to do it in B2C, but it’s really, really hard, and I only recommend doing so if you have a lot of money to spend, for reasons I’ve discussed before.)]

Patrick: Instead of just typing some information into the computer, they’re going to have to go to bat for your software with other people in the organization. They’re going to have to change the way they how do some process at their job. They’re going to have to change their habits over months and years to get value out of it.

That long trek to changing those habits and unlocking the value starts with just that first five minutes, so that first five minutes absolutely cannot be a blocker to them.

Samuel: For those listening, I’m nodding vigorously right now. I completely agree. The 40 to 60 percent, I’m very thankful for you making public claims in that regard, because then I get to reference that in my material. Very, very much agree.

[Patrick notes: I’m a little afraid of citogenesis in the Wikipedia sense, so feel free to share stats from your own businesses if they agree or disagree with that range. It is my rough rule of thumb for B2B apps sold on a low-touch free trial model.]

Samuel: I would also say, one thing that you touched on is it’s really important to make those first five minutes really great, but at the same time, I wouldn’t constrain the definition of onboarding to just that first?run experience. A lot of times, when I see onboarding done really well, it’s because they have a really smart automatic?trigger life?cycle email campaign that follows, or things along those lines.

Then also, even before sign?up, just orienting people around the value that your product offers and setting expectations and guiding their motivation and momentum in the right direction. If you think you’re signing up for one thing and you’re getting another, that’s an onboarding problem, but certainly the heavy weight could’ve been lifted long before that person signed up.

Patrick: I have a priceless anecdote about that, actually. Everybody does experiments, right, with traffic channels, different acquiring customers, whatnot. I presume they won’t be too mad at me for talking about this.

Fog Creek has FogBugz, which is a bug?tracking product for developers. Due to an AdWords campaign at one point, Google was sending people to the landing page who were looking for things like [bug for tracking boyfriend’s car].

[Patrick notes: Back in the day, I did occasional consulting for Fog Creek. Assume that I caused this problem.]

The landing page, at the time, did not disabuse someone of the notion that FogBugz was the right product for them. They got some very interesting feedback in the customer support channel about, “I don’t see how I track my boyfriend’s car,” “How do I start tracking my boyfriend’s car?” et cetera.

Samuel: [laughs]

Patrick: You can think of that as an onboarding problem. Obviously, the solution was tightening up our Google campaign so that we’re no longer paying them a lot of money to send people who want to do various illegal activities with software. Setting expectations is really important.

I like that you mentioned life?cycle emails. Some of the best individual wins that I’ve seen companies get are just circling back with someone in an automated or semi?automated fashion, a day or two after them signing up, and saying, “Hey, you signed up for blah the other day, but it looks like you haven’t gotten around to using it. Here’s how to get started.”

Then you’re giving them X, Y, and Z, where if you can, X, Y, and Z are triggered based on their actions in the app. For example, hypothetically, if I was writing one for GitHub, and somebody had signed up for the paid version of GitHub, but 48 hours later they didn’t have a single repository in their paid version of GitHub, I might ping them and say, “Hey, thanks for signing up for GitHub.”

“Github the place where you want to get all your source code, but you don’t have your source code in yet, so here’s how you can start by getting your source code into GitHub. Or maybe that isn’t your job. Maybe that’s someone else’s at the organization. Here’s how to give them the instructions they need to start using your company’s new GitHub account.”

Samuel: I completely agree. I think that looking at what are the external pressures that are forcing that person to be trying out new software to begin with, and being as aware of those as possible, is a total no?brainer.

Especially B2B software, understanding who’s the person who needs to sign off on this check being cut, is there an IT review of some sort that needs to happen, can you create a PDF that they can slide across the desk to their boss that explains the ROI of your product instead of hoping that they can come up with something clever on their own ?? those are all things that I would highly recommend doing, for sure.

Patrick: That ROI calculation is priceless. I actually do that in a scalable fashion for Appointment Reminder. Somebody, several weeks into a trial, once emailed me when I said, “Hey, your trial is coming towards the last couple of days.”

Since I have their credit card already, it’s just like a courtesy notification, like, “Hey, we’re going to charge you in three days. If you don’t want this to happen, cancel now.” That is not actually the copy I use, but that’s the sense of it.

They wrote me back and said, “Hey, Patrick, really appreciate the email. I’ve got a question. My boss is asking me for an ROI calculation on this software. I don’t know what ROI means and I don’t know how to calculate it. Can you do that work for me?” I’m like, “Well, since it’s going to help you pay 80 bucks a month for my software, I can certainly help you out for that.”

I attached an Excel spreadsheet, where I made some assumptions about their level of use of the software based on what I had seen in the database about them and assumptions on their cost structure as a business. I said, “OK. It turns out that this is saving you,” make up a number, “$500 a month. It only costs you $100, so that’s an ROI of 500 percent.”

Then, right after I sent that email, I’m like, this calculation is generalizable to everybody, and there’s approximately nobody who would hate hearing that they’re getting 500 percent ROI. I just changed the email that they’d gotten that eventually prompted them to ask about ROI, such that the computer automatically calculated the ROI if they were getting a happy number.

[Patrick notes: Maybe this would be easier to understand with a visual aid? Here’s the “trial progressing well” email, which goes out on day 20 for trials which the system has heuristically decided that the customer is likely happy with Appointment Reminder. I’ve taken the liberty of marking it up a bit to direct you directly to the ROI-focused portion.

Appointment Reminder ROI Calculation in Email

]

If it calculated the ROI and they were getting an unhappy number, it instead sent them a second email, which was ?? informally, it’s called “trial unsuccessful,” although that’s not actually in the email to them.

It basically says, “Hey, I’m a small businessman. I understand that sometimes I want to do something in a given month, and life just gets so freaking busy, and I’m not successful with getting that done this month. I totally understand how that might’ve happened to you, too. If it did, drop me an email. I’d be happy to extend your trial by another month.”

Maybe a quarter of people who get that email will write me back and say, “Hey, I wanted to use it. I just got busy. Can you extend my trial?”

Then that gives me an opportunity to both talk to them, figure out, if there was an issue with Appointment Reminder, how do I fix it such that they won’t need the second month. Also, the value of a trial that bounces out of your system is zero. The value of a trial that’s still in your system is nonzero.

To a first approximation, it’s always to your advantage just to give people the extra trial, especially if you don’t advertise that you’re doing that ?? which, oops, I just told the podcast with 40,000 people, but none of you will pay me money so it’s fine.

Samuel: [laughs]

Patrick: Life?cycle email is where it’s at.

Samuel: I concur. Yeah.

Patrick: One of the things that I see trip up folks a lot when they’re doing onboarding is sometimes the folks who are in charge of onboarding ?? and this goes back to your organization point ?? might not be the folks in charge of product.

Prior to customer.io and ?? shoot, what’s the other dot?IO company? Intercom.io, which gives people who are less technical the ability to set up these complicated life?cycle email chains without having to necessarily dig into the code of the product to do it for themselves.

A lot of the marketing or customer success teams might have had a little difficulty hooking up life?cycle email. In addition to life?cycle email, what are tools that someone who might not have total control of the technical aspect, what could they do to influence the customer in their onboarding phase?

Samuel: Hopefully I will be able to point to something that I am making sometime down the road.

Patrick: Oh, please do.

Samuel: In the meantime, I am a big fan of Jonathan Kim and what he’s doing at AppCues. That’s a piece of third?party software that I would recommend people check out.

This maybe is cheating a little bit, but looking at live?chat software, like Olark, just being present in there and understanding where your onboarding experience is breaking down, to me is really, really valuable. Most people who are faced with the onboarding dilemma in their company tend to be more like user experience or product, but just don’t really have the resources to pull it off.

Even if you’re just living in that world and can just say, “Guys, people think that they’re signing up for a bug to track their boyfriend’s car or whatever. Can we just make a copy change or something like that?”

Typically, those can get pushed through. It’s not like it’s a whole new feature, things like that. I would really recommend having live chat in that moment, because you can find out where one person’s going wrong and then make changes that affect the untold thousands of other people that will be following them.

The Fundamental Feedback Loop Of Low-Touch SaaS Companies

Patrick: That is, by the way, just one of the generic secrets of running a SaaS company at scale. You do lots of stuff that doesn’t scale, and then use the stuff that doesn’t scale as fuel for the mass?scalable approaches that affect the rest of the customer base that doesn’t talk to you.

Whether that’s automated email sequences, website copy changes, whether it informs your general marketing strategy, whether it drives changes to the product to make things easier to understand, et cetera.

Samuel: Completely. One thing. I was speaking with Nick Francis from Help Scout the other day, and he made a really great point, which is, even if you’re using your own product or eating your own dog food, you’re not dog?fooding your own onboarding experience. You’re not signing up for your product over and over every day.

A lot of times, you can be pushing out changes over the course of three weeks or three months that change A, B, and E, collide somehow and mess up your onboarding interface and the onboarding experience, but it’s a real blind spot for a lot of people. That’s another big reason that I really recommend getting a live?chat box, like Olark or something like that, installed, just maintaining a presence there.

Patrick: That’s actually a really good point. One of the exercises that I used to go to with consulting clients was, roughly on a quarterly basis, I would have people take out an actual, honest?to?God, physical credit card and sign up for the product. Not on the staging server, not through the API, not using autofilled details provided by the browser. Buying the actual product from the actual production system. Put in a credit card, buy it, and see if everything works, and see if everything was optimally optimal.

I think sign?up flows, purchasing flows, et cetera, they have a great tendency to go stale, because they get implemented by a junior Rails engineer in the first two months of the company, and since they ”work” nobody ever looks at them again, until you break them in such a way that sales go to zero.

Samuel: It’s crazy to me. I mean, you spend so much. Your team breaks their backs to create features that people would bother signing up for, and your marketing department is killing themselves trying to get more and more people to sign up for them, and then looking at just even getting people introduced to that or finding some sort of wins.

Then, even if they defy all the odds and get that far and they’re ready to pay you, like let’s put a ring on this, and then that experience breaks down. It’s super frustrating, so yeah. I completely agree.

Patrick: You would not believe how many times you have really good, passionate product people in a room, these folks who would not tolerate a single comma out of place on a preferences screen, and you put them in front of the credit?card form and ask them to buy their own product.

They put in their credit?card number like it’s written on the credit card, with spaces, and the form blocks them from doing that. “Your credit card number cannot contain spaces.”

Flag on the play. Why are we telling a human to do something that a computer can do better? Let’s fix this.

Samuel: I completely agree.

Patrick: That can be your takeaway. Just take out your credit card right now, try to buy whatever it is you sell.

Anyhow, one more thing on the topic of user onboarding, before we go in a new direction.

Samuel: Sure.

Patrick: I’d like to talk about one of my favorite tactics for improving the onboarding experience, even though it is a bit resource intensive: the product tour. There’s the less?invasive changes you can make to an onboarding process, like changing the marketing copy for the sign?up to establish expectations better, changing the life?cycle email copy or the life?cycle email timing to rescue more of the people who might not have a hundred?percent?successful first?run experience.

Or to not even rescue people but assist them in being more successful with the software, for folks whose decision?making process just naturally doesn’t occur at their company in a five?minute increment.

The more resource?intensive thing that I do for my own products and do for a lot of clients is implementing a post?sign?up tour in the application. I was wondering if you could distill some experiences that you’ve had of doing that with clients, sighting it on the Internet, and dot?dot?dot.

[Patrick notes: Verbal ellipses? Sure, why not.]

Samuel: That is an area, philosophically, I have some issues with it, to be honest. I somewhat hesitate to anti-recommend it, given that you’ve presumably done a lot of experiments and had great success with it.

[Patrick notes: Careful Samuel and all you other guys! I have actually done a lot of experiments about this particular thing, but because there is finite experimental bandwidth and because often we don’t have enough traffic post-signup to get results before the sun goes nova, I will often ship things based on my/the team’s best guess as to what user behavior is without actually testing them. People assume I never do that because I talk about A/B testing so often, but that assumption is dangerous.

I also have to point out that, in the context of user tours, I am aware of ones which were major wins and ones which were “worthwhile to do but won’t make a difference to our overall numbers” and other ones which had to be yanked out of the product at a later date, for a few reasons. Like any tactic, they’re heavily sensitive to the particulars of one’s own use case, one’s implementation ability, and uncontrollable vagaries.]

Samuel: I don’t want to pooh?pooh it out of hand, but I think that there are a couple issues of going down the road of basically what you might call a tool?tip tour or something like that, where you’re spotlighting different parts of the interface or things like that.

[Patrick notes: Tooltip tours are in vogue because they’re comparatively easy to implement, relative to all the other ways of doing a tour experience. Unless you put a lot of thought into what you’re actually getting people to do with the tooltips, they are not value creating. I see many more tooltip tours that are vexatious than ones which, like the Blizzard example earlier, excite the user while simultaneously instructing them on how to get started with saving the world from orcs and poorly managed projects.]

Samuel: One, going back to my initial point of tacking onboarding, stapling onboarding on at the very end of the product cycle, a lot of times, I think people use it to literally cover up user?interface issues that they have. A lot of times, people will use it as a crutch to say ?? I’ve literally seen a button that says, “Create project,” and there’s a tool tip that points to it that says, “Click this to create a project.”

There’s a really wonderful Flickr group that Jason Fried from Basecamp started a long, long time ago, called Signs on Signs, where he takes pictures, or he did at the time, took pictures of a sign in a library that says, “Please be quiet,” and then there’s a sign attached to that sign that points to it that says, “Look at this sign,” or “Attention, please be quiet,” or things like that.

A lot of times, if your interface is messed up, adding more to it that literally points to the parts that are confusing is not something that I would recommend. I would really recommend just fixing it to begin with. There’s that.

I think another issue with tool?tip tours and things along those lines ?? I’ve seen your Appointment Reminder tour, and it does not qualify for this critique, but a lot of others, I think, do ?? is that they’re very focused on introducing people to features or introducing people to parts of the interface more so than they are at guiding people to actually accomplish something.

A lot of times, you’ll see six tool tips that all show up at the same time, and it says, “Click here to do this,” or “When you need to do this, go over here,” things like that. They’re not actually walking you through getting something accomplished. They’re just basically asking you to remember where to go when you’re faced with a situation in which that button would be useful.

[Patrick notes: This is, indeed, a failure case. I pointed it out at one consulting client and asked who to talk to to get it fixed, and was told that nobody “owned” the tour, which is another failure case. They thankfully came to the conclusion that that was suboptimal and tasked an engineer on it.]

Samuel:A lot of times, when I see tool?tip tours done poorly, it’s because they ask people to learn by remembering and not learn by doing, which is not the case with yours.

You focus on one thing at a time, and the entire thing is about let’s just guide you through, hold you by the hand, and get your first appointment scheduled, and understand what it’s like, what kind of phone call you’re going to be getting when that happens, and things like that. I would say, not in your case, but a lot of times, that can be an issue.

Then, one other thing to really look for with tool?tip tours is that they can be, how would I put it, sequentially fragile. There are a lot of times where, if your plan is to get people through maybe a 15?step tool?tip tour workflow, but if there’s an issue where somebody thinks they’re supposed to click on one button, but they’re actually supposed to click “OK” within the tool tip or something like that.

All of a sudden, it disappears. Getting back into it, do you start back at step one, or step seven, where you left off? Things like that. Using that as a highly linear narrative device can go sideways really quickly. That’s another thing to be concerned about.

Patrick: Just in terms of building stuff, when I build out tours, partly because I’m aware of the fact of sequential fragility, there is generally an easily accessible bailout button for the tour at all stages of the process. When somebody bails out, it should probably keep them in a consistent state that doesn’t totally hose their account.

That’s not universal on all tours. Either you give them a wiped?clean account, or, ideally, you would just give them full control over the interface, but keep the state of the account as whatever they were just seeing, to not have the leaky abstraction of, OK, the tour?mode stuff was actually just fake objects created in a fake state that we displayed to you, but it was actually a lie, which is how a lot of them are implemented.

[Patrick notes: Why? Well, since the tour will often involve running through the core use case for the application, it will necessarily plug very deeply into the core workflow / business logic / etc. That is a non-starter at some places, so rather than changing the core workflow / business logic to accommodate a special tour state, they just fake the existence of the happy path of the workflow with smoke and mirrors. Appointment Reminder’s tour, by comparison, is done with maximum verisimilitude (and a whole lot of elbow grease, which involves some hackery deep in the bowels of the application, like a special case in our outgoing phone system which detects Hollywood phone numbers of the (555) 555-XXX format, short-circuits actually attempting to call them as you’re directed to do in the tour, and then simulates the results of interaction by a human with the phone call that would have happened but for the short-circuit).

Samuel: We almost think about, I can almost guarantee that you, myself, and every listener for this podcast has downloaded some sort of mobile app that’s been greeted with a series of welcome screens, and gone swipe?swipe?swipe?swipe?swipe to just get through it to get to the actual thing. Then not know what was covered in the thing that you just skipped over and not really know how to proceed from there.

I would say any kind of intro or tour or anything, create it around helping people make progress and move forward, but don’t absolutely depend on that.

I would design for a null state, where, basically, OK, is it still going to make sense and we’re still going to be communicating the most important things when the dashboard is empty or things along those lines, and not really count on the hand?holding as your only source of orientation and motivation.

Put Better Default States In Your UI For New Accounts

Patrick: Definitely. Speaking of null states, often, if you’re in a project?management app and you have no projects, the first screen will say, “You have no projects.”

Samuel: Right, kind of accusatory.

Patrick: I would always say, rather than saying, “You have no projects,” OK, if you’re in development mode, sure. Whatever. Put that up there, like zero of zero results returned for projects.

When you’re shipping that to actual customers, just a quick, one?line if statement, replace it with a, “Here’s how you can get started creating a project.” Then most people just put an arrow that points to the “add new project” button or they say, “Click above on ‘add new project’ to get started.” Rather than that, I would give a little bit of goal?oriented instruction.

Samuel: 100 percent. The only thing I would add to that is not only prompting them to fill it up with something, but also, “Here’s the value of doing that to begin with.”

Patrick: Exactly.

Samuel: “You don’t have any projects yet, but this is where you’ll be able to see which ones are at the biggest risk of not shipping on time. Click here to add your first one.” Something like that, to me, that’s my general recommendation. Because just changing it from, “You don’t have projects” to, “Click this button to create one,” it’s not making it a meaningful action.

That’s a term that I use over and over again when I’m looking at onboarding experiences. Do I even know what I’m doing, or do I even care about what I’m doing? Can you help me at least get to one, if not both, of those?

Patrick: One of the things I really like is when you provide people with a vision of the future they’ll have if they’re using the software, ideally a vision more focused on them than just focused on your software. For example, I think Baremetrics does this very well.

They’re a company that slurps data out of your Stripe account and presents a variety of metrics for you. My recollection is, when you start using Baremetrics, in the pre?slurp state, it’s got nothing to show you. Rather than showing you, “We’ve got nothing to show you,” they show a grayed?out version of their real stats.

It’s like, “Wow. You can see all of this stuff, except for your business, if you just click the Slurp button and give us however much time it takes to do the Slurp out of your account thing.”

Samuel: That can be like a PNG. You don’t have to build in a feature that has all this mocked out or whatever. Yeah.

Patrick: Is that how it’s pronounced, PNG?

Samuel: I always call it “ping.” I don’t know. Do you just say the letters?

Patrick: OK. Here it’s PNG, but then again, I’ve lived in Japan for the last 10 years.

Samuel: Do you call it a J?P?E?G, or a J?peg?

Patrick: Wow, I don’t know. It’s different than “jiff.”

Samuel: [laughs]

Patrick: “Jiff,” and then, I don’t know. It’s been too long since I’ve been in a Japanese office, despite being here for 10 years.

Samuel: That’s something to celebrate, I guess.

Patrick: Oh, yes. Every day that I’m not a seller man is one more day of actual life. Yay.

Samuel: [laughs]

How Samuel Set Out To Become, And Became, The “User Onboarding Guy”

Patrick: We covered onboarding tours a little bit. We covered a bit of the design of UX when someone is getting started with a product to feel like they can get more success and not just have to do meaningless busywork until they get to the good stuff.

We covered a bit of life?cycle emails and whatnot. I’d be a terrible businessman if I did not mention the fact that if you go to www.lifecycleemails.com, there’s a course from me teaching you how to do that. A little plug.

I mentioned you have the blog at useronboard.com. Maybe blog isn’t the right thing. A site, where you go into this customer?onboarding thing in a bit more detail than people typically do in a blog post, and you do tear?downs of folks’ user?onboarding experiences, the pre?sign?up process, the sign?up process, the post?sign?up process. You dig into what emails they send.

Samuel: Slideshows.

Patrick: I thought this was really, really smart back when I first got to know you, in that you very clearly said that, “OK, there’s a million UX designers out there. I’m going to be the one that just takes user onboarding and owns that.”

How’d that work out for you? I know you wrote a book on it later, and we can talk about that in a moment, too, but I presume you also do a bit of consulting and whatnot?

Samuel: I would say that going after a niche has been a highly lucrative decision on my part. The consulting and the book sales have both been really strong. Really, it’s been a pretty fun ride.

Patrick: Awesome. Mind if I rewind the tape to a little bit before the fun ride and whatnot? What got you into this in the first place?

Samuel: Interestingly, you were saying that I wrote the book later, but the book was actually what got me into it to begin with. I was a user?experience generalist for years. I was at this weird in?between place.

Looking at things like conversion?rate optimization is not typically something that’s part of the UX wheelhouse, but I was always really, really interested in ?? I think that you’re actually probably a good representative of this mentality of, “Let’s find out what the problems with this flow are and empirically demonstrate that we have improved upon it.”

To me, I guess, the job to be done of what somebody hires a UX consultant for is typically not that. I really struggled with that for a long time, looking at a competing set of passions that were between qualitative and quantitative, so user experience versus conversion?rate optimization, and then the ever?contentious term “growth hacking.” [laughs] Was that as well.

They all embody the same thing, which is aligning your success around your users being successful and paying attention to whether that’s happening and where that’s breaking down, and then being able to measure the impact of the way that you’ve improved upon it.

Let’s see. Where do I even start here? I decided to write a book, because I wanted to take a product to market, but I didn’t want to go six months to a year into developing some sort of a SaaS product and then take it on the chin with a bunch of rookie mistakes about just how to price something or how to create a landing page that sells it or how to have a product launch or things like that.

I thought, instead, “I’ll just have a really constrained product, in the form of an eBook. Surely I can write that in a couple weeks.” Which was, spoiler alert, not the case. [laughs] Then be able to just get my toe in the water by getting something out there and just go through that experience and learn from it.

Very naively, I put up a landing page for the book, and I titled it “Customer Growth.” It was basically all about “Grow your customer by helping your customers grow.” That was the one?liner for it.

A lot of issues there. One, that’s not a thing that people explicitly care about. It’s more of I would have to write a very philosophical thought piece on why people should care about it to begin with, and convince them of the value of the subject, before even convincing them of the value of the book that covered said subject.

The best way I can describe it is nobody was sitting down and saying, “You know what? We have this problem with this thing that I’ve never heard of. I wonder if there’s a book out there on it.”

Patrick: Amen. If you have to convince the market that they’ve got a problem, that may be an option, but you need to have a previous success behind you or a war chest or maybe VC investment. [Patrick notes: But that wouldn’t be my first choice for any of those folks, either! Pick the screamingly obviously high-impact problems first. Plenty are left unsolved.]

For those of us who are just getting into business for ourselves, you should not be targeting problems that you have to explain to people that they have. You should be targeting problems that they know they have, that when they wake up in the morning, it’s one of the one or two things that is keeping them up at night.

That’s a mixed metaphor. One of their one or two top hair?on?fire problems for today. Virtually, every mistake I’ve made in business in terms of product selection has been not targeting those, but that’s another podcast entirely.

[Patrick notes: I do not regret Bingo Card Creator or Appointment Reminder, but if I got a do-over, I’d pick something higher saliency in a tightly defined commercial niche that I would like exploring and knew I had “unfair” advantages in. That would probably be selling software, though there’s an interesting meta question in whether I would be any good at selling software but for the experience of BCC/AR and taking advantage of the doors they opened.]

Samuel: The one thing that I did right, though, was fully committing to getting the book out before I started. As I guess we’ll get to in a second, there were definitely some hard stretches in the middle, where people would ask me how the book was coming or something like that.

I would very truthfully tell them that I was glad that I didn’t know how hard it would be before I started or I never would’ve started. I was equally true about how hard it was, and also equally true about how glad I was that that wasn’t the case, because I was fully committed when I started and I was just absolutely going to see it through.

I put up the landing page, wasn’t really sure how I was going to go about writing the book or establish my expertise. Obviously, Nathan Barry’s information out there was a big source of help and inspiration. He’s pretty email?list?centric. [Patrick notes: For a reason. Email is the secret weapon of low-touch marketing like airplanes are the secret weapon of modern militaries. It’s not a secret at all — if you don’t have them, you’re giving up a tremendous advantage.] I was like, “I guess I should start an email list and see. Maybe I could get up to hundreds of subscribers or something.”

Literally starting at zero, not even having an email list, that was like, “OK, I’ll put up a landing page, get people to sign up.” I had to figure out how were people even going to be getting to the landing page. This was the definition of a cold start, I guess you could say.

As a UX consultant, generalist, at that time, a lot of times I would do something very much like the tear?downs that are on the User Onboard site right now. I was like, “Man. I’m already writing the book,” which is really hard, because I’m a painfully, painfully slow writer, which is another issue. I was like, “Am I going to try to guest?post on other blogs?” [Patrick notes: I did a guest-post tour when I launched my Lifecycle Emails course. I cannot recommend it for generating sales, though for someone with less of a platform it might make sense for audience building. I think I wrote six good essays on the topic for other people, and seen in hindsight, six good essays for my own purposes would be better than six good essays for other’s sites. I think I have about $3k of attributable sales as a result of that, and even if you double the number to count ones which I missed due to the vagaries of tracking, I’d rather have the essays than the money, both for the initial results and for the residual portfolio value.]

Samuel: That’s even more writing on top of writing the book. I’ve heard sometimes you just basically get a really deemphasized link in the byline, and it results in three people signing up. I can’t spend 15 hours on a blog post and hope that that happens.

I was like, “Man, if only I could share these tear?downs that I’ve been doing.” I’d feel weird, because they were commissioned and paid for and not really owned by me. I was like, “Oh, I can just pick a company and not ask them to pay me for it and just do whatever I want with that.”

I just picked a company at random, which was OpenTable, and recorded the experience, and I was like, it just didn’t really come out right. Their onboarding experience is very confusing, or nonexistent, almost.

I had to scrap that one. It was getting kind of late into the day, and I was like, “Maybe I will do this. Maybe I won’t. All right, screw it. I’ll try one other company.” That company, once again, just completely at random, was LessAccounting. Your listeners would probably be ?? it’s kind of in a similar space, I guess.

Patrick: LessAccounting, for those of you who don’t know it, is a bootstrapped software company that is basically a stripped?down competitor to Quicken.

Samuel: There you go, yeah. Also, they seem to really maintain a presence in the bootstrapper community and stuff. That’s what I was referring to.

Patrick: Oh, yeah. It’s a funny little bit of community inside baseball, I think. Sometimes we overestimate how much folks know about the ”scene.” If you hang out at Amy Hoy’s conferences and go out to BaconBiz every year or go out to MicroConf every year, then you’ve run into the LessAccounting guys and you know who they are. (I would bet you that the average Quicken-using accountant or bookkeeper in Normal-Bloomington does not.)

[Patrick notes: I think this is observation is widely applicable. Our community is simultaneously bigger than we realize and yet smaller than we think it is.]

Patrick: I happen to know that for a lot of the world it’s the first time they’re hearing about it right now. By the way, they’re good software. You should use them. A plug. Yeah.

Samuel: Actually, speaking of which, that was back in November of 2013, so not even a year ago, I was one of the people who didn’t know who they were. I’d known them just because they’d been around for several years, didn’t really know that they were highly involved in the bootstrapper “scene,” or whatever that might be.

I was like, “All right, they seem friendly enough, at the very least,” went through, created the tear?down, put it up on SlideShare.

I think it was the end of the day, and SlideShare messed up the formatting and the aspect ratio. I just wasn’t really happy with the product, but I was like, “I’ll just go home and talk to my wife, and tell her I blew another day while I’m trying to get this book out.”

I posted it, and the next morning I got an email from one of the co?founders of LessAccounting. I see it in my inbox as the subject line and see who the email’s from, and I was just like, “Oh, no.” I was sure that when I clicked on it, it was going to be him coming and being like, “Oh, thanks a lot for airing our dirty laundry and pointing out how our onboarding experience isn’t working, and who even are you?”

It turned out to be completely the opposite, that he was like, “Thank you so much for pointing all these things out. We already made a bunch of the changes that you recommended. I see you’re writing a book. How can I help promote it?”

It was just total night and day from what I was expecting as a worst?case scenario, really just a super?supporting response. He wound up featuring it on the LessAccounting blog, and that was really the very first thing that I did that got a decent amount of traffic and a decent amount of sign?ups for the email list and things like that.

Patrick: Awesome. I think this strategy is very generalizable, and in fact, folks have done it in a lot of circumstances, and it often works well. Dustin Curtis is a designer. He basically made his name by taking a few big Fortune 500 company websites, doing redesigns on them.

I might have issues with that particular work product, but that’s neither here nor there. 37Signals, back in the day before anybody knew who they were [Patrick notes: 2002 — Basecamp and Rails were in 2006, I think?], just did unsolicited redesigns of the FedEx application and said, “Here’s all the mistakes that FedEx is making.”

It wasn’t actually FedEx, because I think they were probably worried about getting sued, but it was a purple?looking delivery company.

[Patrick notes: I apparently misremembered this — it appears to actually mention FedEx. Their BetterBank was a better example of a generically attacked problem. Though I’m fairly certain that somebody has done a You All Know Whose Website I’m Talking About redesign without actually using the trademark — can’t recall who at the moment.]

Samuel: [laughs]

Patrick: They just had purpledelivery.pdf, with the redesigned with the purple delivery company’s Web app, which featured package tracking as a first?class citizen rather than the 15th thing that you wanted to use.

Especially, if you do this for other people who are closer to the us?es of the world than the Fortune 500s of the world, folks, often, the first impulse will not be send a cease and desist or be very annoyed at you. It’s like, “Hey.” Folks describe me personally as Internet famous, which is a funny, funny word.

To this day, my heart lights up anytime someone shows any bit of attention to one of my products. If you want to screen?grab everything and show what I’m doing wrong with the world or how my pixels are out of place, I won’t think, “Oh, he’s insulting my pixels.” I’ll think, “Yes! Totally! Someone noticed me! That’s awesome!”

Samuel: Just to briefly touch on the whole unsolicited?redesign thing, I can see how I’m in a similar space as that, but personally, I’m really not a huge fan of unsolicited redesigns as a thing, largely because it’s a very surface problem.

You’re basically saying, a lot of times when you see them, especially on Dribble or things like that, it’s, “I didn’t think this was pretty, so I made it prettier,” where you don’t really know what’s working that well, what’s not, what kind of constraints the team is faced with. You’re probably not even necessarily the primary audience that the product was intended for.

For a lot of reasons, when I’m creating a tear?down, I try to be very, very conscious of the fact that there are real people who had made this under real pressure, and it was to serve a job that may or may not be something that was…I’ll literally go through the sign?up process to create the tear?down.

It’s not like I’m even really genuinely trying to make it work for me in that moment. There’s already that, and maybe I’m not even a key audience member at any point in time. There are those issues.

Then also, I’ve actually had conversation with people, where maybe I’ll say, “Yeah, deciding to do that made me scratch my head,” or “That doesn’t really conform to the “best practices” or whatever that might be.” The design team will be like, “Yeah. Yeah, we hated it, too, but it’s working really well.”

Not having visibility into the conversion funnel or whatever that might be, and then also just not knowing about what kind of internal pressures they’re dealing with in the office, I really, really try to say, basically, “Objectively, these are what our best practices are, or not, considered to be generally within the community.

Then also, anecdotally, as a user, I was legitimately confused when I went through this.” Really, really distance myself from saying, “This is objectively wrong” or anything like that.

Patrick: Right. I think that is a great attitude to have about it in general, and probably a karma?maximizing attitude, if you’re hoping to borrow an audience as a result of publishing these things.

Also, I think, as somebody who has worked in a lot of companies and seen the sausage get made, it absolutely tracks with the internal human/political/resource?based constraints on why something might not be totally optimal. There’s a lot of times where, heck, I’ll own it. I won’t blame the client, I’ll blame myself.

There are something that I have shipped where I could point to you X, Y, and Z decisions of the things that shipped today and say, “I hate X. I hate Y. I hate Z.” I had 100 points of awesomeness in that engagement, where awesome is an arbitrary resource. Fixing X would’ve required 20 points of awesomeness. We just had other things to spend awesomeness on, so we just shipped it out the door.

Samuel: There you go.

Patrick: Often, a particular team or person in the organization just did not want to budge on Y, and they had been really cooperating on some other part, and so you trade tit for tat. That happens all the time in real life.

Anyhow, going back to the book for a moment.

Samuel: Yes.

Patrick: You release some of these tear?downs, and both the folks who were, quote?unquote ?? I hate that word, tear?down, by the way. I’d like to say, “build?up.”

Samuel: [laughs]

Patrick: You released some of this feedback on people’s onboarding processes. Some of the folks who were featured in this feedback found it really, really useful to them, like the guys at LessAccounting.

They spread all over the Internets to these people’s preexisting networks, as they said, “Hey, someone has taken this interest in our business and given us really useful feedback. We could read the writeup.” Thus, you got, what, a few hundred or a few thousand people to subscribe to your email newsletter?

Samuel: Specifically, in the early, early days, it was maybe a couple hundred, when the book was still called “Customer Growth” and people probably didn’t really know what they were signing up to get.

Through the success of the tear?downs ?? so I did the LessAccounting one, and I was like, “Well, that went well. I should do another one.” Then I did Basecamp, and then that one got shared a lot. I think that wound up Designer News, the front page, for quite a while.

At that point, it was suggested to me that I stop using SlideShare and instead create a site that’s dedicated to those, where I could control the conversion timing, the asks, basically. I also just wasn’t really a super?huge fan of the user experience on SlideShare, either.

Patrick: Can I circle this point and star it, guys? There’s a lot of folks who put their best work on 3rd party sites. In my case, some of my best work is on Hacker News. In other folks’ cases, it might be on Dribbble, on Twitter, on Facebook, on Medium, et cetera, on GitHub, a major one for the developer community.

For things that are central to your career, building up a public portfolio, you really want to be able to control all aspects about that, both how the work is presented to people who will be future decision?makers about your career and what you emphasize about it.

If you embed something in GitHub, you’re going to end up with a very GitHub?y experience for that, regardless of what it is. The way that people consume that artifact that you have put on GitHub will be a very GitHub?focused consumption experience rather than a you?focused consumption experience or a them?focused consumption experience.

Samuel: Yes.

Patrick: I would strongly encourage, from both a UX point of view and a “maximizing the future value of your passport to your future self” point of view, that you put your best work on your own darn website. Think about wrapper?type issues, like:

Should I put a logo on it? [Patrick notes: If it represents more than a work-week of effort from you you’d be crazy to not spring $100 or $200 for a logo. I strongly feel like the logo, the dedicated web presence, and the non-zero effort put into documentation for A/Bingo were reasons it redounded to my favor.]

What sort of asks should I be having on the page? Whether that’s asking someone for their email address, or, for those of you who might not be selling a book but might be selling freelance or consulting services, maybe you ask them to send you an email and ask for a quote, or “Send me an email. I’d love to have a Skype chat about this if it interested you.” You convert them and do a request for a quote or something on the Skype chat, et cetera.

Yes, asterisk, asterisk, asterisk. You should absolutely have it on your own website. Which is, by the way, to this day, why ?? well, aside from Hacker News ?? almost all of my writing is on either my own blog or on my other sites. Most of the things that I produce even for free, the canonical source

  continue reading

11 episodes

Artwork
iconShare
 

Archived series ("HTTP Redirect" status)

Replaced by: www.kalzumeus.com

When? This feed was archived on December 27, 2016 06:31 (7+ y ago). Last successful fetch was on September 22, 2016 05:26 (7+ y ago)

Why? HTTP Redirect status. The feed permanently redirected to another series.

What now? If you were subscribed to this series when it was replaced, you will now be subscribed to the replacement series. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 51702781 series 10661
Content provided by Patrick McKenzie and Keith Perhac. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Patrick McKenzie and Keith Perhac or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

Samuel Hulick, one of the guys I trust most with regards to SaaS user onboarding, joined us for this episode of the podcast. I met Sam first when he was writing a book on the topic. The best evidence I can give you for the proposition “Sam knows more than the vast majority of people about user onboarding experiences” is the fact that he’s written up 25+ of them publicly (e.g. Basecamp’s) and that the writeups are of very high caliber. Check them out sometime.

[Patrick notes: The transcript below has my commentary inserted like this, as usual.]

What you’ll learn in this podcast:

  • What mistakes SaaS companies frequently make with regards to user onboarding.
  • How to start preparing users for success pre-signup, using site copy and appropriate expectation setting in marketing.
  • How SaaS companies often botch product tours, and how you can make yours serve the user rather than serving the product team.
  • How to use lifecycle emails to make customers more successful.
  • How organizational issues at SaaS companies often directly cause problems in the artifacts given to customers, and how you can avoid this.

Podcast: Customer Onboarding

MP3 Download (~75 minutes, ~110MB) : Right-click here and click Save As.

Podcast format: either subscribe to http://www.kalzumeus.com/category/podcasts/feed in your podcast reader of choice or you can search for Kalzumeus Podcast in the iTunes Store.

Transcript: Customer Onboarding

Patrick McKenzie: Hideho, everybody. This is Patrick McKenzie, here with the ninth episode of the Kalzumeus Podcast. Our guest today is Samuel Hulick, who is behind useronboard.com. My usual co?host, Keith, couldn’t make it today.

I moved down to Tokyo recently [Patrick notes: And will talk about that more some other day.], so it’s a bit of logistical nightmare getting everybody together, but hopefully that’ll work out itself over the next couple episodes. Anyhow, it’s great to have you here, Sam.

Samuel Hulick: It is wonderful to be here.

Patrick: I think today we’re just going to talk a little bit about what you’ve noticed in your experiences as a consultant/author on the topic of user onboarding, what software companies typically do well, do poorly, how they can improve on it.

Also, on a meta-level, I’d like to ask about your experiences of building up the reputation as an expert in this emerging field of dev?related topics, and how that’s worked out for you personally in your career. Sound good?

Samuel: I would be delighted to cover all of that.

Patrick: Awesome. I guess, first question. Sam is one of the few people I trust on the topic of user onboarding. I trust Sam largely because he’s done maybe 20 public tear?downs of websites, saying, “Hey, this is a SaaS company. I signed up for their product.”

He makes copious screencasts/screenshots of the product during the onboarding phase. If you’re not familiar with that term of art, onboarding is basically the experience immediately after you sign into the product for the first time. It’s analogous to unboxing in the retail world. Sometimes we call it the first?run experience, too. Anyhow, onboarding is getting someone shoved into the software.

Sam did public tear?downs about this for various websites, ranging from Gmail and Basecamp, down to no?name websites like mine, and just highlighted, “OK, here’s what they’re doing well. Here’s what they’re doing poorly. Here’s what my recommendations would be for doing it better.”

One of the things that I noticed as I was reading a lot of Sam’s write?ups is that they’re really, really good. These are the sort of things that I used to do for consulting clients. Mine were not nearly so in?depth or detail?oriented. I would just say, “I A/B tested things around this before.”

I would do X, Y, and Z, but I had no, really, theory of the mind of the customer that was informing X, Y, and Z, where Sam is much better at the theorizing behind it. Anyhow.

[Patrick notes: I think I was excessively self-deprecating here with regards to not having a theory of the mind.]

Samuel: I’m honored that you think so.

Patrick: After building you up so much…

Samuel: [laughs]

Patrick: What’s the general takeaway for software companies about our onboarding processes? What are the easy ways that we fluff things up right now, and how can we do that better? Hmm, that sounds too generic, but let’s roll with it anyhow.

How You Structure Your Teams Spills Over Into How Your Product Is Experienced

Samuel: I think that probably the biggest mental hurdle to get over ?? well, a couple things. One is I oftentimes will look at how the organization is organized. There’s the term Conway’s Law, which is that the output of a team will be reflecting the way that that team was organized. If one department doesn’t talk to another, the parts of the application that they’re in charge of will likely not talk to each other. Things like that.

[Patrick notes: This observation is almost painfully on-point at larger software companies.]

I find that a lot of times, when you’re looking at how a product is produced or how it comes to be, there’s typically a marketing department or team, where they’re organized around driving awareness and acquisition, sign?ups, and whose responsibility just ends after sign?ups a lot of the time.

Then you’re looking at a product team, where they’re driven around creating new features and driving ongoing engagement. There are often really any humans in the organization that are really incentivized around bridging the gap from sign?ups to highly engaged users.

Much of the time, if there’s an onboarding issue in the user experience, it’s a lot of times derived from the way that the teams were split up to begin with.

On top of that, a lot of times, onboarding seems to be something of an afterthought. I look at a lot of similarities between onboarding in a product, like a SaaS product, and tutorials in a video game.

[Patrick notes: I would explicitly point out Blizzard games or the Half-Life series, which quite literally have this down to a science. Play the first 5 minutes of Diablo 3 or World of Warcraft or Hearthstone or Half-Life and observe how they’re simultaneously effective at telling a story, manipulating the player’s emotional state, and also introducing several core UI elements of a piece of software whose user-visible complexity rivals that of MSWord or MySQL.]

A lot of times, people seem like they get really carried away about making the “core” game, or the essence of the software product, without really looking at the problem to be solved as, how do you even get people engaged, to begin with?

I wouldn’t say that onboarding is necessarily something that I would recommend waiting till the very end, when all the resources and time are exhausted and trying to staple something on after the fact.

I would really look at your product as the essence of what you’re doing is creating some amount of success in people’s lives. The onboarding process is getting people transitioned from a situation that’s probably frustrating them, because that’s why they’re trying out a new product, to a situation that they’re a lot happier with. Then, they pay you money for that pain relief.

That is my general take on the matter, as a brain-dump.

Patrick: Sure. I largely agree with everything in that general take. It’s something that I often went to clients and other people in the SaaS industry and try to impress upon them.

Again, for reasons like you were talking about with Conway’s Law, and the fact that this is not tracked anywhere in the organization, most companies are unaware of this.

Depending on the SaaS company, if you have a free?trial sign?up model, where folks can have a way of testing your software out, somewhere between 40 and 60 percent of the people who start a free trial will never log into the software a second time. They get that one free?trial experience, and then they’re out of there.

Given that the first five minutes of the use of the software is all a lot of people are ever going to see, you really have to make that first five minutes absolutely sing if you’re going to convince, literally, half of the market for your software that they have to do just a bit more work to get the change in their life that your software is promising to them.

[Patrick notes: I occasionally experience pushback from the phrase “change in someone’s life”, but I honestly think that that is about where we should aim as software entrepreneurs. You don’t need to have the impact of a religion or their spouse, but you should be at least aiming at “washing machine.” Take a person who has never had a washing machine, introduce them to a washing machine, bam, that is a major improvement in their quality of life. That is, approximately, how much you want to revolutionize a business process with your software offering. (Or you can try to do it in B2C, but it’s really, really hard, and I only recommend doing so if you have a lot of money to spend, for reasons I’ve discussed before.)]

Patrick: Instead of just typing some information into the computer, they’re going to have to go to bat for your software with other people in the organization. They’re going to have to change the way they how do some process at their job. They’re going to have to change their habits over months and years to get value out of it.

That long trek to changing those habits and unlocking the value starts with just that first five minutes, so that first five minutes absolutely cannot be a blocker to them.

Samuel: For those listening, I’m nodding vigorously right now. I completely agree. The 40 to 60 percent, I’m very thankful for you making public claims in that regard, because then I get to reference that in my material. Very, very much agree.

[Patrick notes: I’m a little afraid of citogenesis in the Wikipedia sense, so feel free to share stats from your own businesses if they agree or disagree with that range. It is my rough rule of thumb for B2B apps sold on a low-touch free trial model.]

Samuel: I would also say, one thing that you touched on is it’s really important to make those first five minutes really great, but at the same time, I wouldn’t constrain the definition of onboarding to just that first?run experience. A lot of times, when I see onboarding done really well, it’s because they have a really smart automatic?trigger life?cycle email campaign that follows, or things along those lines.

Then also, even before sign?up, just orienting people around the value that your product offers and setting expectations and guiding their motivation and momentum in the right direction. If you think you’re signing up for one thing and you’re getting another, that’s an onboarding problem, but certainly the heavy weight could’ve been lifted long before that person signed up.

Patrick: I have a priceless anecdote about that, actually. Everybody does experiments, right, with traffic channels, different acquiring customers, whatnot. I presume they won’t be too mad at me for talking about this.

Fog Creek has FogBugz, which is a bug?tracking product for developers. Due to an AdWords campaign at one point, Google was sending people to the landing page who were looking for things like [bug for tracking boyfriend’s car].

[Patrick notes: Back in the day, I did occasional consulting for Fog Creek. Assume that I caused this problem.]

The landing page, at the time, did not disabuse someone of the notion that FogBugz was the right product for them. They got some very interesting feedback in the customer support channel about, “I don’t see how I track my boyfriend’s car,” “How do I start tracking my boyfriend’s car?” et cetera.

Samuel: [laughs]

Patrick: You can think of that as an onboarding problem. Obviously, the solution was tightening up our Google campaign so that we’re no longer paying them a lot of money to send people who want to do various illegal activities with software. Setting expectations is really important.

I like that you mentioned life?cycle emails. Some of the best individual wins that I’ve seen companies get are just circling back with someone in an automated or semi?automated fashion, a day or two after them signing up, and saying, “Hey, you signed up for blah the other day, but it looks like you haven’t gotten around to using it. Here’s how to get started.”

Then you’re giving them X, Y, and Z, where if you can, X, Y, and Z are triggered based on their actions in the app. For example, hypothetically, if I was writing one for GitHub, and somebody had signed up for the paid version of GitHub, but 48 hours later they didn’t have a single repository in their paid version of GitHub, I might ping them and say, “Hey, thanks for signing up for GitHub.”

“Github the place where you want to get all your source code, but you don’t have your source code in yet, so here’s how you can start by getting your source code into GitHub. Or maybe that isn’t your job. Maybe that’s someone else’s at the organization. Here’s how to give them the instructions they need to start using your company’s new GitHub account.”

Samuel: I completely agree. I think that looking at what are the external pressures that are forcing that person to be trying out new software to begin with, and being as aware of those as possible, is a total no?brainer.

Especially B2B software, understanding who’s the person who needs to sign off on this check being cut, is there an IT review of some sort that needs to happen, can you create a PDF that they can slide across the desk to their boss that explains the ROI of your product instead of hoping that they can come up with something clever on their own ?? those are all things that I would highly recommend doing, for sure.

Patrick: That ROI calculation is priceless. I actually do that in a scalable fashion for Appointment Reminder. Somebody, several weeks into a trial, once emailed me when I said, “Hey, your trial is coming towards the last couple of days.”

Since I have their credit card already, it’s just like a courtesy notification, like, “Hey, we’re going to charge you in three days. If you don’t want this to happen, cancel now.” That is not actually the copy I use, but that’s the sense of it.

They wrote me back and said, “Hey, Patrick, really appreciate the email. I’ve got a question. My boss is asking me for an ROI calculation on this software. I don’t know what ROI means and I don’t know how to calculate it. Can you do that work for me?” I’m like, “Well, since it’s going to help you pay 80 bucks a month for my software, I can certainly help you out for that.”

I attached an Excel spreadsheet, where I made some assumptions about their level of use of the software based on what I had seen in the database about them and assumptions on their cost structure as a business. I said, “OK. It turns out that this is saving you,” make up a number, “$500 a month. It only costs you $100, so that’s an ROI of 500 percent.”

Then, right after I sent that email, I’m like, this calculation is generalizable to everybody, and there’s approximately nobody who would hate hearing that they’re getting 500 percent ROI. I just changed the email that they’d gotten that eventually prompted them to ask about ROI, such that the computer automatically calculated the ROI if they were getting a happy number.

[Patrick notes: Maybe this would be easier to understand with a visual aid? Here’s the “trial progressing well” email, which goes out on day 20 for trials which the system has heuristically decided that the customer is likely happy with Appointment Reminder. I’ve taken the liberty of marking it up a bit to direct you directly to the ROI-focused portion.

Appointment Reminder ROI Calculation in Email

]

If it calculated the ROI and they were getting an unhappy number, it instead sent them a second email, which was ?? informally, it’s called “trial unsuccessful,” although that’s not actually in the email to them.

It basically says, “Hey, I’m a small businessman. I understand that sometimes I want to do something in a given month, and life just gets so freaking busy, and I’m not successful with getting that done this month. I totally understand how that might’ve happened to you, too. If it did, drop me an email. I’d be happy to extend your trial by another month.”

Maybe a quarter of people who get that email will write me back and say, “Hey, I wanted to use it. I just got busy. Can you extend my trial?”

Then that gives me an opportunity to both talk to them, figure out, if there was an issue with Appointment Reminder, how do I fix it such that they won’t need the second month. Also, the value of a trial that bounces out of your system is zero. The value of a trial that’s still in your system is nonzero.

To a first approximation, it’s always to your advantage just to give people the extra trial, especially if you don’t advertise that you’re doing that ?? which, oops, I just told the podcast with 40,000 people, but none of you will pay me money so it’s fine.

Samuel: [laughs]

Patrick: Life?cycle email is where it’s at.

Samuel: I concur. Yeah.

Patrick: One of the things that I see trip up folks a lot when they’re doing onboarding is sometimes the folks who are in charge of onboarding ?? and this goes back to your organization point ?? might not be the folks in charge of product.

Prior to customer.io and ?? shoot, what’s the other dot?IO company? Intercom.io, which gives people who are less technical the ability to set up these complicated life?cycle email chains without having to necessarily dig into the code of the product to do it for themselves.

A lot of the marketing or customer success teams might have had a little difficulty hooking up life?cycle email. In addition to life?cycle email, what are tools that someone who might not have total control of the technical aspect, what could they do to influence the customer in their onboarding phase?

Samuel: Hopefully I will be able to point to something that I am making sometime down the road.

Patrick: Oh, please do.

Samuel: In the meantime, I am a big fan of Jonathan Kim and what he’s doing at AppCues. That’s a piece of third?party software that I would recommend people check out.

This maybe is cheating a little bit, but looking at live?chat software, like Olark, just being present in there and understanding where your onboarding experience is breaking down, to me is really, really valuable. Most people who are faced with the onboarding dilemma in their company tend to be more like user experience or product, but just don’t really have the resources to pull it off.

Even if you’re just living in that world and can just say, “Guys, people think that they’re signing up for a bug to track their boyfriend’s car or whatever. Can we just make a copy change or something like that?”

Typically, those can get pushed through. It’s not like it’s a whole new feature, things like that. I would really recommend having live chat in that moment, because you can find out where one person’s going wrong and then make changes that affect the untold thousands of other people that will be following them.

The Fundamental Feedback Loop Of Low-Touch SaaS Companies

Patrick: That is, by the way, just one of the generic secrets of running a SaaS company at scale. You do lots of stuff that doesn’t scale, and then use the stuff that doesn’t scale as fuel for the mass?scalable approaches that affect the rest of the customer base that doesn’t talk to you.

Whether that’s automated email sequences, website copy changes, whether it informs your general marketing strategy, whether it drives changes to the product to make things easier to understand, et cetera.

Samuel: Completely. One thing. I was speaking with Nick Francis from Help Scout the other day, and he made a really great point, which is, even if you’re using your own product or eating your own dog food, you’re not dog?fooding your own onboarding experience. You’re not signing up for your product over and over every day.

A lot of times, you can be pushing out changes over the course of three weeks or three months that change A, B, and E, collide somehow and mess up your onboarding interface and the onboarding experience, but it’s a real blind spot for a lot of people. That’s another big reason that I really recommend getting a live?chat box, like Olark or something like that, installed, just maintaining a presence there.

Patrick: That’s actually a really good point. One of the exercises that I used to go to with consulting clients was, roughly on a quarterly basis, I would have people take out an actual, honest?to?God, physical credit card and sign up for the product. Not on the staging server, not through the API, not using autofilled details provided by the browser. Buying the actual product from the actual production system. Put in a credit card, buy it, and see if everything works, and see if everything was optimally optimal.

I think sign?up flows, purchasing flows, et cetera, they have a great tendency to go stale, because they get implemented by a junior Rails engineer in the first two months of the company, and since they ”work” nobody ever looks at them again, until you break them in such a way that sales go to zero.

Samuel: It’s crazy to me. I mean, you spend so much. Your team breaks their backs to create features that people would bother signing up for, and your marketing department is killing themselves trying to get more and more people to sign up for them, and then looking at just even getting people introduced to that or finding some sort of wins.

Then, even if they defy all the odds and get that far and they’re ready to pay you, like let’s put a ring on this, and then that experience breaks down. It’s super frustrating, so yeah. I completely agree.

Patrick: You would not believe how many times you have really good, passionate product people in a room, these folks who would not tolerate a single comma out of place on a preferences screen, and you put them in front of the credit?card form and ask them to buy their own product.

They put in their credit?card number like it’s written on the credit card, with spaces, and the form blocks them from doing that. “Your credit card number cannot contain spaces.”

Flag on the play. Why are we telling a human to do something that a computer can do better? Let’s fix this.

Samuel: I completely agree.

Patrick: That can be your takeaway. Just take out your credit card right now, try to buy whatever it is you sell.

Anyhow, one more thing on the topic of user onboarding, before we go in a new direction.

Samuel: Sure.

Patrick: I’d like to talk about one of my favorite tactics for improving the onboarding experience, even though it is a bit resource intensive: the product tour. There’s the less?invasive changes you can make to an onboarding process, like changing the marketing copy for the sign?up to establish expectations better, changing the life?cycle email copy or the life?cycle email timing to rescue more of the people who might not have a hundred?percent?successful first?run experience.

Or to not even rescue people but assist them in being more successful with the software, for folks whose decision?making process just naturally doesn’t occur at their company in a five?minute increment.

The more resource?intensive thing that I do for my own products and do for a lot of clients is implementing a post?sign?up tour in the application. I was wondering if you could distill some experiences that you’ve had of doing that with clients, sighting it on the Internet, and dot?dot?dot.

[Patrick notes: Verbal ellipses? Sure, why not.]

Samuel: That is an area, philosophically, I have some issues with it, to be honest. I somewhat hesitate to anti-recommend it, given that you’ve presumably done a lot of experiments and had great success with it.

[Patrick notes: Careful Samuel and all you other guys! I have actually done a lot of experiments about this particular thing, but because there is finite experimental bandwidth and because often we don’t have enough traffic post-signup to get results before the sun goes nova, I will often ship things based on my/the team’s best guess as to what user behavior is without actually testing them. People assume I never do that because I talk about A/B testing so often, but that assumption is dangerous.

I also have to point out that, in the context of user tours, I am aware of ones which were major wins and ones which were “worthwhile to do but won’t make a difference to our overall numbers” and other ones which had to be yanked out of the product at a later date, for a few reasons. Like any tactic, they’re heavily sensitive to the particulars of one’s own use case, one’s implementation ability, and uncontrollable vagaries.]

Samuel: I don’t want to pooh?pooh it out of hand, but I think that there are a couple issues of going down the road of basically what you might call a tool?tip tour or something like that, where you’re spotlighting different parts of the interface or things like that.

[Patrick notes: Tooltip tours are in vogue because they’re comparatively easy to implement, relative to all the other ways of doing a tour experience. Unless you put a lot of thought into what you’re actually getting people to do with the tooltips, they are not value creating. I see many more tooltip tours that are vexatious than ones which, like the Blizzard example earlier, excite the user while simultaneously instructing them on how to get started with saving the world from orcs and poorly managed projects.]

Samuel: One, going back to my initial point of tacking onboarding, stapling onboarding on at the very end of the product cycle, a lot of times, I think people use it to literally cover up user?interface issues that they have. A lot of times, people will use it as a crutch to say ?? I’ve literally seen a button that says, “Create project,” and there’s a tool tip that points to it that says, “Click this to create a project.”

There’s a really wonderful Flickr group that Jason Fried from Basecamp started a long, long time ago, called Signs on Signs, where he takes pictures, or he did at the time, took pictures of a sign in a library that says, “Please be quiet,” and then there’s a sign attached to that sign that points to it that says, “Look at this sign,” or “Attention, please be quiet,” or things like that.

A lot of times, if your interface is messed up, adding more to it that literally points to the parts that are confusing is not something that I would recommend. I would really recommend just fixing it to begin with. There’s that.

I think another issue with tool?tip tours and things along those lines ?? I’ve seen your Appointment Reminder tour, and it does not qualify for this critique, but a lot of others, I think, do ?? is that they’re very focused on introducing people to features or introducing people to parts of the interface more so than they are at guiding people to actually accomplish something.

A lot of times, you’ll see six tool tips that all show up at the same time, and it says, “Click here to do this,” or “When you need to do this, go over here,” things like that. They’re not actually walking you through getting something accomplished. They’re just basically asking you to remember where to go when you’re faced with a situation in which that button would be useful.

[Patrick notes: This is, indeed, a failure case. I pointed it out at one consulting client and asked who to talk to to get it fixed, and was told that nobody “owned” the tour, which is another failure case. They thankfully came to the conclusion that that was suboptimal and tasked an engineer on it.]

Samuel:A lot of times, when I see tool?tip tours done poorly, it’s because they ask people to learn by remembering and not learn by doing, which is not the case with yours.

You focus on one thing at a time, and the entire thing is about let’s just guide you through, hold you by the hand, and get your first appointment scheduled, and understand what it’s like, what kind of phone call you’re going to be getting when that happens, and things like that. I would say, not in your case, but a lot of times, that can be an issue.

Then, one other thing to really look for with tool?tip tours is that they can be, how would I put it, sequentially fragile. There are a lot of times where, if your plan is to get people through maybe a 15?step tool?tip tour workflow, but if there’s an issue where somebody thinks they’re supposed to click on one button, but they’re actually supposed to click “OK” within the tool tip or something like that.

All of a sudden, it disappears. Getting back into it, do you start back at step one, or step seven, where you left off? Things like that. Using that as a highly linear narrative device can go sideways really quickly. That’s another thing to be concerned about.

Patrick: Just in terms of building stuff, when I build out tours, partly because I’m aware of the fact of sequential fragility, there is generally an easily accessible bailout button for the tour at all stages of the process. When somebody bails out, it should probably keep them in a consistent state that doesn’t totally hose their account.

That’s not universal on all tours. Either you give them a wiped?clean account, or, ideally, you would just give them full control over the interface, but keep the state of the account as whatever they were just seeing, to not have the leaky abstraction of, OK, the tour?mode stuff was actually just fake objects created in a fake state that we displayed to you, but it was actually a lie, which is how a lot of them are implemented.

[Patrick notes: Why? Well, since the tour will often involve running through the core use case for the application, it will necessarily plug very deeply into the core workflow / business logic / etc. That is a non-starter at some places, so rather than changing the core workflow / business logic to accommodate a special tour state, they just fake the existence of the happy path of the workflow with smoke and mirrors. Appointment Reminder’s tour, by comparison, is done with maximum verisimilitude (and a whole lot of elbow grease, which involves some hackery deep in the bowels of the application, like a special case in our outgoing phone system which detects Hollywood phone numbers of the (555) 555-XXX format, short-circuits actually attempting to call them as you’re directed to do in the tour, and then simulates the results of interaction by a human with the phone call that would have happened but for the short-circuit).

Samuel: We almost think about, I can almost guarantee that you, myself, and every listener for this podcast has downloaded some sort of mobile app that’s been greeted with a series of welcome screens, and gone swipe?swipe?swipe?swipe?swipe to just get through it to get to the actual thing. Then not know what was covered in the thing that you just skipped over and not really know how to proceed from there.

I would say any kind of intro or tour or anything, create it around helping people make progress and move forward, but don’t absolutely depend on that.

I would design for a null state, where, basically, OK, is it still going to make sense and we’re still going to be communicating the most important things when the dashboard is empty or things along those lines, and not really count on the hand?holding as your only source of orientation and motivation.

Put Better Default States In Your UI For New Accounts

Patrick: Definitely. Speaking of null states, often, if you’re in a project?management app and you have no projects, the first screen will say, “You have no projects.”

Samuel: Right, kind of accusatory.

Patrick: I would always say, rather than saying, “You have no projects,” OK, if you’re in development mode, sure. Whatever. Put that up there, like zero of zero results returned for projects.

When you’re shipping that to actual customers, just a quick, one?line if statement, replace it with a, “Here’s how you can get started creating a project.” Then most people just put an arrow that points to the “add new project” button or they say, “Click above on ‘add new project’ to get started.” Rather than that, I would give a little bit of goal?oriented instruction.

Samuel: 100 percent. The only thing I would add to that is not only prompting them to fill it up with something, but also, “Here’s the value of doing that to begin with.”

Patrick: Exactly.

Samuel: “You don’t have any projects yet, but this is where you’ll be able to see which ones are at the biggest risk of not shipping on time. Click here to add your first one.” Something like that, to me, that’s my general recommendation. Because just changing it from, “You don’t have projects” to, “Click this button to create one,” it’s not making it a meaningful action.

That’s a term that I use over and over again when I’m looking at onboarding experiences. Do I even know what I’m doing, or do I even care about what I’m doing? Can you help me at least get to one, if not both, of those?

Patrick: One of the things I really like is when you provide people with a vision of the future they’ll have if they’re using the software, ideally a vision more focused on them than just focused on your software. For example, I think Baremetrics does this very well.

They’re a company that slurps data out of your Stripe account and presents a variety of metrics for you. My recollection is, when you start using Baremetrics, in the pre?slurp state, it’s got nothing to show you. Rather than showing you, “We’ve got nothing to show you,” they show a grayed?out version of their real stats.

It’s like, “Wow. You can see all of this stuff, except for your business, if you just click the Slurp button and give us however much time it takes to do the Slurp out of your account thing.”

Samuel: That can be like a PNG. You don’t have to build in a feature that has all this mocked out or whatever. Yeah.

Patrick: Is that how it’s pronounced, PNG?

Samuel: I always call it “ping.” I don’t know. Do you just say the letters?

Patrick: OK. Here it’s PNG, but then again, I’ve lived in Japan for the last 10 years.

Samuel: Do you call it a J?P?E?G, or a J?peg?

Patrick: Wow, I don’t know. It’s different than “jiff.”

Samuel: [laughs]

Patrick: “Jiff,” and then, I don’t know. It’s been too long since I’ve been in a Japanese office, despite being here for 10 years.

Samuel: That’s something to celebrate, I guess.

Patrick: Oh, yes. Every day that I’m not a seller man is one more day of actual life. Yay.

Samuel: [laughs]

How Samuel Set Out To Become, And Became, The “User Onboarding Guy”

Patrick: We covered onboarding tours a little bit. We covered a bit of the design of UX when someone is getting started with a product to feel like they can get more success and not just have to do meaningless busywork until they get to the good stuff.

We covered a bit of life?cycle emails and whatnot. I’d be a terrible businessman if I did not mention the fact that if you go to www.lifecycleemails.com, there’s a course from me teaching you how to do that. A little plug.

I mentioned you have the blog at useronboard.com. Maybe blog isn’t the right thing. A site, where you go into this customer?onboarding thing in a bit more detail than people typically do in a blog post, and you do tear?downs of folks’ user?onboarding experiences, the pre?sign?up process, the sign?up process, the post?sign?up process. You dig into what emails they send.

Samuel: Slideshows.

Patrick: I thought this was really, really smart back when I first got to know you, in that you very clearly said that, “OK, there’s a million UX designers out there. I’m going to be the one that just takes user onboarding and owns that.”

How’d that work out for you? I know you wrote a book on it later, and we can talk about that in a moment, too, but I presume you also do a bit of consulting and whatnot?

Samuel: I would say that going after a niche has been a highly lucrative decision on my part. The consulting and the book sales have both been really strong. Really, it’s been a pretty fun ride.

Patrick: Awesome. Mind if I rewind the tape to a little bit before the fun ride and whatnot? What got you into this in the first place?

Samuel: Interestingly, you were saying that I wrote the book later, but the book was actually what got me into it to begin with. I was a user?experience generalist for years. I was at this weird in?between place.

Looking at things like conversion?rate optimization is not typically something that’s part of the UX wheelhouse, but I was always really, really interested in ?? I think that you’re actually probably a good representative of this mentality of, “Let’s find out what the problems with this flow are and empirically demonstrate that we have improved upon it.”

To me, I guess, the job to be done of what somebody hires a UX consultant for is typically not that. I really struggled with that for a long time, looking at a competing set of passions that were between qualitative and quantitative, so user experience versus conversion?rate optimization, and then the ever?contentious term “growth hacking.” [laughs] Was that as well.

They all embody the same thing, which is aligning your success around your users being successful and paying attention to whether that’s happening and where that’s breaking down, and then being able to measure the impact of the way that you’ve improved upon it.

Let’s see. Where do I even start here? I decided to write a book, because I wanted to take a product to market, but I didn’t want to go six months to a year into developing some sort of a SaaS product and then take it on the chin with a bunch of rookie mistakes about just how to price something or how to create a landing page that sells it or how to have a product launch or things like that.

I thought, instead, “I’ll just have a really constrained product, in the form of an eBook. Surely I can write that in a couple weeks.” Which was, spoiler alert, not the case. [laughs] Then be able to just get my toe in the water by getting something out there and just go through that experience and learn from it.

Very naively, I put up a landing page for the book, and I titled it “Customer Growth.” It was basically all about “Grow your customer by helping your customers grow.” That was the one?liner for it.

A lot of issues there. One, that’s not a thing that people explicitly care about. It’s more of I would have to write a very philosophical thought piece on why people should care about it to begin with, and convince them of the value of the subject, before even convincing them of the value of the book that covered said subject.

The best way I can describe it is nobody was sitting down and saying, “You know what? We have this problem with this thing that I’ve never heard of. I wonder if there’s a book out there on it.”

Patrick: Amen. If you have to convince the market that they’ve got a problem, that may be an option, but you need to have a previous success behind you or a war chest or maybe VC investment. [Patrick notes: But that wouldn’t be my first choice for any of those folks, either! Pick the screamingly obviously high-impact problems first. Plenty are left unsolved.]

For those of us who are just getting into business for ourselves, you should not be targeting problems that you have to explain to people that they have. You should be targeting problems that they know they have, that when they wake up in the morning, it’s one of the one or two things that is keeping them up at night.

That’s a mixed metaphor. One of their one or two top hair?on?fire problems for today. Virtually, every mistake I’ve made in business in terms of product selection has been not targeting those, but that’s another podcast entirely.

[Patrick notes: I do not regret Bingo Card Creator or Appointment Reminder, but if I got a do-over, I’d pick something higher saliency in a tightly defined commercial niche that I would like exploring and knew I had “unfair” advantages in. That would probably be selling software, though there’s an interesting meta question in whether I would be any good at selling software but for the experience of BCC/AR and taking advantage of the doors they opened.]

Samuel: The one thing that I did right, though, was fully committing to getting the book out before I started. As I guess we’ll get to in a second, there were definitely some hard stretches in the middle, where people would ask me how the book was coming or something like that.

I would very truthfully tell them that I was glad that I didn’t know how hard it would be before I started or I never would’ve started. I was equally true about how hard it was, and also equally true about how glad I was that that wasn’t the case, because I was fully committed when I started and I was just absolutely going to see it through.

I put up the landing page, wasn’t really sure how I was going to go about writing the book or establish my expertise. Obviously, Nathan Barry’s information out there was a big source of help and inspiration. He’s pretty email?list?centric. [Patrick notes: For a reason. Email is the secret weapon of low-touch marketing like airplanes are the secret weapon of modern militaries. It’s not a secret at all — if you don’t have them, you’re giving up a tremendous advantage.] I was like, “I guess I should start an email list and see. Maybe I could get up to hundreds of subscribers or something.”

Literally starting at zero, not even having an email list, that was like, “OK, I’ll put up a landing page, get people to sign up.” I had to figure out how were people even going to be getting to the landing page. This was the definition of a cold start, I guess you could say.

As a UX consultant, generalist, at that time, a lot of times I would do something very much like the tear?downs that are on the User Onboard site right now. I was like, “Man. I’m already writing the book,” which is really hard, because I’m a painfully, painfully slow writer, which is another issue. I was like, “Am I going to try to guest?post on other blogs?” [Patrick notes: I did a guest-post tour when I launched my Lifecycle Emails course. I cannot recommend it for generating sales, though for someone with less of a platform it might make sense for audience building. I think I wrote six good essays on the topic for other people, and seen in hindsight, six good essays for my own purposes would be better than six good essays for other’s sites. I think I have about $3k of attributable sales as a result of that, and even if you double the number to count ones which I missed due to the vagaries of tracking, I’d rather have the essays than the money, both for the initial results and for the residual portfolio value.]

Samuel: That’s even more writing on top of writing the book. I’ve heard sometimes you just basically get a really deemphasized link in the byline, and it results in three people signing up. I can’t spend 15 hours on a blog post and hope that that happens.

I was like, “Man, if only I could share these tear?downs that I’ve been doing.” I’d feel weird, because they were commissioned and paid for and not really owned by me. I was like, “Oh, I can just pick a company and not ask them to pay me for it and just do whatever I want with that.”

I just picked a company at random, which was OpenTable, and recorded the experience, and I was like, it just didn’t really come out right. Their onboarding experience is very confusing, or nonexistent, almost.

I had to scrap that one. It was getting kind of late into the day, and I was like, “Maybe I will do this. Maybe I won’t. All right, screw it. I’ll try one other company.” That company, once again, just completely at random, was LessAccounting. Your listeners would probably be ?? it’s kind of in a similar space, I guess.

Patrick: LessAccounting, for those of you who don’t know it, is a bootstrapped software company that is basically a stripped?down competitor to Quicken.

Samuel: There you go, yeah. Also, they seem to really maintain a presence in the bootstrapper community and stuff. That’s what I was referring to.

Patrick: Oh, yeah. It’s a funny little bit of community inside baseball, I think. Sometimes we overestimate how much folks know about the ”scene.” If you hang out at Amy Hoy’s conferences and go out to BaconBiz every year or go out to MicroConf every year, then you’ve run into the LessAccounting guys and you know who they are. (I would bet you that the average Quicken-using accountant or bookkeeper in Normal-Bloomington does not.)

[Patrick notes: I think this is observation is widely applicable. Our community is simultaneously bigger than we realize and yet smaller than we think it is.]

Patrick: I happen to know that for a lot of the world it’s the first time they’re hearing about it right now. By the way, they’re good software. You should use them. A plug. Yeah.

Samuel: Actually, speaking of which, that was back in November of 2013, so not even a year ago, I was one of the people who didn’t know who they were. I’d known them just because they’d been around for several years, didn’t really know that they were highly involved in the bootstrapper “scene,” or whatever that might be.

I was like, “All right, they seem friendly enough, at the very least,” went through, created the tear?down, put it up on SlideShare.

I think it was the end of the day, and SlideShare messed up the formatting and the aspect ratio. I just wasn’t really happy with the product, but I was like, “I’ll just go home and talk to my wife, and tell her I blew another day while I’m trying to get this book out.”

I posted it, and the next morning I got an email from one of the co?founders of LessAccounting. I see it in my inbox as the subject line and see who the email’s from, and I was just like, “Oh, no.” I was sure that when I clicked on it, it was going to be him coming and being like, “Oh, thanks a lot for airing our dirty laundry and pointing out how our onboarding experience isn’t working, and who even are you?”

It turned out to be completely the opposite, that he was like, “Thank you so much for pointing all these things out. We already made a bunch of the changes that you recommended. I see you’re writing a book. How can I help promote it?”

It was just total night and day from what I was expecting as a worst?case scenario, really just a super?supporting response. He wound up featuring it on the LessAccounting blog, and that was really the very first thing that I did that got a decent amount of traffic and a decent amount of sign?ups for the email list and things like that.

Patrick: Awesome. I think this strategy is very generalizable, and in fact, folks have done it in a lot of circumstances, and it often works well. Dustin Curtis is a designer. He basically made his name by taking a few big Fortune 500 company websites, doing redesigns on them.

I might have issues with that particular work product, but that’s neither here nor there. 37Signals, back in the day before anybody knew who they were [Patrick notes: 2002 — Basecamp and Rails were in 2006, I think?], just did unsolicited redesigns of the FedEx application and said, “Here’s all the mistakes that FedEx is making.”

It wasn’t actually FedEx, because I think they were probably worried about getting sued, but it was a purple?looking delivery company.

[Patrick notes: I apparently misremembered this — it appears to actually mention FedEx. Their BetterBank was a better example of a generically attacked problem. Though I’m fairly certain that somebody has done a You All Know Whose Website I’m Talking About redesign without actually using the trademark — can’t recall who at the moment.]

Samuel: [laughs]

Patrick: They just had purpledelivery.pdf, with the redesigned with the purple delivery company’s Web app, which featured package tracking as a first?class citizen rather than the 15th thing that you wanted to use.

Especially, if you do this for other people who are closer to the us?es of the world than the Fortune 500s of the world, folks, often, the first impulse will not be send a cease and desist or be very annoyed at you. It’s like, “Hey.” Folks describe me personally as Internet famous, which is a funny, funny word.

To this day, my heart lights up anytime someone shows any bit of attention to one of my products. If you want to screen?grab everything and show what I’m doing wrong with the world or how my pixels are out of place, I won’t think, “Oh, he’s insulting my pixels.” I’ll think, “Yes! Totally! Someone noticed me! That’s awesome!”

Samuel: Just to briefly touch on the whole unsolicited?redesign thing, I can see how I’m in a similar space as that, but personally, I’m really not a huge fan of unsolicited redesigns as a thing, largely because it’s a very surface problem.

You’re basically saying, a lot of times when you see them, especially on Dribble or things like that, it’s, “I didn’t think this was pretty, so I made it prettier,” where you don’t really know what’s working that well, what’s not, what kind of constraints the team is faced with. You’re probably not even necessarily the primary audience that the product was intended for.

For a lot of reasons, when I’m creating a tear?down, I try to be very, very conscious of the fact that there are real people who had made this under real pressure, and it was to serve a job that may or may not be something that was…I’ll literally go through the sign?up process to create the tear?down.

It’s not like I’m even really genuinely trying to make it work for me in that moment. There’s already that, and maybe I’m not even a key audience member at any point in time. There are those issues.

Then also, I’ve actually had conversation with people, where maybe I’ll say, “Yeah, deciding to do that made me scratch my head,” or “That doesn’t really conform to the “best practices” or whatever that might be.” The design team will be like, “Yeah. Yeah, we hated it, too, but it’s working really well.”

Not having visibility into the conversion funnel or whatever that might be, and then also just not knowing about what kind of internal pressures they’re dealing with in the office, I really, really try to say, basically, “Objectively, these are what our best practices are, or not, considered to be generally within the community.

Then also, anecdotally, as a user, I was legitimately confused when I went through this.” Really, really distance myself from saying, “This is objectively wrong” or anything like that.

Patrick: Right. I think that is a great attitude to have about it in general, and probably a karma?maximizing attitude, if you’re hoping to borrow an audience as a result of publishing these things.

Also, I think, as somebody who has worked in a lot of companies and seen the sausage get made, it absolutely tracks with the internal human/political/resource?based constraints on why something might not be totally optimal. There’s a lot of times where, heck, I’ll own it. I won’t blame the client, I’ll blame myself.

There are something that I have shipped where I could point to you X, Y, and Z decisions of the things that shipped today and say, “I hate X. I hate Y. I hate Z.” I had 100 points of awesomeness in that engagement, where awesome is an arbitrary resource. Fixing X would’ve required 20 points of awesomeness. We just had other things to spend awesomeness on, so we just shipped it out the door.

Samuel: There you go.

Patrick: Often, a particular team or person in the organization just did not want to budge on Y, and they had been really cooperating on some other part, and so you trade tit for tat. That happens all the time in real life.

Anyhow, going back to the book for a moment.

Samuel: Yes.

Patrick: You release some of these tear?downs, and both the folks who were, quote?unquote ?? I hate that word, tear?down, by the way. I’d like to say, “build?up.”

Samuel: [laughs]

Patrick: You released some of this feedback on people’s onboarding processes. Some of the folks who were featured in this feedback found it really, really useful to them, like the guys at LessAccounting.

They spread all over the Internets to these people’s preexisting networks, as they said, “Hey, someone has taken this interest in our business and given us really useful feedback. We could read the writeup.” Thus, you got, what, a few hundred or a few thousand people to subscribe to your email newsletter?

Samuel: Specifically, in the early, early days, it was maybe a couple hundred, when the book was still called “Customer Growth” and people probably didn’t really know what they were signing up to get.

Through the success of the tear?downs ?? so I did the LessAccounting one, and I was like, “Well, that went well. I should do another one.” Then I did Basecamp, and then that one got shared a lot. I think that wound up Designer News, the front page, for quite a while.

At that point, it was suggested to me that I stop using SlideShare and instead create a site that’s dedicated to those, where I could control the conversion timing, the asks, basically. I also just wasn’t really a super?huge fan of the user experience on SlideShare, either.

Patrick: Can I circle this point and star it, guys? There’s a lot of folks who put their best work on 3rd party sites. In my case, some of my best work is on Hacker News. In other folks’ cases, it might be on Dribbble, on Twitter, on Facebook, on Medium, et cetera, on GitHub, a major one for the developer community.

For things that are central to your career, building up a public portfolio, you really want to be able to control all aspects about that, both how the work is presented to people who will be future decision?makers about your career and what you emphasize about it.

If you embed something in GitHub, you’re going to end up with a very GitHub?y experience for that, regardless of what it is. The way that people consume that artifact that you have put on GitHub will be a very GitHub?focused consumption experience rather than a you?focused consumption experience or a them?focused consumption experience.

Samuel: Yes.

Patrick: I would strongly encourage, from both a UX point of view and a “maximizing the future value of your passport to your future self” point of view, that you put your best work on your own darn website. Think about wrapper?type issues, like:

Should I put a logo on it? [Patrick notes: If it represents more than a work-week of effort from you you’d be crazy to not spring $100 or $200 for a logo. I strongly feel like the logo, the dedicated web presence, and the non-zero effort put into documentation for A/Bingo were reasons it redounded to my favor.]

What sort of asks should I be having on the page? Whether that’s asking someone for their email address, or, for those of you who might not be selling a book but might be selling freelance or consulting services, maybe you ask them to send you an email and ask for a quote, or “Send me an email. I’d love to have a Skype chat about this if it interested you.” You convert them and do a request for a quote or something on the Skype chat, et cetera.

Yes, asterisk, asterisk, asterisk. You should absolutely have it on your own website. Which is, by the way, to this day, why ?? well, aside from Hacker News ?? almost all of my writing is on either my own blog or on my other sites. Most of the things that I produce even for free, the canonical source

  continue reading

11 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide