How to find angel investors

Recently I’ve been receiving a lot of emails from entrepreneurs asking for advice. I’ve learned a lot over the last few years and it’s always fun to try and apply the lessons I have learned to another situation. Although I feel unqualified to be giving out advice, I’m always willing to share and help where I can. One particular question that has come up a lot recently is how to find angel investors. I’m hoping to save some time and hopefully be helpful to more people by posting my thoughts here.

Let me start by acknowledging that I know we were really lucky.  TechStars helped us get connections and investors that would have been tough to get otherwise.  The short answer on how to find angel investors is apply for TechStars.  I’ve written before about how valuable TechStars was for both our company and for me personally.  Applications for the Boulder program are open until March 22.  If you have the chance and the desire to start a company, TechStars is the way to go.  I can’t recommend it enough.

If for some reason you can’t get into TechStars, don’t despair.  A little tenacity can get you a long way.

Start by identifying the best people you could possibly have as investors.  These people are easy to spot — they’re the guys with tons of industry experience, plenty of connections and mountains of cash.  Your first task is to find them, your second is to engage them.  The non-obvious part is that you should focus on finding good mentors first.  The money will come later.  As the saying goes, “if you want money, ask for advice.  If you want advice, ask for money”.  I’ve definitely found that to be true.  First, identify the people you want to engage and then see if you can get to them via your network using LinkedIn. It’s best if you can get an introduction, but even cold emails can work surprisingly well when they’re personal and well-crafted.

After you’ve found mentors and gotten them engaged in your idea, the best trick for converting them to investors is to implement as many of their suggestions as you can.  This is important because it helps them start to feel ownership in what you’re doing and they’ll want to give you money to see their ideas succeed.

Approach investors as you would a girl you want to date. Specifically, this is one of those situations where it’s wise to be indirect with your approach. Don’t go in for the kiss right away. Build the relationship first. When the time comes to bring up money, it will happen naturally.

Raising money is hard, but don’t get discouraged. Take every “no” you get as an opportunity to learn something and refine your idea. If you can’t get someone to say “yes”, figure out what you need to change or just go out and prove them wrong!

Hope that helps.  Good luck!

 2 comments

Did Google Reader just turn on full PuSH support?

Jesse claims the answer is yes.

This is a test to find out for myself.

Update: It worked!  If your blog is PubSubHubbub enabled any new posts will show up in Google Reader immediately instead of taking the usual 20-30 minutes.  Now you have more incentive than ever to get PubSubHubbub support on your blog!

 5 comments

My interview on Mixergy

If you haven’t heard the news yet, Rob and I have decided to shut down EventVue.  As you can probably imagine, it was a incredibly hard decision.  We’ve poured the last three years of our lives into EventVue and it’s tough to say goodbye.

One of the things we wanted to make sure we did was to share some of the lessons we learned.  Our hope is that other entrepreneurs can avoid making the same mistakes we did.  Rob wrote up a good post-mortem on our blog that tells our story in pretty good detail.

On Friday I had the privilege of being interviewed by Andrew Warner on Mixergy.  To be honest, it wasn’t my greatest performance.  I’ve been struggling with a cold and there were a couple times during the interview where I found myself wishing my brain worked faster.  That said, it was a real honor to have been invited on the show and be numbered with the incredible people that Andrew has put together. Speaking of which, if you’re not subscribed to Mixergy, you’re missing out on some fabulous content. Andrew has put together a great set of interviews from countless people I respect like Jimmy Wales, Seth Godin and Paul Graham to name a few.

My interview is about an hour long and is imbedded below.  I hope you’ll check it out:

 3 comments

Updated PubSubHubbub plugin for WordPress MU

I just updated my PubSubHubbub WordPress plugin to work with multi-user installations of WordPress and also verified that everything still works with version 2.9.1 of WordPress. If you haven’t installed the plugin yet, I encourage you to check it out.  It’s the fastest and easiest way to realtime enable your WordPress blog. I’ve now had over 1,200 downloads of the plugin and I’d be stoked if you added it as well. You can grab the latest version at:

