In July 2010, I was the first one accepted into LaunchBox10, LaunchBox Digital‘s 3rd accelerator program. 130 startups applied. 7 were accepted. They said they’d never take a single founder. They made an exception for Slipstream.

This was a huge leap forward for me and my company. It meant moving across the country, from Berkeley, CA to Durham, NC for 3 months. It meant getting my first round of (seed) funding. It meant figuring out my first term sheet. It meant a ton of work packed into a very short period, all done by one person: me.

Here’s what I’ve learned:

1. I LOVE the Problem I’m Solving

   From day one, I had to tell a story. That story couldn’t just end with my progress so far, what I expect to achieve at LaunchBox or after, or something that trends up and to the right. Why should anyone but me care? I spent a lot of time thinking about where my startup fits into the world. This took me through the history of communication, from cave men grunts to social media and beyond. When I was done creating my own reality distortion field, my story convinced some of the best advisors in North Carolina’s Research Triangle Park (RTP) to back me. That vision kept me going regardless of how wonderful or awful any given day was.

2. It Doesn’t Matter How Much I Work if Stress is Low

   If I make it through the first month without burning out, I’ll be fine. That’s what I told myself. I tried to work hard and keep myself accountable, while not worrying much about things beyond my control. LinkedIn launched a neat product called Signal. Twitter itself promised to help information overload. News like that stirred me up when it first hit. But ultimately, I stayed focused on what I could control: my vision, my product, and how much feedback I could gather. That’s a lot fewer things than all those I can’t control. I don’t recall taking a single day off in October but I never burned out because I stayed focused on what I could actually change.

3. Many, Many Things Don’t Matter in the Beginning

   If you don’t ruthlessly prioritize when starting a startup, you’ll spend a lot of time working without making any real progress. This is incredibly hard to do without experience or people who have more experience than you. My advisors made a world of difference here.

   There are a ton of things your company could and should have, but how many are necessary today so you could understand if you have a business? This can range from having business cards, a company blog, exhaustive unit tests, and efficient code to buying domains, having a company name, being incorporated, or even having working code. What’s so important to blog about before finishing a prototype? What’s so essential to test or optimize before you validate that people want those features? Why commit to a company name, incorporation documents, or a single line of code before finding just one person who has your problem?

   What’s the simplest possible thing you can do today to learn what you need for tomorrow? How little do you really need to learn about the problem you’re solving, the solution you’re building, and the people you’re helping?

4. Missing One of the Essentials Can Be Devastating

   I built two Twitter clients before asking anybody if they wanted another Twitter client. I asked many related questions later, most notably: ”what would it take for you to switch to my Twitter client?” People gave me long lists of features, the most common of which I began adding to what I built. I did plenty of research and got plenty of answers, as one of my advisors would say. But I didn’t listen on a deeper level or notice the pattern. Maybe replicating every last feature of every other Twitter client and then sprinkling in my own wasn’t the best solution. This chart clarified things for me:
   
   A new Twitter client would mean trying to climb this mountain. Instead, I decided to build on top of it by working on top of Twitter.com. That took several months and discarding code that should have never been written if I just asked ”what would it take to switch?” up front. I didn’t learn enough before I started building too much.

5. Weekly Goals Really Move Me Forward

   I met with my advisors on a weekly basis. The goals we set for each week weren’t always met but regularly presenting progress to others really pushed me to get more done. Daily goals would have been too painstaking to set. Monthly goals would have created a lot more room to slack off or work on things that didn’t matter right now.

6. Doing a Startup Alone Makes Me Lazier in the Rest of Life

   Now, I’m less likely to cook, buy groceries, do chores, call friends, or even write blog posts like this one (that’s why it’s been nearly six months since my last post). A lot of this has to do with being a single founder. If I take a day off, my company takes a day off. After weeks of waking up with that feeling, it’s harder to make time for anything else. I temporarily optimized my time for my startup: more fast food, living that creates less chores to do, not staying in touch unless people reach out to me, and less writing.

