Often, entrepreneurs ask me something to the effect of, “What’s the best way to let new users explore my product?” My answer is almost always a variation of, “Stop it.” In order to be slightly more helpful, let’s look at why this is a terrible question. Users Don’t Care About Exploring Your Product Nobody cares about your product. Fundamentally, what users care about is themselves. They are using your product as a means to an end. We knew this back in 1960 when Theodore Levitt explained that when customers buy quarter inch drills, they really are buying quarter inch holes. Think about the last time you bought a drill. Did you sit down with the drill in order to spend time exploring it? Not unless you’re some sort of drill fetishist. What you almost certainly did was try to figure out the fastest way that you could set about completing the project for which you bought the drill. The same is true of whatever product you’re building. I know that you care deeply about the user interface of your product and all of the delightful features you have so lovingly handcrafted. Sadly, nobody else does. At least, not in the same way that you do. People want whatever your product promises to do for them, and they want it to happen as quickly and easily as possible. They don’t want to explore your tax preparation software. They want their taxes done. They don’t want to delve deeply into the mysteries of your To Do List software. They want to not miss deadlines. But What About B2B Products? I know, I know. B2B products are different! They’re more complex! They have so many features! They require training and exploration! Nonsense. All of those incredibly complicated, feature-dense pieces of B2B software that require weeks of training are getting disrupted by things that humans actually understand. I worked with a company that required all documents be shared by filing a ticket with IT to create a personal folder on a shared server which then required mounting a new drive onto the desktop and…blah blah blah. Everybody just used Dropbox, even though it was officially forbidden by the company. The fact is, people in big companies are forced to work with dozens of complicated products every single day. The introduction of a new, complicated product does not instill in them the desire to spend a lot of their day exploring it. It tends to make them sigh resignedly and figure out if there is some way to avoid learning the new system until it goes away and is replaced by something else. The only way to make a product that people want to use at work is to make it so easy to use that they don’t have to explore it. They can just jump in, share a document, send an email, or do whatever task it is that they wanted to do originally. Users shouldn’t have to explore your product to do their jobs. But…but…but…Games! Nope. Sorry. Still very little open exploration for new users. I mean, sure, you can wander all over GTAV and steal as many cars as you want. But have you ever noticed how many quests and tasks and hints you’re given along the way as a new player? Actually, you probably haven’t. Really successful games are fabulous at getting you onboarded without making you feel like you’re going through a tedious training session but also without just dumping you directly into the deep end. In good games, the real exploration doesn’t come until users are pretty comfortable with all the basic actions they need to be successful. Often, advanced features are hidden from users until they are unlocked. This not only provides the user with an incentive to keep playing, but it effectively hides complexity until the user is ready for it. Think about hiding a rocket launcher from a new FPS player. Now think about not showing quarterly estimates to a tax preparer until you know that she needs to file quarterly estimates. There’s a surprising similarity. Note: hiding rocket launchers from people doing their taxes is also not a terrible idea. E-Commerce? Again, not really. While online stores do encourage you to explore and browse, you’ll notice that they don’t have you exploring and browsing the store itself. They have you exploring and browsing the products they want you to buy. When you’re selling widgets, it’s all about showing off the widgets as quickly as possible. Even while you’re looking at a widget, the site or app is immediately offering you more widgets that you might be interested in. It’s not about exploration of the product. It’s about getting you involved with the things the product is selling. What Should You Do Instead? Stop thinking about letting users explore your product. In fact, stop thinking about letting them do anything at all. When a new user comes to your product, give them a task. Have them do the most obvious, low-friction thing that they will need to do in order to become a slightly more experienced user of the product. Twitter is an excellent example. When you first join, they don’t just tell you to explore Twitter. They have you immediately start following people. This not only introduces you to the concept of following people, but it gives you a nice, low-friction way to start using the product in the manner it’s meant to be used. Of course, figuring out what that most obvious first task is can be tricky. In order to do it well, you need to truly understand why your user might want to use your product. What problem are they trying to solve? What task do they want to accomplish? How do they want to change their lives? What sort of hole are they trying to drill? Once you understand that, you’ll know how to create an onboarding experience that won’t force people to explore your product before using it. In fact, they’ll never have to explore it. They’ll just be able to accomplish their task and get on with their now-improved lives. And that, after all, is exactly why they wanted to use your product in the first place.

