The Founder Institute

At first glance, I might not seem like the typical candidate for the Founder Institute. I'm not a fresh entrepreneur. I've been doing it a long time and I've had both favorable outcomes (acquisitions) and failures (losing a lot of money). And I even serve as an advisor and mentor to a lot of other entrepreneurs. But, through it all, two things have remained constant: I'm an entrepreneur at heart, and I have a lot to learn.

And those two things are the key reasons that I'm excited that I just got accepted to be part of the Founder Institute's winter session in Seattle.

What is an entrepreneur anyway? I'm not giving anything away to tell you that the first question on the application form is why you want to be an entrepreneur. And I certainly hope I'm not giving anything away by saying I think it's a trick question. Maybe you can want to be a good entrepreneur, or a successful one, but I think being an entrepreneur in the first place, like being a writer, or a musician, or an artist, is about being true to yourself. Do you want to build things? I know I do! I love the challenges of figuring out the problem and figuring out the solution. And I love making something out of nothing. The opportunity to be around a bunch of other like-minded people over a three-month span would be valuable all on its own.

What do I have to learn? Tons, it turns out. Earlier this year, I wrote the absolute best business plan I had ever written. I created the best presentation decks I had ever written (although I didn't present them that well, ironic for someone who's a very good public speaker). I had a pretty good prototype to go with them. And it was for a business that I really think could make it and be hugely profitable. I'm a CTO, a product guy, and, yes, a visionary (though I don't really care for that term). But, I'm not a CEO and I was trying to start a company that really needed one. In looking at the Founder Institute curriculum, about 90% of the content is centered around the areas that I'm weak in, the places where I still have a lot to learn. If this were CTO camp, I could teach it. But it's a business camp and I'm happy to be a student.

And that brings up the third piece of the picture. I had the good fortune to run into Chris Early, the local person from FounderWise who's running the Seattle session, at an NWEN breakfast a week ago. I'd been thinking about applying but wasn't sure. Chris impressed me with his vision, understanding, and focus. He pushed me over the edge with information. They're looking for a wide range of people, from fresh entrepreneurs to veterans, they're hoping for a mix of talents, meaning both technical people and business people, and they're expecting a variety of representative industries, not just high-tech. But the common thread they're looking for is people who will take what they learn and run with it. All the mentors (aka instructors) are selected for the sessions they're teaching based on their specific knowledge. Each week, there are three different instructors who are best suited to the topic at hand. The sessions aren't those cattle call lectures we all remember from college. They'll be much more interactive and there's out-of-session "homework" every week. I can't predict exactly what all that means, but I loved how Adeo asked each person who asked a question at the UW session what they were passionate about. The Founder Institute isn't about one-way communication or lectures from on high. It's about guidance and learning. And that sounds good to me.

I don't know if the Founder Institute is right for you. It depends on who you are and what you want to do. But I'm really looking forward to it.

I Want To Like Microsoft Azure

I want to like Microsoft Azure. I really do. I've been using Google App Engine for more than a year now (Puzzazz, SeattleTechCalendar and the FriendMosaic front end run on it). I'm also familiar with Amazon's Elastic Computing Cloud or EC2 (the FriendMosaic back end runs on it). Both have advantages and disadvantages.

Google App Engine is a wonderfully scalable system that requires programming to a very specific, narrow API and use of Google's BigTable database rather than a more traditional SQL database. It's super easy to get going (literally, you can have an app running in the cloud within minutes of installing the SDK). Scaling is completely, totally automatic, and you pay for the capacity you use, when you use it. But, App Engine isn't appropriate for apps that require a lot of processing power, and you can't easily take the application elsewhere.

In contrast, EC2 is very flexible. You can run Unix, Linux, or Windows on virtual machine instances and you get pretty complete control of these instances, as if they were real servers. And, if you grow big enough to afford your own servers, its easy to move those instances to your own physical boxes. But, it's much more of a pain to get going and scaling is awkward. You have to allocate complete instances of different sizes as if you're deploying real hardware and to change your capacity to respond to changing needs, you have to add or remove instances. If an instance crashes, you lose any local storage on the machine. And, you pay for active instances even if they are sitting there doing nothing.

When I first heard about Azure, I thought it was a brilliant way to split the difference and get the advantages of both systems -- a wonderfully scalable system with great flexibility. Sadly, Microsoft has produced the exact opposite -- a poorly scalable system which requires developing to a special API that limits flexibility. In other words, the disadvantages of both systems.

Azure uses instances, just like EC2, which means that scaling is by instance, not automatic. At launch, apparently you'll be able to configure this to happen semi-automatically, but it's still the case that you have to run an entire instance even if you have no traffic for it and you have to decide when additional instances get added and what capacity they have, instead of having it just work, as Google has done with App Engine. And, Azure isn't Windows. You can't just take a Windows application and plop it onto the box. In fact, you don't control the virtual box. You can't install helper applications on it. Instead, you have to program to the Azure APIs, meaning can't easily take an Azure-based app elsewhere (or take a non-Azure app and just have it work, like you can with EC2).