7. You’re Not Alone, Even as a Single Founder

   Delegate anything that doesn’t have to be done by you and only you. Get an intern. Ask for help. Your girlfriend is nice enough to make banner ads for you. Your closest friends will tweet on your behalf. There are plenty of supportive people in your life. It’s foolish to not leverage any of them and try to do everything yourself.

8. Conflicting Advice is Wonderful

   From day one, I heard lots of conflicting advice. LaunchBox told us this would happen but the sheer amount and frequency of it was still surprising. Everyone seems to have succeeded and failed in their own ways. But instead of trying to go in a thousand directions or let things cancel each other out, just listen and be glad that you have so much diverse input to choose from. There’s no way you would have been able to come up with it all yourself.

9. No Incubator is Alike

   I’ve heard from friends who’ve gone through Y Combinator and got to spend some time with David Cohen and Brad Feld from TechStars when they came by to help us in November. From the amount of hands-on time, to what’s prioritized, to the quantity and quality of advisors, you wouldn’t believe how different all these programs are. I’m starting to think they have more differences than things in common.

If you’re building a new web app, you’d rather focus on the app instead of building complex data collection tools. You need a metrics solution along the lines of Mixpanel, KISSmetrics, or Google Analytics. But which should you use and why?

I evaluated Mixpanel, KISSmetrics, and Google Analytics with an early prototype of Slipstream, a new web-based Twitter client. I had previously built my own tool for collecting and reviewing user data but thought that I could save time using an existing solution. I picked these three tools because they were the main metrics tools I had heard of. I used most of the client-side features of all three tools.

What are you trying to learn?

Collecting too much data is as bad as not collecting enough because you won’t be able to act on it all. Most metrics tools can generate more data than you know what to do with so you need to focus on getting what you need up front. Before picking a tool, you should answer the most important question:

What am I trying to learn?

The answer affects which tool you choose more than anything else. For example:

• If you would like to justify your argument that a certain feature is being ignored, you can use Mixpanel’s event tracking to show that people aren’t using it, week after week.
• If you want to find where in your sign up process people are ditching your site, KISSmetrics could be a great choice because of it’s excellent funnels.
• If you need to show others that your social media efforts are more successful than any ad campaign you’ve tried, Google Analytics could give you a clue with it’s clear breakdown of traffic sources.

Once you know what you want to learn, it’s time to dive into the tools to see what will bring you closer to the answers.

Mixpanel pros & cons

Mixpanel is ideal for tracking arbitrary events in real-time. That means you can record when people do practically anything in your app. For example, when a user marks a tweet as a favorite in Slipstream, I can easily tell Mixpanel with a little bit of JavaScript:

mpmetrics.track("Added a favorite");

You can also add arbitrary properties to events. So if someone uses a particular feature like a slider that filters out tweets with a certain score, I can track the event (“Used slider”) and it’s property (“Tweets scored higher than”):

mpmetrics.track("Used slider", {
  "Tweets scored higher than" : slider_value
});

More impressively, the results can be viewed on Mixpanel.com in real-time. For example, I can see how often people are using my slider over the last few days:

and thanks to the “Tweets scored higher than” property, I can also see which values of the slider are the most popular:

Mixpanel is great for measuring retention, thanks to the following table. It helps me see which of my features, represented by each row as an event, are being used again and again over different periods of time:

Mixpanel also supports measuring funnels but I found it’s numbers were way off from what other tools recorded and, more importantly, the actual counts in my database. I don’t recommend using it.

This tool can’t measure and analyze traffic to your site, a chief strength of Google Analytics. Thankfully, the two can work together and the site and FAQs are helpful in explaining the differences between them.