http://wordpress.org/extend/plugins/pubsubhubbub/

As always, please let me know if you have any issues with the latest version.

If you’re curious what I changed, it turns out one of the secrets to making your plugin MU compatible is to register any of the settings you want to use.  This forum entry proved to be the solution I needed.

If you have no idea what I’m talking about, this post about PubSubHubbub is a good place to start.

Hope you’re having a fantastic weekend.

 4 comments

My talk from The AJAX Experience

Back in September 2008 I had the privilege of speaking at The AJAX Experience in Boston.  I talked about designing great forms and covered a lot of my own pet-peeves with forms on the web and shared some of the things I’ve learned along the way.

Today I got an email from a guy who found the video online and said he’d gotten some great stuff out of it. I had no idea a video even existed.  600 views and many months later I finally found out about it.  And in the spirit of better late than never, I’m posting it now.  The talk is about an hour long and covers a lot of my thoughts around form design, usability and creating experiences on the web that are actually fun!

One of the coolest parts for me was the amount of discussion this talk generated, both during the show and afterwards.  I had a great audience with lots of participation but I apologize for the parts you can’t hear since we didn’t have an audience mic set up.

And here are the slides:

As always, if you’re interested in having me speak at your event, let me know.

 2 comments

Openness and security go hand in hand

I just saw the post on Mashable about Microsoft downplaying the IE security hole. The one quote that caught my attention was from Microsoft’s UK security chief Cliff Evans. He said:

“The net effect of switching [from IE] is that you will end up on less secure browser,” and that “the risk [over this specific] exploit is minimal compared to Firefox or other competing browsers… you will be opening yourself up to security issues.”

He’s got to be kidding, right?

A key difference between IE and the open source browsers is what happens when a problem is found. If it’s IE we sit around and wait for Microsoft to fix it. On the other hand, if someone finds a bug in Firefox, hundreds of developers jump on it and race each other to get it fixed. Of course there are vulnerabilities in Firefox and there are bugs in Chrome – that’s just the reality of developing software. The important thing is that security issues get found and resolved much faster in an open-source environment.

I’m a firm believer that openness leads to greater security. This is a big reason why Unix is more secure than Windows. I’m not suggesting that Microsoft doesn’t have smart developers, because they do. They just don’t have the benefit of having constructive code reviews from thousands of smart developers who care so much about what they’re building that they’re willing to do it for free. It’s tough to compete with a group of people who are working out of passion instead of for a paycheck.

Openness leads to security, which leads to trust. If we ever implement online voting in America, the only way to do it would be to open-source the whole thing. Unless it was open-sourced, no one would trust the results. I’m not saying that everything in the world needs to be open-sourced. That’s not realistic. But when it comes to security, openness is crucial. It’s no accident that the encryption algorithms we use to transfer credit card numbers over the web are all open-source. That openness gives us the confidence because we know these algorithms have been tested by hackers all around the world. They’ve gone through the fire and somehow still came out standing.

If you ever need to make sure something is 100% secure, the first-step is to open-source it.

 2 comments

Backwards compatible window.postMessage()

You can find the latest version of this library on Github.

Simple cross-domain messaging

This blog post explains how to implement a backwards compatible version of window.postMessage() to handle all your cross-domain messaging needs. If you’re in a hurry, you can skip directly to the demo or just grab the following files:

Background