It's not too late. Azure does have some of the advantages of both App Engine and EC2 (a simple model, flexible, powerful), plus Azure has some nice advantages all its own. The way they've defined roles is very nice (especially if they clean up the definition of the worker role, which I'm assuming they will) and potentially more flexible than the App Engine way of doing everything through a URL. A certain amount of sandboxing can be a good thing. And, of course, C# can be a joy to program in, with the best IDE and debugger on the planet (I'm still waiting for a decent Python debugger).

And, really, there's only one (big) change necessary. Azure needs to automatically scale, so developers just create code for the roles and everything else works, with as much hardware as necessary allocated on demand (and not allocated when you don't need it). With their architecture, Azure could accomplish this really well, if they choose to do so. Then they can add additional role types with different feature, performance, and scaling properties. But, if they don't do this, I don't know why anybody would use it over the competition.

Update: Microsoft has created a new site MyGreatWindowsAzureIdea tbat's worth taking a look at. It's a voting site using UserVoice. The current top votegetter is "Make it less expensive to run my very small service on Windows Azure," with twice as many votes as the runner-up.

You Can't Outsource Yourself

Outsourcing is a buzzword these days, but you can't outsource your core competency.

Three times in the last few weeks, I have had meetings with consulting clients or potential clients who believed that they could build a technology company with no developers -- in essence, that they could outsource their core competency. I'm not talking about a remote developer, or a virtual development team. I'm talking about companies that believed they could hire a consultant or a code shop who would build their product for them. After all building the product is the easy part. It's the idea that's the hard part. Or selling it that's the hard part. Here's a tip: it's all hard.

There's a simple, important question you have to ask when deciding what you must do and what you can outsource. What is your core competency? What is the thing which is essential to your value proposition? What is the unique value that you provide that your competitors don't? Who are you?

You can't outsource whatever it is that defines you. It's not possible that your unique value proposition can just be put together from off-the-shelf components by a rent-a-coder shop. If it were possible, then your unique value isn't very unique, is it? And if you actually pay a lot for consultants to build you something truly custom, what happens to all the lessons learned during development? If there aren't a lot of lessons learned, chances are the product wasn't developed correctly. You need to own that knowledge -- it's essential for you to grow as a company.

I'm not saying that you can't ever outsource software or software development. For example, I've outsourced the software that powers my blogs -- they're built on Blogger. But, the value of my blogs is in my content, not the code that runs on the server. By using Blogger, I can concentrate on my blogs' unique value -- my unique content. But I'm not about to outsource software development when I'm building a software company.

Open Source Client Simulator

In these days of web 2.0, it's quite common to build clients and servers that communicate with each other. Debugging the communication can be a pain, especially if you're not in control of one end of the connection. This is particularly the case with a service like Twilio, one of a bunch of telephony providers that you can connect your server to. With Twilio, every live test you do requires making or receiving a phone call. This is arduous, takes time, and costs money in phone charges.

So, I wrote a simple simulator to simulate the Twilio server contacting my server, which I released today as open source.

Chlorine is a simple, small (400 lines of JavaScript), and easy-to-use client simulator. It doesn't do much but it does the essentials to allow you to debug a protocol:

• Submits requests to your server via GET or POST.
• Displays the results back in a readable fashion, minus the contents of comments and CDATA blocks.
• Supplies a link you can use to GET the raw response from the server if you need to inspect it (for example, when the server doesn't actually return XML, so it can't be parsed)..
• Turns any attribute or text value in the result that looks like a URL into a form which will submit that URL back to the server, along with any parameter values you specify.
• Allows you to configure it to add additional parameter fields to each form that is created.

Chlorine itself is generic, but I've included a version which is configured for use with Twilio. 

Chlorine is available at http://chlorine.googlecode.com

Twitter Puzzles on Puzzazz

I launched a new class of puzzles on Puzzazz today -- Twitter Puzzles. Unlike the Daily Puzzles, which will continue to run every day, Puzzazz Twitter puzzles run continuously. Just follow @Puzzazz on Twitter to get them. In addition to the delivery system, they're different in another way. Each puzzle is a "successive reveal" puzzle in which you get a series of clues. The more clues you have, the easier the puzzle is. But, once you know the answer, you'll want to tweet it, since the first person to tweet an answer is designated the winner and immortalized forever on the puzzle's page on Puzzazz.com. If you weren't first, you can visit the puzzle's page to verify your answer (or get additional clues). And don't worry -- the solution is hidden unless you choose to reveal it to preserve the fun.

The puzzles are a mix of different puzzles, ranging from Hangman Trivia to What Goes With? puzzles. You can always see the current puzzle on the site at http://www.puzzazz.com/s and get more information in the FAQ.

These puzzles are part of the broader strategy of extending the Puzzazz brand. I'm interested in what you think.

Learn From My Mistakes

I broke a lot of my own rules in my talk at the First Look Forum and, unfortunately, it wasn't the best thing to do. I've spent a lot of time listening to advisors over the last few months. And, most of the time, the advisors know more than me, so I've learned a lot. But, sometimes, you have to trust your gut. By not doing that, my presentation did not accurately reflect the potential of my company.