Finally, Mixpanel has a somewhat cumbersome setup process. If you’re not familiar with metrics tools, it might take you some time to figure out where to integrate the Mixpanel code. There’s also no sandbox, so you’ll have to use up some data points against your monthly limit if you want to test that events are actually being tracked. Strangely, you can’t delete funnels or events so you’ll be stuck with test data. I recommend creating a test project when you’re setting up and trying to get everything working there. When you’re ready for production, create a new project and switch to it so your test data doesn’t get mixed in with your real data.

KISSmetrics pros & cons

KISSmetrics rocks at funnels. If you need to know how many visitors go from your landing page to pricing to sign up and how many drop out at each stage, it’s easy. You would first set up a few URL rules on the KISSmetrics site:

or via an event API very similar to Mixpanel’s:

_kmq.push(['record', "Viewed main timeline"]);

and then chain them together into a nice visual report:

Most importantly, the KISSmetrics funnels are very accurate. They consistently matched the traffic I measured with Google Analytics and matched up with the numbers in my database.

While their funnels are great, I didn’t find KISSmetrics useful for anything else. Even though their JavaScript API is almost identical to the Mixpanel one, there is no reporting interface that supports measuring retention. And while you can track properties for events, again like Mixpanel, I found those much less useful in my funnels.

KISSmetrics makes it easier to get set up with a really helpful debugger that loads an arbitrary URL on your site and shows you all the data KISSmetrics is collecting. This is much easier than the hoops I had to jump through with testing my Mixpanel setup.

Google Analytics pros & cons

Google Analytics showers you with page by page data about your site. You can see how much traffic you’re getting at any given point in time, where it’s coming from, and what pages people are hitting most frequently:

Google Analytics can measure funnels, which it calls Goals. They’re noticeably less accurate than the KISSmetrics funnels but not as far off as Mixpanel’s.

This tool also has event tracking but I found it very cumbersome to set up and could not get it to work. The Mixpanel and KISSmetrics APIs were much more straightforward for arbitrary events and properties.

If you just use Google Analytics to measure your traffic, it’s dead simple to set up: just include some JavaScript once and never worry about it again.

My Decision

I didn’t see a clear winner after poking around with the three tools so I decided to try all of them together. I’m really glad I did because this is the comparison table (based on my experiences from above):

They’re all great at different things! And since what you need to learn will change over time, you really need more than one tool in the long term.

My Setup

I’ve come up with a pretty flexible setup so that I never have to worry about sending unnecessary data to any of the services.

The Google Analytics script is only included in production so I’m not counting all the times I hit my site when I’m developing it. In a Rails app, that looks like this:

I stub out Mixpanel if I’m not in production:

<%- if RAILS_ENV == 'production' -%>
    <script type='text/javascript'>
    // regular Mixpanel include script
    </script>
<%- else -%>
    <script type='text/javascript'>
    var null_fn = function() {};
    var mpmetrics = {
        track: null_fn,
        track_funnel: null_fn,
        register: null_fn,
        register_once: null_fn,
        register_funnel: null_fn,
        identify: null_fn
    };
    </script>
<%- end -%>

The else clause lets me use the entire Mixpanel API anywhere I want in the rest of my app without generating any errors because it silently fails. This is a lot cleaner than having to check if I’m in the production environment for each call to the API.

KISSmetrics is also set up to silently fail in non-production environments:

<script type="text/javascript">
    var _kmq = _kmq || [];
    <%- if RAILS_ENV == 'production' -%>
    // regular KISSmetrics include function
    <%- end -%>
</script>

Both Mixpanel and KISSmetrics allow you identify a user with something unique like an email address, username, or id before recording other data:

mpmetrics.identify("<%= current_user.login %>");
_kmq.push(['identify', "<%= current_user.login %>"]);

This helps with accuracy so that the same visitor isn’t counted multiple times in a funnel or for an event (unless they actually went through the funnel or triggered the event multiple times). While this makes for better reporting, neither Mixpanel nor KISSmetrics let you see all the events any given user triggered or all the funnels he or she went through. You can approximate that functionality by setting an identifier property with each event. So instead of just reporting that the currently logged in user viewed the main timeline, I can specify who it was with a property and be able to filter the reports by that property:

mpmetrics.track("Viewed main timeline", {"User" : "<%= current_user.login %>" });
_kmq.push(['record', "Viewed main timeline", {"User" : "<%= current_user.login %>" }]);

This can be a bit cumbersome but per-user data is very useful because instead of retention in the abstract, you get to see exactly who is coming back. I hope both Mixpanel and KISSmetrics add this type of functionality in the future without me having to always set a “User” property.

Conclusion

Metrics tools help you learn a lot very quickly but you should focus on what you really need to learn before diving into any of them. Don’t be afraid to use multiple tools; their APIs are very similar and they’re usually good at very different things!

I believe the perfect landing page for a new product is somewhere between a single field form and a survey. No one likes answering a ton of questions but that doesn’t mean all you should ask for is an email address.

So how can you improve your next landing page? Here’s my approach:

1. Figure out the next critical thing you need to learn from potential users.
2. Pick a way for you to learn what you need directly from your landing page. If you can’t, let your landing page be the first big step to learning.
3. Attach the approach you came up with at the end of your landing page funnel. This usually means adding it after you ask for an email address.

Example 1: Figuring out which platform to build on

The following is from my first landing page for Slipstream, a new Twitter client that fixes information overload by highlighting tweets relevant to you. At that time, my most critical question was: “which platform should I build on?” I started with the typical approach, just asking for an email address. The problem is that most landing pages stop here:

Form 1

If visitors are compelled enough to put in their email address, why stop there? Ask for more information! After people provided their email, they saw the following:

Form 2

The second form directly asks my critical question: which kind of Twitter client should I be building? I find this data to be more reliable because it’s from people who’ve already shown enough interest to provide an email address. A public poll is easier to game and there’s less weight behind each vote.

The conversion rate on Form 1 was 7%. The conversion rate on Form 2 was 63%. More than half of the people who expressed interest in my product were willing to share more information at the first point of contact. This wasn’t in an email I sent them minutes or months later, it was as soon as they decided they wanted my product. Judging by later response rates from the same group, I’m certain much less than 63% of people would have answered if I asked the same exact question at a later time.

Why was the conversion rate so strong for Form 2? People were already invested in the product after providing their email so they were more likely to participate. I’m just continuing to engage them; not in a follow-up email some time later but with a small, actionable item now. A simple question at the right time takes them seconds to answer and gets me so much more insight than a cold email address.

Example 2: Recruiting collaborators, not users

Here’s another example from Slipstream. I needed to find users who would collaborate with me in building a better product, not just sign up, try once, and disappear forever. I can’t make people give feedback when I need it but I can set up that expectation right from the start with my landing page. This is a case of the landing page being “the first big step to learning what you need,” #3 above.

The first page people see includes a prominent call to action:

Page 1

When people click “Let me ride the Slipstream!”, they see:

Page 2

I’m still using two pages because the transition from Page 1 to Page 2 still approximates interest, similar to people giving their email in Example 1, Form 1. I can measure how many people care about my product (click the Page 1 call to action) and how many want to help (fill out Page 2) without worrying about scaring people away with too many questions up front.

As a side note, the second question on Page 2 was directly inspired by an excellent post by Cindy Alvarez with lots of other detailed information for finding people at an early stage.

The conversion rates weren’t as strong as Example 1 but almost 20% of people who came to Page 2 filled out the form. I’m still happy with the results and knowing that I’m getting signups for a very active beta.

How far could you take this?

If people are willing to give you all this helpful information, what’s the limit on how much you can ask? How much more will they answer after providing their email? That might make for a nice experiment but I chose to focus on the one critical thing I really needed to learn next instead of testing people’s patience with a series of forms. After all, when’s the last time you enjoyed filling out a long survey?

