These are the slides/notes to a talk I gave at Startup Grind 2013

Introduction

My advice is for venture capital backed social companies, this advice is not for lifestyle businesses.

This is a very lessons learned type talk, it definitely walks a fine line between jaded and RA-RA-RA you can do it.

I want everyone in this room to understand that once you’ve taken VC money, you’ve basically started a clock counting down and subscribed to a certain lifestyle, and you've also agreed to become a certain type of company.

With all that said, I want to talk about money, there are two types of money...

Traditional Money

This is a typical business, you have customers and they pay you for your product.

Social Money

I’ve been involved in two social companies from the ground up (Plancast and Undrip, and since this talk I've also worked at Path)

In a social company your users are your money; they might as well be a line item on your income statement.

There is no such thing as a lifestyle social network business, if you choose the social company path you need to be a runaway success.

What do I mean by runaway success?

Pinterest (amazing success, exponential growth)

Ben Silbermann has talked about how Pinterest had 50% growth month after month in the early days of the company. Starting from a small base, this seems like awful engagement and growth for the first little while, but you'll eventually reach a tipping point when you are growing by that big a percentage each and every month.

The tech press who wrote stories about how Pinterest was nothing for years, but the founders stuck it out and didn’t pivot, really don’t understand how magical 50% growth month over month is--even from a small base. To point out how ridiculous those stories were, Pinterest was able to raise multiple rounds of funding while they were “sticking it out.”

Our intuition about the future is linear. But the reality of information technology is exponential, and that makes a profound difference. If I take 30 steps linearly, I get to 30. If I take 30 steps exponentially, I get to a billion.

-Ray Kurzweil

Plancast (linear growth, X users/month like clockwork)

You’ll run out of money long before you get to the scale of users you need to keep the lights on.

I’ll just get press and my site/app will explode with users

I want you to think back to that Simpson's episode where Rainier Wolfcastle was shooting a movie in Springfield. The acid is coming towards him and so he takes out some goggles and puts them on, then the acid hits him and he says, “The goggles, they do nothing!”

Press is a lot like that, it will not significantly move the needle for your company.

Just as a side note, an easy way to tell if a founder inflates all his metrics is to ask him how many hits he got from a TechCrunch article about his company, if it is really high, my guess is he is lying about almost all his other metrics also.

Power users are overrated

Your best bet to grow is to have users love you, and for them to tell their friends.

Pinterest and Snapchat had huge user bases before Robert Scoble signed up.

Personally, I think people that follow power users are jaded, I’m much more likely to download an app on my mom's recommendation than some random tech pundit I follow on Twitter.

Advertising is not a business model

Why would companies use your brand-spanking-new super geo-targeted social networking app with a small user base when they could just carpet bomb Facebook ads for everyone in your city for less money and reach 200x more people (answer: they won’t).

You have to have huge scale before advertising becomes a viable business model for your company, and even then it's not guarranteed to succeed.

I'm done

Agree? Disagree? email me your thoughts, set me straight...

The one question I always get while talking to people about First Opinion is, "How is the quality?" On the surface, quality seems like such an easy thing to measure since most people (myself included) usually only view quality in terms of results: I have a problem, I seek a solution, that solution solved my problem, so it was a quality solution.

But in actuality, a quality experience can be much more nuanced and can change depending on the circumstances of the person and their expectations with regards to not only results, but also speed and empathy. I think this anecdote from The Innovator’s Prescription demonstrates quite nicely how fluid the definition of a quality experience can be:

We'll illustrate how the definition of quality health care can change by recounting the experience of a friend, whom we'll call Helen, whose youngest daughter woke up on a recent winter morning with an earache. Having seen the symptoms dozens of times before, Helen called their pediatrician. "Katie has an ear ache," she said. "I bought an otoscope a few years ago because this happens so often with our children—and Katie's eardrum is bright pink. Is there any way you could just call in a prescription for ampicillin to our pharmacy?"

"No, I can't do that," the pediatrician replied. "I really need to see her."
"Can I bring her in this morning?" Helen asked. "She's in a lot of pain, and I have a busy day at work."

"Unfortunately I'm booked all day—but if you bring her in at about two o'clock, I'll see if I can work her in," was the reply.

Helen arrived with Katie at the pediatrician's office at 2:00 P.M., and waited for two hours before the doctor had time to see her. Then in 30 seconds, with one look in her ear, the doctor diagnosed, "She has an ear infection."

"That's what I told you this morning!" Helen grumbled in frustration. "We need to get home because the older kids are home from school. Can you please give us the prescription?"

The pediatrician then wrote out the prescription. After a 10-minute drive to the pharmacy and another 20-minute wait, Helen and Katie drove home with the medicine they needed. The process, which is played out tens of thousands of times every day in America, cost Helen four valuable hours.

Was that a quality experience? Helen got her desired result, but the lack of speed and empathy resulted in an overall poor quality experience. In fact, I think there are even times when speed and empathy might actually be more important than just results alone, especially in situations where the desired result might not be completely obvious.

I want you to close your eyes and imagine being awakened abruptly, in the middle of the night, by the crying screams of your three year old daughter. You rush into her room to find your daughter, and her bed, covered in throw-up. You jerk off the covers and strip off her soaked clothes. As your wife works to calm her down, you start to clean up the mess. Then, ten minutes later, your daughter throws up again.

Your wife pulls out her phone and sends a message to her doctor (using First Opinion of course) to see if her doctor has any thoughts on what could be wrong. Within 15 minutes, your wife and her doctor are messaging back and forth--in the middle of the night. In this situation, there was no real result to be had with that conversation with her doctor, but this was a quality experience nonetheless, not because the problem was solved, but because the response was quick. The experience wouldn’t have been nearly as high quality if that conversation had happened just one hour later.

Now I want you to close your eyes again and imagine you’re a new parent, you’ve only had your baby home from the hospital for a few days, and she’s having trouble sleeping, you’ve tried everything you could think of to help her sleep, you’re tired, and you’re baby still isn’t sleeping. Your wife convinces you to take her and the baby to the Pediatrician, so she can talk to him.

At the office, the doctor pokes and prods your daughter with his finger for a bit, takes some measurements, and tells you she’s healthy and asks if you have any questions. After you run through your list of what you’re doing to get her to sleep, he sits down for a minute and talks about how frustrating it is when babies aren’t sleeping, and how he’s been through it himself with his kids. He assures you it’s normal and that he thinks you’re doing a great job and that he’s sure she’ll start sleeping soon.

Once again, there was no direct result to be had from that doctor visit, but this was still a quality experience because the doctor was there for you, to tell you he thought you were doing a good job, to empathize with you.

I, of course, don’t need to imagine the above scenarios because they both happened to my wife, our daughter, and me. And so I know they were both positive experiences and high quality interactions with our doctors. These are the exact type of experiences I hope you have with your First Opinion doctor, so, if we ever meet in person, I can ask you, “How is the quality?” and you can share a similar story to me.

Designing and building software is all about tradeoffs. As a developer, I usually begin the planning phase by mapping out the ideal way I would like to interact with the software. If this is an iOS application, I ask how I would like my program to behave with certain input, what does it do when I swipe left? How about swiping right? If this is a new library, I map out how I would like to interface with this library. After mapping out the ideal interface and interaction, then the realities of actually building that ideal creep in.

At First Opinion, we decided early on that passwords were annoying on a mobile device and so our app would use uniquely generated tokens when signing up on the app. Basically, a user would sign up using their device and then their account would be locked to that particular device, they would always have access to their account (on that particular device) and they would never even have to think about a username and password. Then, if they ever tried to use First Opinion on another device, we would see it wasn't their validated device and send them an email with a registration code that they could then enter into their new device to tie their account to that new device. No usernames or passwords would ever need to be remembered by the user.

This was the ideal user interaction with First Opinion that we wanted. But that ideal changed as we went along actually building the app. First, as developers, we spend a lot of time logging in and out of the app, and so we kept delaying the email with validation code part of our signup flow because it was not only complex to implement on the backend, but would keep us from easily moving between devices and logging in and out to test the app. Since the validation of users didn't exist, and there were no passwords, during the early days of the app everyone could sign in as everyone else. Obviously, this was going to have to change by the time the app was released into the wild.

As we got closer to launch, we realized how much architecture was really needed to support sending the validation emails. Things like a temporary storage place for those registration codes and an architecture for sending emails. Basically, there needed to be lots of stuff to allow the user to not have to remember a password, and that was on top of the rather large list of other things that still needed to be done before launch, we're a relatively small team (currently three engineers) and we needed to focus our attention on what was absolutely necessary for launch.

So, after a few debates, we decided to compromise between no credentials and a full fledged password, and add a passcode. A passcode feels lighter than a password, and its easier to remember (hopefully!). But most importantly, adding the passcode allowed us to remove all that needed backend work from our plates. What did it take to add the passcode? A slight modification to our user schema and some hashing code to turn the plaintext passcode into a secure hash. Total time spent adding and testing the new passcode was about an hour (at most), I'm guessing doing it the other way would've taken a few days and most likely wouldn't have been as reliable (what happens if the email is delayed? What if it doesn't come at all?).