Before I go on, let me make a few things clear. First, it wasn't a total loss. I made some great connections with potential investors and I have some follow-up meetings scheduled. It just wasn't as good as it could have been and I didn't have the opportunity to do my full 10-minute pitch to the room full of investors. I would have liked to do that. And, second, I'm not faulting any of my advisors. The buck stops with me.

The First Look Forum process is unlike anything I've gone through before and, to some extent, that led me to some bad decisions. We started by creating 10-minute slide decks and, then, after they were created and reviewed, we created shorter 3-minute slide decks. Almost all of the 3-minute presentations at the forum were clearly shortened versions of the 10-minute presentations. As I noted in an earlier blog post, I started that way, but I ended up with a 3-minute pitch that was completely different.

If you've ever heard me speak, you'll know that I never use notes. I speak extemporaneously and I do a pretty good job of it. I will sometimes create an outline, but it is a very brief outline and I never refer to it during a talk. In thinking about it, the last time I gave any sort of a scripted talk was in 9th grade.

However, 3 minutes is really short -- it's easy to run over, as most of the presenters did. And, over and over, my advisors kept telling me of all the things I had to make sure to include. So, I ended up scripting the talk. That was mistake number one. Next, I rehearsed the talk in front of a lot of people. This was good and I kept tweaking it. By Saturday, I really had it down.

On to mistake number two. On Sunday, one of my advisors told me they thought that the pitch was only a B+, that to make it an A, it really needed work. I had too much fluff (compelling fluff, but nonetheless fluff) and I needed to cut that out and add some critical things that were missing, like a brief discussion of revenue. I think her advice was basically correct, but I should have ignored it, for two very important reasons:

1. By taking a pitch that I really knew and replacing it with a pitch that I didn't, I made it worse, not better. I could have elevated the B+ pitch to an A with good oratory. But a poorly delivered A pitch can easily fall to a C level. I didn't have the time to do the changes and I should have deferred them to the future.
2. Most of the other pitches, including the majority of the ones chosen for the 10-minute session, had more fluff than I had, and far less in the way of fact.. It turns out that the investors were looking for the grab, not the facts, in deciding who they wanted to vote for. My original pitch had more grab and fewer facts, especially given the delivery.

Whenever you're in unfamiliar territory, it's a good idea to assume the worst. I considered having an audio clip as part of my talk, but decided that there was no guarantee that we would have sound. I also could have had a little demo using the Internet and my cell phone, but I decided there was no guarantee of a net connection or that my cell phone would work (in fact, there was no internet connection available, which we didn't find out until Monday). I brought a backup of everything on a USB drive just in case something got messed up (and, in fact, the wrong version of my presentation was included in the deck, so that came in very handy).

That leads to mistake number three. We were told there would be a podium. If I'd been able to put my notes on a podium, I could have spoken more naturally and the notes wouldn't have mattered much. The fact that there would be a podium allowed me to make mistake number two above. But, the podium had the laptop and was basically in the way, worse than having no podium. If I had assumed the worst -- no audio, no podium, etc., I would have been in much better shape.

So, in short:

• Listen to advice, but do follow your own rules as much as you can.
  
• Time pressure trumps good advice. Defer it to later if you don't have time to do it right.
  
• Assume the worst, most inhospitable environment. You won't be far off.
  
• Learn from your mistakes. Or, even better, learn from mine.

Making A Fast Pitch

It always takes longer to write less. I already had a pitch for a 10-minute talk, but the first pitch in the NWEN First Look Forum is a 3-minute pitch. And, I only get to do the 10-minute pitch if I'm in the top five, so the 3-minute pitch is actually more important.

The 3-minute pitch deck is limited to five slides which, unless you're the fast talker from those old FedEx commercials, is about the most you can do anyway. So, I took my five key slides, basically the five slides on the topics they recommended we cover, and then I crammed some extra points into them to make sure I covered everything. Then, I did a practice pitch to my NWEN coaches. Ignoring the fact that my 3-minute pitch took me more than 4 minutes to deliver, it was a totally flat pitch. Even I wasn't interested in hearing more. What went wrong?

Well, in trying to cram as much as possible into the time available, I took out the soul. I took out the excitement that I had worked hard to get into the longer pitch. And I crammed in way too much detail. The 3-minute pitch, like the 30-second elevator pitch and the one pager I discussed earlier, should be all about excitement. You don't need tons of detail in the 10-minute pitch and you need even less when you go shorter. Remember, the point of a short pitch is not to get investors -- the whole point, the only point is to get people to want to hear more. So, I scrapped everything and re-created the deck from the top down -- about customer pain, the excitement of addressing the need, and what the solution looks like. In one case, I had a slide with eight long bullet points. The new slide is just a diagram, which I've also added (in a smaller size) to the longer pitch deck.

I don't know if a picture is worth a thousand words in a pitch deck, but sometimes it can be worth eight bullet points.