If you really want to ask that many questions, you should consider user testing, phone interviews, or face to face meetings. The qualitative feedback you’ll gather will probably give you richer answers than shallow survey data, where it’s harder to ask follow-up questions and nearly impossible to gauge the emotional tone of the answers.

Conclusion

Are you learning as much as you can from your landing page? Don’t just ask for an email address, engage your audience right after they provide their email! Base your engagement on the one critical thing you need to learn next. The conversion rate should be strong because people are already invested after providing their email. Finally, don’t abuse people by asking too much, stick to what you really need to learn.

What are you waiting for? Go learn more from your landing page!

There is simply too much stuff coming at us every day. And too much of that stuff is what your neighbor’s dog had for breakfast or what Lady Gaga is wearing, meaning, completely irrelevant to me. But I know there’s signal in all that noise, and I believe it’s worth finding.

I’m not going to resist the firehose because it won’t slow down. I’m going to help.

Meet Slipstream.

Slipstream is a Twitter client that filters your entire stream for tweets that are relevant to you. It determines what you’re into by looking at your favorites and then it just works. No specifying keywords, no figuring out how much you want to see from every person, no putting people into special lists. It’s that simple. Drink from the firehose without drowning.

People shouldn’t be overwhelmed with what they don’t need. Help me take this to the next level by signing up today (you’ll get early access and a big discount at launch)!

P.S. This all started in February, when I did pretty well at a certain Berkeley hackathon.

There are a few things that made this event stand out from others that I’ve recently attended. I recommend the following for a better startup networking event:

1. Curate Who Gets In

   I don’t recall which blog wrote about the event but they encouraged any founder to apply for an invite. I don’t know how many applied but I was very pleasantly surprised at the ones who got in. I didn’t hear a single bad pitch. That’s more than I can say for most open house events. I’m all for meeting a variety of people but curating who got in was one of those things you think wouldn’t work but it did quite well. Whatever the selection process was, it did a great job of bringing together a diverse group of founders with solid ideas.

2. Offer an Incentive Just to Attend

   Every event you attend could be the one where you meet that key customer, advisor, investor, or make one of a thousand other crucial connections. But there’s never any guarantee. You could attend a hundred events and not find anyone useful at the event. So it’s really nice when the host guarantees something valuable to some of the attendees. Typically, this means the attendees furiously compete for money or press (e.g. TechCrunch50, SF New Tech, etc.). Entrepreneurs Helping Entrepreneurs just raffled off mentoring sessions with respected founders. You were entered in the raffle just for attending. I like having no pressure to do anything but attend and the chance to be rewarded for doing so.

3. Don’t Force Competition

   This is closely tied to #2. Startups are competing all day (and night) with big companies, people’s mindsets, their runway, and time itself. It’s nice to have a break and simply bring people together instead of continue to push them after a full day of work.

4. Feed Founders Something Other than Ramen

   Silly, I know. But I enjoy eating what I wouldn’t buy for myself on a bootstrapper’s salary.

I could probably say more about the venue, the dress code, and other details but 1 – 3 are what really made an impression on me.

What good experiences have you had at networking events? What’s missing from my list?

1. Don’t Talk to Customers

   “Get outside the building” sounds easy when Steve Blank mentions it on a weekly basis but is really hard in practice. Not only is simply reaching out to people, cold calling, and swallowing your pride by questioning all your hypotheses really difficult, you have to do it over and over and over again.

   Ethan and Dan brought up one case where they were faithfully doing customer interviews but then got seriously sidetracked. They noticed a customer problem and simply went off and built a solution. What’s wrong with that? No one would buy it! Why? They didn’t validate the problem with the customer first. Customer Development, especially the first step, Customer Discovery, isn’t just a series of interviews or focus groups with your target market. It’s a continuous learning experience where you state your hypotheses and go out in the real world to (dis)prove them. So no matter how much you think you know about your target market or their problems (even if you are in your own target market like I am with my startup, Outspokes) you still have to validate, validate, validate the problem.

