In the early days of a startup, everything is training. You’re alway practicing. Talk to anyone who will listen. Think of yourself as an athlete, always training, practicing.
That party where you’re answering questions from some random person at your startup — 2 months later you’re going to get that question from a rock star reporter when you least expect it, and you’ll be ready with the answer on autopilot. Keep building. Keep doing stuff even when the payoff isn’t 100% clear. Invest yourself. Get paid later.
That random student who wanted to chat, you thought about blowing off? Turns out his mom is a VC. That candidate who you knew wasn’t right, but still wanted to chat? Turns out he knows the perfect person and introduces you after you do him the courtesy of a conversation. Invest. Share. It will come back to you in ways you never expect.
You don’t make your money now off your success now (mostly). You make your money in the next “life”. Because what you do in this “life” (your current gig) is what gets to that next, bigger gig, your next “life”, that’s an even bigger opportunity. You’ll have to earn it there, too, but you’ll never get the chance if you don’t invest.
Most of the money I’ve made, I’ve made via Endeca, when they/we were acquired by Oracle. And I worked my ass off for it. But I’d never have gotten the chance, if I hadn’t invested 5 “dog years” (seemed like 35 years) at PTC. It was a meat grinder, a hell of place to learn but an unrelenting grind. But because of the work I did there, and the reputation I built, I got a chance to take the next step up at Endeca. Invest.
I constantly speak to managers or leaders who are aggravated that someone who works for them makes more than they do. “Get over it”, I tell them. I’ve been everything from a manager of a few people to a VP running hundreds of people to a CEO. In almost every circumstance I’ve had someone reporting to me who made more than I did. They say you should hire people smarter than you. I agree. And that probably means they’re sometimes going to get paid more. And you know what — that’s ok, because they’re going to make me money, in this life or the next.
A few years ago, everyone seemed certain that ebooks were taking over, and companies rushed to form the first successful “Netflix for books” service that could provide readers with unlimited ebooks for a low monthly price. Amazon jumped into the market with Kindle Unlimited, challenging the already existing Scribd and Oyster for the ebook subscription […]
We’ve written previously about Scribd and the challenges of the ebook subscription model. Electric Lit reports that Scribd will more-or-less gut the service by imposing hard-to-understand limits on how much you can read on the service. It’s challenging enough to make an economic rationale for Scribd, in it’s current form (as I wrote here). This will make it near-impossible.
The news that Oyster is closing shop (or at least, abandoning their eBooks subscription business) suggests a re-evaluation of the subscription eBook business model is in order. We’ve written before…
I think it’s the endgame, until the publishers see this model as a benefit and revenue source, rather than as something to be tolerated.
Startups obsess about their User Experience (UX). As well they should. Consumer expectations are sky high — if your product is ugly, hard to use, or confusing, they’ll abandon it in a heartbeat. There’s just too many options out there.
But are you worried about the right things?
Startups have a tendency to agonize over their user interface, but not necessarily the right parts. Fussing with buttons, changing colors, re-arranging pages, tinkering with the home page. Assuming a user flow that’s the typical “previous visitor comes back to the the home page, then hits the link we want them to hit, and takes the actions we want them to take”. This is often not where the big win is.
Here’s the reality. Your first time user experience IS your user experience. It’s the only thing guaranteed to be experienced by all your customers. All those fancy features you are implementing don’t mean a thing if people don’t onboard well. If they onboard well, they’ll come back — and you’ll have acquired the necessary information (e.g. their email address) to pro-actively reach out to them to get them back. If they don’t onboard well, all that other stuff doesn’t matter. Invest in optimizing your first time experience!
What are the key ingredients of a great onboarding experience?
Tell the Story with Progressive Exposure
Incremental Rewards
No friction
Context aware
Multi-channel aware
Easy off ramps
Tell the Story with Progressive Exposure. As people onboard, it’s your chance to tell them the story of your product. Simon Sinek calls this “Start with Why”. “People don’t buy what you do. They buy why you do it.”. This is your chance to sell your mission, to tell them that story.
Tell them that story. And what your product’s benefits are, and how it works. But gradually. Make sure you expose the right information first. Gradually reveal details — people can’t take it all in at once. Many details can be deferred to a follow up welcome email, and that gives you another change to help refine the onboarding and drive re-engagement. For example, with The Hawaii Project, I follow up a day after registration with an onboarding email, and if they have not filled out certain bits of information (e.g. their favorite authors!), I will offer them the chance to do it then.
Give them incremental rewards along the way. As they give you information, give them something back, so they invest in the process.
No Friction. Ask the easy questions first. Don’t ask the hard questions til later. (for example, in The Hawaii Project’s onboarding for book recommendations, the first question I used to ask was for people’s favorite authors, via a blank search box. Data and user interviews showed me that many people got stuck on this question. And then abandoned the entire onboarding process. So I moved that question till near the end, made suggestions for them based on previous information I’d gleaned, and made that question optional). If the question is hard, get rid of it or move it to the end once people are invested. Don’t ask for information you haven’t earned the right to yet — for example, asking for payment details when I don’t really even know what the service does yet.
Context Aware. You have to be aware of how people came to your site/app and why they did so. Quite possibly (most likely) they didn’t start on your home page! They probably started on some other page, if it’s a web app — make sure the onboarding process can be started from there, and is contextually aware of that page and what it means for the user. Maybe it’s a book page for their favorite author — take advantage of that knowledge in onboarding.
Multi-Channel. People may have found out about you by visiting your website and then downloading the app. Or your app and website need to interoperate. Or your website points people to download your app. Where possible be aware of this multi-channel exposure and take advantage of it.
Easy Exit Ramps. Give people an easy way to stop the onboarding process, while leaving with confidence that their information isn’t lost and that they can come back later to finish. Many times people stumble on something interesting, suddenly realize they have a meeting to go to and can’t finish then. Don’t lose them.
Here’s an example I recently came across that breaks too many rules. I saw some ads and articles for an “all you can eat” magazine subscription service,Texture. While they have a website, all the ads (and the positioning on the site) point me to the app. So I downloaded the Android App and fired it up. Here’s what happened.
First three steps on Texture Onboarding
Screen 1. Fine. I guess, why not put sign up first, not second — once people have signed up and signed in, they aren’t going to sign in again? Since you’re advertising a mobile app, why not assume that’s where people are coming from? (I.E. — the only reason I’d need to sign in is if I created an account on the web, then downloaded the app — which is not what your website leads me to do….but fine. So I hit “sign up”, — what wha???? Why am I suddenly cast out of the app into a website? Completely lost my flow already and a bit confused. You’re selling a mobile app, let me create my account in that app without sending me off someplace strange! In that one event I’m already starting to lose trust in this app.
I get a page full of info, instead of a signup form. Ok, so I figure out I’m supposed to hit the button (again) to “Start Free Trial”. (In fact, if I scroll down, there are TWO kinds of free trials to choose from…gack! So I enter my info, and BOOM — Texture wants my credit card!?!!? I don’t enough know what this thing is yet? I know it’s magazines, but I don’t know how it works, what magazines they have, nothing — and they want my CC info. This is WAY too much friction. And you haven’t earned the right to ask for my credit card yet!
Honestly, if I were a normal consumer, and not someone looking to explore onboarding experiences, I’d be out of here, never to return. I’m a lost customer to them. But, I sign up. Here’s the next three screens:
Good grief. After I create my account, it tells me I need to download the app (iOS no less, even though I came from Android)! I already did download the app! That’s why I’m here! If you’re going to send me off to a website to sign me up, at least keep the context that I came from an app and respect it! They’ve lost the context of who I am and how I got here.
Then I get a screen with some high level info — it’s OK, but it’s not the primary content and it’s a lot of info to consume. So I just hit continue, and (finally!) get to the money screen — where I can pick which magazines I want to read! From there it’s no so bad, but in reality they lost me 3 or 4 screens ago. A better user experience would have a) let me start personalizing before asking for my payment, and b) let me create account and payment afterwards, in a native UI. I can’t get away without providing payment info either way, but in this way I’m motivated to pay vs irritated to pay.
Now, Texture seems like an interesting product and I’m sure they’ll refine all this — it’s just an illustrative way of pointing out that all the care they undoubtedly spent on their product UI is potentially wasted because I never got to it.
Your First Time User Experience IS your user experience. Treat it that way.
(are you a Book Lover? Sign up for The Hawaii Project and check out our onboarding. It’s by no means perfect, and comments/critiques are welcome!)
If you’re interested to explore how others tackle Onboarding, there’s some great collections of first time experiences:
So yesterday I wrote about Book Playlist, my hack from the CODEX hackathon, for building collaborative music playlists. This morning I woke up to an email that it was featured (on the home page) of Product Hunt! Very excited. I’m curious (and will post) what that will mean in terms of traffic.
Awhile back I randomly found out about CODEX Hackathon, a “literary hackathon” mashing up books and technology, and I knew I had to get involved. I started by registering to attend, but realized pretty quickly I wanted to do more. I volunteered to helped organize and sponsor, which I’ll write about later. I also hacked, and wanted to share what I came up with, and how I came up with it.
Books and music go together like, well, wine & chocolate. Settling down on the couch with a great book, a glass of wine, and some great music has to be one of life’s guiltiest pleasures. Heck there’s…
So when this hackathon came along, the juices had been flowing for awhile and I knew what I wanted to do. Build an environment where people could collaboratively build and share music playlists for their favorite books.
I had the basic idea framed out in my head. I’d use the Spotify web player and hack up a branch of http://www.thehawaiiproject.com to become the new thing. Seemed like a layup, all their Web APIs are sitting right there. Spotify has a feature for “collaborative playlists” – what could go wrong, right?
After some presentations from sponsors (I was a sponsor, here was my pitch for The Hawaii Project), we get down to it, at 11am Saturday morning.
Here’s a quick timeline from my notes:
start @ 11
around 12, have a Master & Commander (Patrick O'Brien’s book) page with a static playlist on it. Everything hard coded but I can listen to music for the book and it visually looks pretty good!
My plan is to use Spotify’s Collaborative Playlist feature so everyone can add to the playlist (and be authenticated to Spotify in the normal way via their browser). SNAG! Turns out making a Playlist “Collaborative” in Spotify makes it Private so only collaborators can see it. Even worse, via the API, only the Owner can modify it. That pretty much blows the whole idea out of the water.
OK, Plan B. I will make a Hawaii Project Spotify account that will own all the playlists. When users add an item to a playlist I’ll send it to my server and the server will add it to the playlist. Because the API calls have to authenticate (via OAuth) to the Spotify server, I have to figure out how to authenticate in PHP to Spotify without a browser around. I dumpster dive in Stackover flow and find The Hint (thank you Michael Thelin!).
12:00 : 1:30pm. I struggle to get The Hint to work in practice. I take a break and grab lunch (wonderful sandwiches and Hummus, CODEX has great food!).
3:41pm EUREKA!!!! I get a valid spotify token and successfully retrieve a playlist!!!!!
3:42pm. My token expires and I can’t figure out how to get it to renew.
7:45pm. I think I get a repeatable way to add tracks, at least until my token expires. which I have to renew manually. OK for a demo but can’t actually go live with that. I’ve spent ~50% of my hacking time on OAuth. Not what I had in mind.
8:30pm. I have some basic track search + autosuggest for tracks working. (like when you type “Stairway to H” I suggest “Stairway to Heaven by Led Zeppelin”)
8:50 Stairway to Heaven and Highway to Hell added to playlist via UI. !!!!!!
9:50 Code cleanup. Things basically working with a single hard-coded book & playlist ID, except hacky tokens & expiration.
10:00 Did I mention this is a hackathon for Adults? MIT kicks us out at 10pm. Home. Martini. Sleep.
Sunday
6:30 am up, by 7:40am On the train.
8–9 in coffee shop because MIT doors locked. Quickly solve some problems with playlist views and track list ordering problems solved. still struggling with expiring oauth tokens.
10:00 With the exception of tokens, I have what I need for a workable demo, can search for and add tracks to any book.
10:30–11. Make some fun playlists for some of my favorite books!
11:12 roll a new home page showing the latest books that have soundtracks created.
12:30. stop and roll a deck for the presentation.
1pm. Hands off the keyboard at 2pm for presentations, so I decided to adopt the “Vietnam strategy”. Declare victory and get out. I avoid breaking my demo with any late changes, and go chat with a few interesting folks I didn’t have time to get to before.
Presentation went well (in fact everyone’s did!). I start my presentation with the James Bond theme and end with adding Highway to Hell to a playlist, and playing it over the speakers as I exit. Mission Accomplished.
I wanted to launch it to a live URL during the Hackathon, but I just couldn’t solve the expiring token. On the drive home, I decided that tomorrow I’d ask my son-in-law, who is an actual practicing software engineer. But I wake up the next morning and, as often happens, within about 20 seconds I see a typo that’s been causing me all this grief. Edit, “git commit -m “I’m an idiot””, and a few minutes later, voilá: BookPlaylist is born!
As I write this, I’m jamming to Kayti’s most excellent playlist to Cinder, a book I’ve not read. But now might.
It was really fun to take an idea that I’ve had in my head for almost a year, and get it out of my head and into something real. Hope you get a chance to play (pun intended) with it!
You can read a bit more about the Hackathon here (via Matthew S Carroll, one of the organizers.
Hello, from the the CODEX Hackathon. We’ll be live blogging here all weekend, so come back often as we update. To follow on Twitter: #codexhack. The hackathon is about…
Everything is training.
