Research Then Development

A lot of companies talk about R&D -- Research and Development. If you're doing a startup, wipe that phrase out of your vocabulary!

It's simple, really. Investors don't want to pay for research. Research is open-ended. Research doesn't have an answer -- at best, it has a theory. I was talking with an entrepreneur recently who has an idea about something that might work. If it works, it might be cool. If it's cool enough, it might make money. That's all fine and good, but investors aren't going to pay for all those mights. They don't want to invest in a theory -- they want as much certainty as possible. Their ideal scenario is where you're already making money and you just need money to expand. Certainly, you can find investors who will take more risk, but the more uncertainty you can remove, the better.

Don't get me wrong -- research is important. Most of the time I spent on Puzzazz in the last year and a half was research. But unless you work at Bell Labs or Microsoft Research, don't count on somebody else paying you to do it.

Instead of R&D, you have to think about R then D, with investors coming after the R and some of the D.

What Are You Passionate About?

Adeo Ressi of the Founder Institute likes to ask the question "What are you passionate about?"

I love this question because there are many wrong answers but there is no right answer. Adeo doesn't ask this question because he wants the answer, though he is interested in what you say. He asks the question because he wants you to think about the answer. If you don't think about your passions and if you don't do something that you are passionate about in some way, then your chances of success go way down. This is true in life, but it's even more true if you're an entrepreneur.

There isn't a one-size-fits-all way to be passionate. It's all about you. My mother opened an optical shop and she wasn't passionate about eyeglasses -- she was passionate about service. She wanted everybody in town to be able to afford a pair of quality, stylish eyeglasses. She succeeded in her business because of her passion, which permeated every aspect of her business. And her shop changed how eyeglasses are sold in Lawrence. Yes, the change would have happened eventually (it's happened everywhere else), but her passion made it happen sooner.

As I wrote recently one reason that I killed my coordination services startup was that I wasn't passionate enough about it. I still think it's a great idea, but it's not my last great idea, and somebody else -- somebody else who is passionate about it -- will do it, probably even better than I would have. I wish them luck.

In case it's not obvious, passion is one of the big reasons that I'm jazzed about Puzzazz.

What are you passionate about?

Jazzed About Puzzazz

It took me a surprisingly long time to come to this conclusion, but I'm taking the experiment that is currently Puzzazz and turning it into a real business, hopefully a big one.

I've been passionate about puzzles for most of my life. In my spare time, I'm a professional puzzle constructor, with puzzles published in the New York Times, GAMES Magazine, and plenty of other newspapers, magazines, and books. I've constructed thousands of puzzles. I also co-founded Microsoft Puzzle Hunt and Microsoft Intern Puzzleday, two events that are still going on long after I left the company. So what was the holdup? Did I think I was too passionate about it?

Honestly, that was part of it. I wasn't sure I had the proper distance. I was concerned that, because I loved puzzles, it would cloud my judgment and I wouldn't be able to accurately assess the potential business. But there were two bigger components.

Helping the World

Throughout my career, there's been a common thread. I do things which help people, enable people, or empower people in some way. Usually, it's been stuff which made them more productive, like word processors, web publishing software, databases, and personal information managers. But I've also done educational software (twice, most recently at DreamBox Learning) and even an embedded system for hardware that assisted the kidney dialysis process. How can puzzles stack up with any of that?

It took other people to help me realize what is now obvious. Mostly they just echoed back what I was saying, but hearing it from somebody else really helps. Puzzles aren't just fun. Like my current Puzzazz users who visit the site every single day, many people find the fun and challenge of puzzles an essential part of their life. There's a reason fifty million people in the US solve crossword puzzles regularly!

And, in the online world, there are an awful lot of crappy puzzles and puzzle games out there. Providing people who want puzzles, who can't live without puzzles, a better experience is definitely making their lives better.

Building a Big Business

How can puzzles and puzzle games be a big business? It took me a long time to see this, too. Sure, lots of people solve crosswords. Sure, people go nuts for Sudoku. But a big business? When I did some research I learned that the casual and mobile games markets combined are about a $5 Billion market and growing strong. About 20% of that is puzzle games -- honestly, not very good puzzle games. So, the market is there.

I had started Puzzazz as a fun experiment. I picked a narrow range of puzzle types and I did a number of different things to learn what would work, from the different perspectives of puzzles, site features, and revenue generation. Over time, I've come to realize that it's not just an experiment -- it's a successful one. Even though it's a tiny site at the moment, it's making a large amount of money on a per-user basis. Even if I did nothing else, Puzzazz could be profitable by just increasing the number of regular visitors. But I've got much bigger and bolder plans than that.

Learning from Failure

It turned out that by trying to make sure I didn't let my passion cloud my judgment, I allowed it to stop me from seeing what is now pretty obvious. Puzzazz has the potential to be a really great, profitable business!