Arguably, the user lost a bit in this decision, they now have to remember a passcode, but by balancing the needs of the user with the needs of the developer, I think we were able to build an overall better, more reliable product. Most times, in the end, the user doesn't end up with your ideal interface, but hopefully you find the right balance between what you wanted, and what you ship.

I've pretty much always built my own blogging engine. In fact, I've spent more time building blogging engines than I've ever spent actually writing blog posts. The previous version of marcyes.com was built around the end of 2006, a few months after finishing my Computer Science degree, while I was waiting to start my first real job as a Patent Examiner at the PTO.

I was actually quite proud of that little blogging engine, it had all the common bloggy things of the day (trackbacks, comments, and rss) and a few others that no other blogging solutions had at the time (ajaxy image file management, expanding text boxes, SQLite backend, and link caching).

But over the last few years I've realized just how long in the tooth my blog had become (I hadn't touched the code in years, and it also hadn't had a design refresh), lots of whiz-bang features no longer worked quite right due to newer browser incompatibilities (but it worked in ie6) and just plain newer versions of everything. Also, I used my blog for a lot of non-blog things that I eventually replaced with other, better services. For example, my blog would cache links locally and make them searchable (using Lucene), but so could Evernote and it was available on my phone. It also turns out I don't blog much, so I don't have a lot of readers, and therefore I don't have a lot of comments (good thing I added all that comment moderation stuff), or rss subscribers, so those features got built, but never really got used.

Since my blog no longer worked quite right, and was way outdated aesthetically, I mostly stopped blogging altogether until I could update the software (the last public post was May 7, 2012, and the last private post was on March 12, 2013). Well, I've finally sat down and built a new blogging engine and gave the design a new coat of pain (with custom fonts and everything) :)

Why didn't I just use Wordpress?

I love Wordpress, but I think this answer from Marco Arment pretty much sums up my feelings on the matter also:

I'm a programmer, it's what I do.

I like building things, it's not only what I do, it's what I enjoy doing. Also, I like things a certain way and all the other blogging engines didn't do things exactly how I wanted to do them, so I wrote one that did do things exactly how I wanted to do them. Hopefully, I'll even blog a little more now.