One of the trickiest things you will ever run into on the web is the same origin policy. The same origin policy basically limits how scripts and frames on different domains can talk to each other.  The same origin policy is an important part of your security on the web. For example, it prevents someone from being able to steal your password from another frame on the page. The annoying thing is there are sometimes perfectly valid reasons for frames on different domains to need to talk to one another.   One good example of this would be the Facebook Connect library where facebook.com needs to be able to communicate with non-facebook.com domains.  Over the years we’ve developed a series of hacks to work around this browser limitation. Some developers have used flash while others have relied on a window.location.hash hack.  Facebook worked around it by getting people to install a cross domain communication channel.  It got pretty ridiculous until the browser makers finally decided to give us a way to do cross-domain messaging without all the nonsense.  The result was window.postMessage() which is supported by the latest browsers like Firefox 3, Safari 4, Chrome and IE 8.  Unfortunately, as usual we’re going to need a backwards compatible version before we can take advantage of this new functionality.

I found a couple great examples of people who have tackled this already.  Luke Shepard wrote xd.js which is part of the open-sourced Facebook Connect code.  I also found Ben Alman’s jQuery plugin which does a really nice job.  Both of these scripts are great, but neither fits quite right with my needs.  For one, I wanted the smallest possible script written in pure JavaScript.  I’m a fan of jQuery, but since I’ll be installing this code on other people’s domains I can’t assume that jQuery will be available and while I could load it up it’s important to keep the file size small.  So what I did was start with Ben’s code and took out all of the jQuery dependencies. Here is the result:

The code