First, some background: I highly recommend that you read the following two blog posts: by Ashe Dryden: The Ethics of Unpaid Labor and the OSS Community and by James Coglan: Why Github is not your CV. They make some fantastic points and communicate the issues surrounding “Using Github as your CV”. Both of these were largely provoked by this tweet by Chris Anderson: Advice received on hiring software devs: reject anyone who doesn't have a @GitHub profile (the more active the better). Agree? — Chris Anderson (@chr1sa) October 30, 2013 I had a similar, extremely popular, tweet from 2011: When it comes to hiring, I'll take a Github commit log over a resume any day. — John Resig (@jeresig) February 5, 2011 I wanted to take this chance to clarify my position on using Github during the interview process a bit. To start, the position being posited by Chris is absolutely wrong. No one should ever require a Github profile in favor of a resume (unless you’re applying for a job at Github, perhaps?). Nor should anyone prefer candidates who provide a Github profile over those who don’t. (And to clarify, some people seem to be getting caught up in the terminology – I see many people using ‘Github’ as a placeholder for ‘any OSS activity’, I hope no one is being that literal.) When you’re applying for a job it’s generally advised that the more high-quality information that you provide, the better. Anything that emphasizes your work habits, the quality of work that you will perform, and your interests is ideal. Thus the more targeted information you’re able to provide, the better. Github can provide this for some but almost certainly can’t be the final arbiter of this information for all. We’ve had dev applicants at Khan Academy who’ve applied with traditional resumes, resume + Github profile, resume + personal web site, resume + links to projects they’ve worked on, resume + a custom project made special for the interview. Out of all of these submissions the ones that’ve had the most impact are the ones where the candidates have gone above-and-beyond and done some custom coding, made a custom web site, or contributed to one of our Open Source projects as part of the application process. A popular project is one where candidates make a custom exercise using our exercise framework. There are a few reasons why this particular approach is so effective: It communicates just how interested the candidate is in the job: That they’re willing to go above-and-beyond to demonstrate their interest. They show that the sort of things they’re interested in working on are largely aligned with what we’re trying to do (especially if they make an exercise with our exercise framework). If it’s a coding project you can get a sense for what their code quality is like and how they wish to portray themselves. Naturally this isn’t completely ideal as it requires a candidate to put in considerably more time into their application than just generating a single-sheet resume. That being said the level of information that is conveyed is so much higher that it almost isn’t comparable. The traditional interview process is broken. It’s high-stress and a poor representation of what you’ll actually experience working for the employer, or working with the candidate. Over this past summer I developed a new “take-home” project-based interview for JavaScript-centric candidates to Khan Academy. I wanted a way to try to better-quantify a person’s development ability without having to necessarily suss out their best code from Github, or elsewhere. I extracted a tangible, contained, project that I had assigned to one of my interns and turned it into a project. Thus far it’s worked extremely well as, as can be attested to by Pamela Fox (who completed the project with flying colors). I’m very pleased with this approach as it gets all the benefit of the candidate creating a custom project on their own but it has the added benefit of communicating to the candidate the exact type of projects that they’ll be working on here at Khan Academy. I’d love to open up the project at some point to show how it’s done but it’s still an effective tool in our interviewing toolbox and I’m not sure I want to lose that just yet! However, you can be privy to the project-based interview process if you wish to apply to Khan Academy! Specifically if you’re interested in working with Pamela Fox and me to build Khan Academy’s Computer Science platform (more details on the launch, a technical talk I gave on it after launch). If this really excites you then you should apply for a Software Developer position at Khan Academy and specifically request to go through the JavaScript project interview with myself. I’ll give you the project to work on and we’ll discuss the results extensively. The biggest drawback to this approach is that we’re demanding some of your free time to gather this information. We’re not sure what the best way is to offset this, as of yet. However by doing the project you’ll likely be able to skip a number of stages in our interview process and hopefully get started on changing the world with us at Khan Academy all the sooner.