2. Solve Problems You’re Not Passionate About

   What do you really care about? What problems do you want to solve? Answering these questions for the product Ethan and Dan built when they simply noticed a customer problem and decided to solve it (#1) helped steer them back on track. They said that even if they had paying customers or could flip the company after a short period of time, they wouldn’t pursue it further. Why would you do a startup just to work on something you don’t enjoy or believe in? You could do the same for a lot more money and a lot less risk anywhere else.

3. Sell Your Solution Before it’s Validated

   Trying to sell a solution before you have validation is a dangerous game because you’re working in abstract concepts instead of concrete ones. If you sit down with a potential customer and walk through a paper prototype or screen shots, you might walk way with a lot of deceptively good feedback. The customer might even tell you feature by feature what it would take for them to buy but you can’t simply listen and add all the requested features to the product. Your job, as Steve and Eric have stressed many times before, is to find the minimum viable product (MVP) that solves the customer’s problem and leads to a sale.

   So what exactly is an MVP? Screen shots and paper prototypes are obviously not enough to solve anyone’s problem (they’re too minimal of an MVP). Building out a full solution for a given customer isn’t it either. Not only does that take too long but it probably won’t lead to something you can use with any other customers. So where’s the middle ground?

   Before you try and sell customers on the vision, you have to give them something tangible and listen to their feedback. Most of them won’t get it and that’s OK! 1/10 or even 1/20 is a good ratio of those who get it to those who don’t. Everyone else isn’t worth listening to yet because you haven’t gotten to the chasm (i.e. the mainstream). And how do you know when to actually listen to those inevitable feature requests? If multiple important customers request it and it’s not just a one-off thing to get one new customer, then it’s worth adding or at least seriously considering.

Ethan and Dan also shared a few tips:

• Charge from Day 1

  If those crazy early adopters won’t pay for it, who will? But if that really doesn’t make sense for your product, at least measure retention.

• Prototype Furiously, Even After You Have a Product

  I found it inspiring that Ethan and Dan keep building MVPs to test new concepts and of course, keep talking to customers to help shape everything Flowtown is working on. Don’t let one success make you lazy. Startups have to keep innovating!

I’m looking forward to more guest speakers like these! Thanks to Ethan and Dan for some great practical tips on implementing Customer Development. Check out their progress: Flowtown.

The challenge from Mozilla Labs was to design what would go in this new tab. Whereas most of the other entries focused on complicated metrics and cramming a ton of already existing browser features into the tab, I took a much simpler route in my design.

In my concept, each browser window is treated like a task that you can name, organize, and switch between via the home tab. You can think of tabs as sub-tasks or just things that help you accomplish your main task. Now beginning users, who typically stick to just one window or tab, can do more than one thing at a time while heavy multitaskers can stay organized instead of drowning in many windows & tabs.

UPDATE: Check out Slipstream here.

Having gone to this hackathon and SuperHappyDevHouse in July, I think the best thing about these events is just having a good opportunity to focus and the pressure to finish something. It doesn’t have to be pretty or stable or complete or even entrepreneurial. Showing an awesome demo of something you didn’t think was possible to a room full of other crazy engineers leaves you with a great feeling of accomplishment. I really encourage you to do a hackathon and surprise yourself in that short time period by actually building something instead of just talking about it.

Fun fact: I participated in this same event last year (last photo in the post). The result was ableset, a fun project that I briefly considered doing as a startup.

Entering Intel…

The first device that makes me care about both wireless sensors and cleantech is like Mint for energy (sorry for the low volume, the video was shot on my phone):

I’ve never heard the term WiDi until yesterday but this Wireless Display technology is almost-perfect (you can see the delay in transmission near the end). Again, sorry for the low volume:

I was having too much fun with this webcam-based augmented reality game to pay attention to the parallel processing technology behind it:

You can also check out photos of the event on flickr and I made a Twitter List for the other attendees. Thanks to Intel for hosting the event; I’d love to go again next year!