// everything is wrapped in the XD function to reduce namespace collisions
var XD = function(){

    var interval_id,
    last_hash,
    cache_bust = 1,
    attached_callback,
    window = this;

    return {
        postMessage : function(message, target_url, target) {
            if (!target_url) {
                return;
            }
            target = target || parent;  // default to parent
            if (window['postMessage']) {
                // the browser supports window.postMessage, so call it with a targetOrigin
                // set appropriately, based on the target_url parameter.
                target['postMessage'](message, target_url.replace( /([^:]+:\/\/[^\/]+).*/, '$1'));
            } else if (target_url) {
                // the browser does not support window.postMessage, so use the window.location.hash fragment hack
                target.location = target_url.replace(/#.*$/, '') + '#' + (+new Date) + (cache_bust++) + '&' + message;
            }
        },
        receiveMessage : function(callback, source_origin) {
            // browser supports window.postMessage
            if (window['postMessage']) {
                // bind the callback to the actual event associated with window.postMessage
                if (callback) {
                    attached_callback = function(e) {
                        if ((typeof source_origin === 'string' && e.origin !== source_origin)
                        || (Object.prototype.toString.call(source_origin) === "[object Function]" && source_origin(e.origin) === !1)) {
                             return !1;
                         }
                         callback(e);
                     };
                 }
                 if (window['addEventListener']) {
                     window[callback ? 'addEventListener' : 'removeEventListener']('message', attached_callback, !1);
                 } else {
                     window[callback ? 'attachEvent' : 'detachEvent']('onmessage', attached_callback);
                 }
             } else {
                 // a polling loop is started & callback is called whenever the location.hash changes
                 interval_id && clearInterval(interval_id);
                 interval_id = null;
                 if (callback) {
                     interval_id = setInterval(function() {
                         var hash = document.location.hash,
                         re = /^#?\d+&/;
                         if (hash !== last_hash && re.test(hash)) {
                             last_hash = hash;
                             callback({data: hash.replace(re, '')});
                         }
                     }, 100);
                 }
             }
         }
    };
}();

Usage:

There are two parts to using this code: posting and listening. Both are relatively simple. To post a message we call XD.postMessage with a message, a URL and the frame that we want to talk to. Notice that we start off by passing the URL of the parent page to the child frame. This is important so the child knows how to talk back to the parent.

// pass the URL of the current parent page to the iframe using location.hash
src = 'http://joshfraser.com/code/postmessage/child.html#' + encodeURIComponent(document.location.href);
document.getElementById("xd_frame").src = src;

function send(msg) {
    XD.postMessage(msg, src, frames[0]);
    return false;
}

Setting up the listener on the child is also easy to do:

var parent_url = decodeURIComponent(document.location.hash.replace(/^#/, ''));

XD.receiveMessage(function(message){
    window.alert(message.data + " received on "+window.location.host);
}, '/index.html');

I recommend taking a look at this barebones example to understand better how the various pieces fit together. This is still a work in progress and I’d love any feedback you have on it. I’m particularly interested in adding Flash as an alternative method before falling back to fragments. This is what the Facebook code does and I like it because it eliminates the nasty polling every 100ms.

Got other thoughts on how to make this better? Let me know in the comments.

 57 comments

No risk, no reward

If you don’t miss a flight every now and then, you’re wasting too much time hanging around in airports.

If you’re a mountain biker without any scars, maybe it’s time to earn some.

If you haven’t wiped out in a while, maybe it’s time to push the limits once again.

If there is no danger of your heart being broken, maybe you need to take a chance at loving more.

Here’s to 2010, missed flights and new scars with awesome stories behind them.

 5 comments

The bell

Jeff Bezos loves to tell the story of the bell that rang in the Amazon office every time they made a sale.  Of course, after a while it began ringing so often that they had to turn it off.  The important thing was that the bell served as a constant reminder to the entire team of what they were trying to accomplish.  The bell unified the team behind one goal and gave them an obvious way of knowing how they were doing.

I was late to the party in understanding the power of the bell.  I’ve since been eager to catch up and install some modern-day bells for EventVue.

Earlier this year we started sending out nightly metrics emails to everyone in our company along with some of our close mentors and investors.  This email includes key metrics like how many people signed in that day, how many people used Discover, how many people shared with friends, etc.  Recently we took it one step further and started publishing real-time updates into the Socialcast community that our company uses for internal communication.  We publish stories as people use our products and reach meaningful milestones like inviting their friends to join them at an event.

The result is quite powerful.  It helps us really feel what’s happening in addition to seeing the cold, hard numbers each night.

Of course, there are a lot of different ways you could accomplish the same goal, but building on top of the Socialcast API has given us a few unique benefits:

  • Our bell can be heard anywhere we have an internet connection.
  • We don’t have to change our behavior.  We’re already using Socialcast every day.
  • Everyone has their own volume control.  The stream can get noisy, but Socialcast makes it easy to filter.
  • We can search, filter and catch up later if we miss anything.

If you haven’t installed a bell in your office yet, why not give it a shot?  You’ll find yourself encouraged by some things and discouraged by others.  One thing is for sure:  you’ll learn more about your users as a result.  And at the end of the day, that’s what it’s all about

 7 comments

If only we lived in an ideal world

After my last post on the importance of IP addresses, I emailed a few friends I respect for feedback.  I’m glad I did because there’s an important aspect I neglected to address.  Brett Slatkin made this comment:

The post makes sense. What I’d focus on in part is that reputation based on IP is fundamentally broken, which is why email sending with SMTP and feed fetching through polling are both fundamentally flawed. We need better protocols that use client tokens (like OAuth) to do rate limiting instead of using just IP addresses.

I hope this would be obvious, but neither SendGrid nor SuperFeedr are optimal solutions.  Let me be more blunt.  In an ideal world, neither company would have reason to exist.

I also understand that as an entrepreneur you have to dream big while also realizing that significant change usually doesn’t happen overnight.  One day we may all drive Tesla’s, but that doesn’t mean we can do away with our gas stations quite yet.

I’m a firm believer that companies should focus on solving the problems that exist today while being ready to adapt as better solutions get adopted.  For the sake of completeness, here’s the missing footnote to my last post:

The ideal solution to the problem of polling feeds is PubSubHubbub.  The ideal solution for accessing authenticated APIs would be for parties to use token based authentication like OAuth or WRAP.  And as Isaac Saldana mentioned in the comments, the ideal solution for email reputation would be widespread adoption of DKIM which moves the reputation to the domain instead of the IP address.

Those are the ideal solutions.  Too bad we don’t live in an ideal world.

 4 comments