I spent a lot of the time between the time I launched Puzzazz, in September, 2008, and now, trying to start another business that didn't make it. I'm avoiding the same mistakes. I have a good, practical plan, without unreasonable deadlines. I'm not trying to "boil the ocean" and the plan involves steady growth, with multiple solid revenue sources. I'm doing something I'm passionate about, where I already have a ton of knowledge, both in puzzles and in building large, scalable, quality web services. I've already gotten traction and revenue without requiring skills that I don't have (although I have started looking for my first business person). And I'm having fun with it. That doesn't mean it's a cakewalk. Nope, there are plenty of hard problems to solve to get it done right. And, though I've started the process, there's a long way to go before Puzzazz is what I want it to be.

In other words, like any good puzzle, it'll be both fun and challenging!

Learning From Failure

What ever happened to Groupthink?

I get asked that periodically. If you don't know, Groupthink was the name I attached to the startup I was trying to build more than a year ago. I started with an ambitious, overly public plan, and an announcement that I was going to launch in 30 days. What I didn't say was that I had a huge, gigantic plan, and the planned 30-day launch was just the start.

If you've been reading my blog, you know the first thing that happened (I didn't launch in 30 days) and you probably know the second thing that happened (I didn't ever launch it), but now I'll make it official: it's dead and it's been dead for quite a while. I learned a ton in the process and I think my future endeavors will be stronger as a result, but I figure I might as well let everybody else learn as well.

So what was I building?

Put simply, I was building a coordination services company for small- and medium-sized businesses. I had what I thought was a pretty cool idea -- an incredibly simple, easy-to-use scripting language for coordination activities combined with a highly stateful backend system that let people build coordination functionality into their applications without having to know anything about how it all worked or even running a server. You could use the same scripts to send and receive emails, provide web forms, make phone calls, send SMS text messages, even contact somebody through XMPP chat. The system could work 24/7 with any application, even one written in Visual Basic in Microsoft Access, running on a single PC sitting in the corner of a small business that gets turned off every night. The system was designed so that anybody from an expert to a casual spare-time developer could use it, with the sweet spot being VARs and ISVs delivering custom applications to specific types of businesses. These VARs and ISVs don't have the experience (or servers) to do these things on their own, but Groupthink would have allowed them to add a wide range of coordination activities very quickly. It's not a perfect analogy, but think of it as Varolii for everybody else. And I envisioned that Varolii (a Seattle company) or one of their competitors, or possibly one of the giants like Google or Microsoft, would be the eventual acquirer.

I knew that I couldn't launch a platform without a product, so I decided I needed to build one. Plus, I wanted to keep the larger vision secret. After all, I was still figuring parts of it out. So, I made my first mistake -- I picked a first product that I personally wanted to have -- a group task manager I called Groupthink Projects. When people asked me how it was better than Microsoft Project or Liquid Planner, I said "they don't make phone calls." Unfortunately, my little demo problem was just a bit too big. I spent time on Ajax UI that it needed but that wasn't critical to my overall vision. Because I'd publicly said I was going to launch in 30 days, I ended up cutting some of the critical features (including mobile access) in order to try to make my deadline. Then, I got sick for a week and lost another week to moving my father-in-law into an Alzheimer's facility (which I talked about at Ignite Seattle 6). When you only have a month, two lost weeks is huge. By this point, I also knew that I'd pick the wrong first product, but I kept going. In retrospect, it's pretty obvious I shouldn't have, but, at the time, I felt I ought to make my deadline and shipping would be good for me.

The deadline came and went, without me launching. I started spending much more time on the backend -- the important stuff. I took time out to build a couple demo apps, including a version of Eliza that I built in a day. Talking with your psychiatrist via email or text messages didn't seem so compelling, so I added voice recognition functionality to my backend just so you could just talk to Eliza. It worked quite well, except for the huge delays caused by telephony provider Twilio's incredibly slow voice recognition.

The second first app

Although I never announced it, I decided to completely abandon the Projects app and concentrate only on the platform, but I still needed a first app. When I'd been talking with people, the coordination problem that resonated with everyone was the scheduling problem, and I had identified a very solid market in restaurant schedule coordination. I knew from field research I'd done in visiting restaurants that it was a huge problem, that paper, computer-based, and even web-based scheduling system hadn't solved the coordination problem of rescheduling people and dealing with missed shifts. You should see some of the workarounds restaurants use! So, I latched onto this as my new first product.

Dumb move. It was even bigger than the first problem and I had no passion for it. Worse, everybody thought I had morphed into a scheduling company or a restaurant software company. And all the potential investors I talked to wanted to see traction there first. Yup, traction in the first app which was really just to demo the platform. And I didn't succeed in finding any customers for the platform. Truth be told, I didn't try hard enough to get those customers -- after all, I'm not a sales guy.

The skills you have vs. the skills you need

And that relates to the final problem. I had picked a problem where I couldn't succeed without an early business partner, because way too many of those skills. I advise people all the time that they should pick problems that needs the skills they already have, yet here I'd picked a problem where about half of the skills I needed at the beginning were those I didn't have. Without a business person with marketing and sales skills, I couldn't get traction that would matter to investors.

I still really like the concept I had and I think it's inevitable that somebody will build a platform like it. I learned a ton from failing. I've moved on and I'm trying to make sure that I don't make the same mistakes next time around.

I'll write about that next.

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.