The Errant Idea

This post is the first in a series spread out over… well, let’s just take it one post at a time.

Back before Moby’s (wonderfully creative) breakthrough mainstream hit Play, and long before his subsequent albums calcified into mostly blandness, he wrote some of the most deeply felt, minimal songs you can find under the (broad, vague) label of “electronic”. Many were vocal, many can be classified as “dance”, but some of his most powerful works are simple, relaxed, lush instrumental tracks.

So it is with Living (which, if you don’t have any early Moby, I recommend picking up as part of the compilation MobySongs, which has a number of other breathtaking pieces). No matter how many times I hear it, the deceptively relaxed piece hits me in the gut by the end.

From its first notes, Living jumps directly into a simple melody: a straightforward theme on guitar, backed by quiet strings and a consistent snare-and-bass drum backbone. The melody very gradually builds, is embellished with plenty of small flourishes and wandering harmonies, becomes gradually more exuberant and rich, but still maintains the theme introduced in the first bars. It builds for a full seven minutes, in a constant crescendo.

Without warning, at the 7:00 mark, it starts to cut out as though a wire has come loose.  By 7:01 it is over, and the next song has begun.

If the mortality illustrated so effectively in this song is not one of the most primal motivations to stop coasting and create something important — for instance, a startup — I don’t know what is.

We were fortunate enough to meet briefly with Jason Caplain of Southern Capitol Ventures, a Raleigh-based VC firm, and Scot Wingo of Channel Advisor (and a rather successful serial entrepreneur). They both seemed to “get” the idea, which was encouraging — especially given the brevity of the pitch. They provided some useful pointers, though I couldn’t shake a feeling they were pulling some punches on real criticism; surely, at this early stage, the idea must have some significant blindspots. Granted, they only had a few minutes to digest the plan and provide feedback. Probably the most gratifying aspect of the meeting, though, was that they both requested invites to the alpha test when it’s ready.

Already we’re seeing that the world of startups — or perhaps, at least, startups in RTP — is a surprisingly small one. Scot made a suggestion that we talk with DisrupterMonkey, as there could be some overlap between our technologies and we might be able to help each other out. Ironically, Nick Napp — DisrupterMonkey’s founder — and I had been exchanging emails already, having met through Nick’s blog, and were planning on meeting for lunch soon — but neither of us really yet had any idea what the other’s working on.

Thanks to Scot and Jason; if luck holds we’ll be darkening their doors again at some point.

I received a sad little note in my inbox this evening, thanking me for my interest in career opportunities at Google but informing me that, alas, they had no openings that matched my resume.  They’ll keep my application on file, fortunately.

This would be somewhat depressing — had I actually applied to Google.  In the real world, though, I’ve turned down no fewer than five inquiries from three different recruiters at Google over the past three years.  As eager as I might have been to work for Google, I’ve never been interested in relocating to do so.

Perhaps there’s a bug — or a confounding inefficiency — in the recruiting systems in use by the most renowned information processing corporation on the ‘net today.

Or maybe they took the recent hiring throttle a little too much to heart, and have gone into reverse, rejecting people who’ve never even applied.

Or maybe they just wanted to turn me down for a change.

Whichever it is, sounds like this relationship is on the rocks.

[Update: Unsurprisingly, the true reason is much more mundane -- the (quite friendly) recruiter replied that she'd just hit the wrong button while updating my record, and (unnecessarily) apologized.  Ah well.]

“Everything should be made as simple as possible, but not simpler.”

– Maybe Albert Einstein

One can start a technology company by spending time working on a slick pitch and pounding the investors with pavement (that’s roughly how the saying goes, isn’t it? Doesn’t sound quite right) until one is given enough money to put a team together and finally sit down and start making a product. Or — at least in the web industry — one can start making the product first, and then go after money when one has something real to show off — both for a visceral demonstration of how you’re going to change the world, but also (and perhaps more significantly) because you’ll be that much closer to revenue, have that much less risk, and hence be that much more fundable. As a bonus, you have a nice built-in Plan B: even without significant funding, you can conceivably launch slow (as long as you can beg and borrow just enough cash to cover operations in the short term), start refining your product, make connections with users, and even start making revenue.

But there’s also a pretty clear downside. If you have a good idea, a viable opportunity with the right timing and a decent market, you can be bloody certain you aren’t the only one with that idea. That means if you don’t get to the starting line before your competitors, you’ll lose first-mover advantage — which isn’t everything, certainly, but is certainly better than a poke in the eye. And for whatever method B’s strengths, the necessarily small and often part-time team means that time-to-market isn’t (usually) one of them (though don’t forget that it does take time in method A to woo investors — time not spent on making a product).

Jectiv is taking the latter path, for better or worse. But this means that time and effort are precious, and the goal is to put together a prototype with the absolutely lowest effort feasible on the shortest timeline possible.

It helps, here, if the founder is also a software developer.

So you gotta pick technologies based on how efficiently they’ll let you build a product. Agile development is the name of the game, The Simplest Thing That Can Possibly Work is your mantra. Perfect is the enemy of good enough, yada yada. This can be a difficult process for perfectionist engineers who habitually do everything in their power to make things three times sturdier and more flexible than they strictly need to be.

But then, this is complicated further by the fact that, unless dollars fall from the heavens from gushing angel investors and VCs as soon as they’re given the faintest hint of a demo, chances are what you build now is the same code that you’re going to launch your beta with, and probably your public launch, and the first few years after that… so you’re not really building a prototype after all, you’re building The Product. Just the smallest, simplest, most important subset of that product you can identify. But you’ve gotta build that subset well enough that it won’t hold you back once you do make it. It’s bad enough to shoot yourself in the foot, but doing so just before running a marathon is a Bad Idea.

So: architecture is important. Just don’t furnish any of the rooms you won’t be living in the first day.

We’ve learned some lessons already while going down this road. Sometimes shortcuts aren’t as short as you’d like (ever notice there’s no reasonable Ruby Servlet-level solution under Apache if you’re not using Rails? Ever notice JAXB and RelaxNG simply will not work together?). Sometimes the most expedient technology is simply the one you know best.

We’ll keep trying to do this thing fast, but damned if we’re not going to do it well at the same time.

Developer’s journal, September 21, 2007. First urge to refactor. Dammit.

The Brain prototype isn’t even complete yet, and that developers’ eternal nemesis, the desire to change how it works, has already reared its ugly head. We’re not a NIH-obsessed shop here, but we make a conscious effort to keep unnecessary dependencies down, both to reduce risk and — in the case of dependencies on commercial products — hold down the cost-per-CPU, as we’ll be throwing a lot of CPUs at this thing, so they gotta be cheap. So — for a variety of reasons, most of which were simply expediency-related — we’re using Java servlets and have rolled-our-own dead-simple REST functionality based on simple regex pattern matching (one of the times we’ve really wished we were using Ruby). Not rocket science — REST is simple, that’s one of its biggest virtues. Nevertheless, we just looked a bit more into JSR-311 and Jersey, and realized that despite their youth, those APIs were actually thought through rather well and could’ve saved us some minor headaches, and resulted in that part of the codebase being significantl cleaner.

But… we really can’t justify switching our code already, given that the REST frontend is already done and there are miles yet to go. Right? Discipline. Curses.

The term “pitch” has a number of meanings, several holding a great deal of weight in American culture: the initiating action of our national sport; the measure of a singer’s tone; a thick, tarry substance using in roofing and paving; or a sudden, uncontrollable, and often tragic plunge over the side of a precipice.

A startup pitch has elements of all of these.

Plus, it’s bloody hard to write one (much less present one). You have this great idea in your head, you’ve thought it over and through in an endless loop for months, you know all the wonderful and subtle and worrisome ins and outs, all the opportunities and risks and challenges it presents. You know exactly how you’re going to exploit and mitigate and attack them (well, more or less), what needs to happen for you to succeed and what to blame if you fail. And you need to take this complex web of thoughts and distill it into an eloquent, engaging, brief package which anticipates all confusions and concerns, isn’t too vague or too technical for any member of an audience, doesn’t make you look like either an out-of-touch visionary or a beancounter without an imagination, and reliably leaves your audience hungry to hear more and desperate to be a part of what you have.

I mean, it doesn’t sound hard, but actually it is, believe me.

Plus, you need two to four versions of this: an elevator pitch (one paragraph, thirty seconds), a full pitch (a dozen slides, twenty minutes; sometimes more), optionally a one-page of prose to get sent and resent (one page never looks intimidating to read), and — if you’re old-school — a business plan (which will never actually be read by anyone outside your company anyway, so you needn’t worry about your audience).

Worse, you probably need multiple sets. Most likely one for potential investors, one for prospective employees, another for partners, and perhaps a last one for customers (depends on your business, of course).

Fortunately, I’m going to describe for you exactly how to do it.

A pitch should include an overview of your business (the problem you’re solving and what you’re providing to solve it), what your market is, how you’re superior to alternatives, how you’ll make yourself known to (and deliver your product to) your customers, how you’ll make money, how you’ll implement your solution (technical and process-wise), what technical challenges and other risks you face, and what your status and plans look like. Mix-n-match depending on format and audience, of course, and add audience-specific things like what kind of investment capital you’re looking for and what you’ll do with it, or how a partnership would benefit both parties, etc.

Well, that’s it, actually. I should revise my statement above to read “I’m going to tell you very vaguely in maddeningly hand-wavy terms how to do it”. If you want more detail, do some research. There are tons of templates and examples out there for each format; read a few, learn from them, and then throw them out and write your own — there’s nothing worse than following somebody else’s template and simply filling in the blanks. Read a book — Guy Kawasaki’s The Art of The Start has a decent overview of pitching, for example. Write, distill, rewrite, repeat. Most of all, keep it brief. Concise. To the point. Don’t repeat yourself. Avoid extraneous words. No repetition, no unnecessary detail. Don’t bore your audience. If you don’t get the joke by now, please re-read the preceding seven sentences a few times. As for me, it’s Wednesday, so I’ve gotta go rewrite my pitches.

By the way — if anyone is particularly interested in Jectiv’s pitch, email me. I’ll consider it.

Seth Godin is a brainstorm in a teakettle, a one-man tornado of ideas and insight which I have a feeling would pick me up and fling me to Singapore if I got within three meters. That said, I’d like to know what site he’s referring to whose pages-per-visitor distribution has a mean of 2.1 and a median of 9. Unless it has a hell of a lot visitors viewing negative pages, which sounds kinda scary and more than a little sinister. Perhaps he meant mode rather than median? Or maybe he was exaggerating (to a mathematical impossibility) to make a point? Either way, it’s a little disturbing because his entire point is that people fail to understand what these measures indicate.

(Or am I completely deluded and it’s possible to have a mean which is less than half the median when one has a distribution composed entirely of positive numbers?)

Marc Andreessen, in his incredibly insightful little gem factory, has tackled the concept of “internet platforms”, a term which has been bandied about far too loosely of late. Marc brings some much-needed rigor to the discussion, and in so doing provides a framework to look at what the future might hold for the web as a confederation of platforms. I encourage you to go read it — good stuff.

But it seems to me that Marc has missed a subtlety in the definition of what makes a platform. You might call this semantic quibbling, but I think it embodies an insight that took the technology industry a decent while to figure out — and which, if this new ‘platform’ stuff takes off, will be coming back full-strength in this new context. Anybody who ignores it does so at their own peril, because it is almost undoubtedly The Way Things Should Be, and quite likely The Way Things Will Be.

CliffsNotes for those that didn’t read the article. Marc defines platforms thusly:

• Level 1 – a service which can be accessed by arbitrary applications. Google Maps, flickr, etc. Lots of these, and they’ll probably continue to form the basis of 90% of interesting developments in the ‘net space over the long term (my opinion there, not necessarily Marc’s).
• Level 2 – a bulletin board in which you can come along and pin random applications; that is, a meta-application which provides a means for plugins to be visually integrated. Think Facebook.
• Level 3 – a virtual machine which allows third-party code to be directly executed directly on the primary applications’ servers. Marc quotes Second Life, Salesforce.com, and his Ning, but decries Amazon’s EC2, saying it doesn’t count because — my summary — it’s too hard to use and/or doesn’t provide unique vertical capabilities. I’m not sure I buy the difference, and I’d like to see a definition where your commodity datacenter doesn’t qualify as a Level 3 platform — ’cause I happen to think it probably does, under these definitions, just not one particularly streamlined to the kind of uses Marc’s interested in.

So to my quibble. A platform is not a pile of capabilities that makes it easier to develop applications (although that’s usually — hopefully — an important side benefit). At its core, the one thing you can’t take away from a platform without completely losing the point is that a platform is an abstraction which buys freedom.

It abstracts the application from the machine, sure, so that you can run arbitrary applications on a machine, and the machine’s creator doesn’t need to anticipate every application beforehand. That part is parallel to Marc’s discussions of internet platforms. But just as significantly, it abstracts the machine from the application — so that the application doesn’t need to know that the hardware is running with an AMD or Intel CPU with a particular cache size, or this video card and that network card, or a particular OS version, or this chipset, or a particular amount of RAM, and so on. On modern platforms like JVMs, .NET, Flash, etc, the virtual machine lets the application developer even ignore things like what type of CPU is being used, or even what operating system. HTML+Javascript provides an abstraction (albeit an imperfect one — platforms are rarely perfect) from the browser itself.

That freedom is very important, because it means that (A) the stuff supporting the platform can be changed quite a bit without affecting the applications, and (B) a given application will run on a whole hell of a lot of different implementations of a platform, and won’t become useless once, say, the latest Nokia phone is supplanted by something with a touch screen (yes, I realize there’s not a good platform for phones that supplies such freedoms; that pain is significant, and expensive, and exactly my point). So is the platform? Simple a set of policies, interfaces, mechanisms and whatnot that define that abstraction.

So what does this mean for internet platforms? What freedoms are we forgetting? Well, how about the freedom to run an application on lots of different sites? It’d be painful to write and rewrite my little app to run on dozens of different proprietary “internet platforms” — and so I probably wouldn’t, and that’s a shame as it limits the richness of the ecosystem. I’d also not in practice be able to rely on Cool New Site Q being around forever (as mentioned by A VC), so I’d rather my application wasn’t locked into that company and their continued goodwill. More significantly, perhaps, if I’m a business trying to introduce a new “platform” type site, wouldn’t it behoove me to use as many existing abstractions as possible to make it painless for developers to port their existing applications? The pressure for a good abstraction isn’t just from the user side, it’s from both sides.

So, where would these abstractions come from? There are two possibilities. One, they could be consciously defined. Some particularly visionary company (no, Jectiv isn’t in this business, alas) could think about the problem and define the abstractions, then write the premier platform implementation. Think, well, Windows. An open source group could do the same thing, as could a confederation.

The other possibility is that the platform(s) will evolve and become a standard via network effects. Say a couple platform-ish sites start supporting running user JVM code on their site/servers, and provide libraries tailored for JRuby, with a display environment built around portions of Ruby on Rails (this is just an example, people). It’d snowball pretty quickly — network effects are like that. Before you know it, Ning had better be supporting JVM and RoR code or they’ll get steamrolled by somebody who will.

Google “Bootstrapping a startup”. Go ahead, do it, we’ll wait.

Yes, we could’ve provided a link, but this is mostly just a literary device, so that’d defeat the point. And besides, you learn by doing.

Back? Good. So you see, it’s a pretty common process — many have tried it, many have failed, some have succeeded, many have gone quietly mad, others quite vocally so. Staring a business with little — or no — money. And in many cases, no time. Which brings us to our point: doing a startup while holding down a day job.

It’s about the rules. One must not mix and match; doing startup work on company time is a hanging offense. Thinking too hard about it during work is grounds for a decent lashing (unless it’s one’s lunch hour).

One must structure one’s time militantly. And if that means that the evening hours of 8-12 (or, more likely, 8-2) are allocated to the startup each Tuesday, Thursday, and Sunday, and… well… Monday… and Wednesday and Friday, and usually Saturday… well, that’s how it has to be. (And if there’s a new season of television starting — well, time to invest in some more hard drive space for Myth!) Having a supportive and understanding spouse — assuming one has a spouse — is, hence, absolutely vital, since chances are you won’t be seeing quite as much of them for a while. We make a point of not working — much — during the day on weekends, so as not to lose the plot completely.

But time’s not the only thing that needs to be divided. Computers are an obvious one, and email accounts. Misappropriation of company resources: stoneable offense (no, the other kind of stoned). Story time. We had a (curiously unproductive) coworker some years ago who, it turned out, had been spending most of each day creating a web-based business right from his office. His startup’s official phone number was his office phone. I believe he may have been the first and only person ever fired from that company. No, we didn’t stone him. C’mon, obviously he was a complete loon — there are laws against stoning loons. But I do notice that areaflorist.com no longer exists.

This all leaves the stickiest subject, though: you. You see, your current employer owns you. Varies by state, of course. First, one must look long and hard and to see if there are any conflicts of interest. If so, you’ve gotta tell your superiors, now; the alternative could be nasty, and could easily sink your dreams. (We’m assuming you’re going to be careful not to actually misappropriate any of your current employer’s technology; otherwise, please stop reading this and go read, I don’t know, Slashdot or something until you grow up). But worse, your company probably has rights to what you do in your free time, and even some rights to restrict what you’re allowed to do after you stop working for them. Those non-compete and employment agreements you signed, remember? Yeah, nasty. The best thing to do is to write a (reasonable but thorough) amendment to those agreements providing exceptions for what you’re working on (or better, get your lawyer to do so, if you have a lawyer yet; they’re good at this legal stuff). And get it signed. I know, doesn’t sound like fun — but if you’re not up for that, you’re really not up for creating a successful company from scratch, are you?

At some point amidst all these rules and details, note that one must also find time to actually concentrate on starting a company.

(Alternate title: “Crooks and Nannies: how to bootstrap a startup without stealing your employer’s code or failing to raise your children yourself”)

The internet doesn’t have enough startups, so we (and note that this is the editorial “we”, not the royal “we”) at Jectiv have decided to step up and remedy this situation. So starting today, –

Actually, that’s not right at all. Jectiv isn’t starting today, it began in the summer of 2007 (6 p.b.*) and has been labouring furiously in the meantime to develop — wait, that’s misleading as well. Jectiv was born two years ago. It had bit of a misspent youth, wasting the many angstful months of its adolescence spinning its wheels, knowing it could never amount to anything, while it heard terms like Web 2.0 and social media whispered from the shadows, teasing, mocking.

In the summer of ‘07, though, an epiphany struck which reframed its entire life. In this new light, suddenly its ideas made sense — suddenly, its existence had value. It began in earnest to make the preparations to show the world what it had known, deep in its heart, since its conception two years before. But to prove this, it needed things. Use cases. Monetization plans. Algorithm evaluations. Competitive analyses. Interface definitions. Mockups. Scalability plans. A pitch. A schedule — a, mocking, ambitious schedule. And — oh, merciful Turing — a Prototype.

Herein we will watch the young Jectiv as it sets out on its own, with dreams and ambitions bigger than its pocketbook. It will be an epic journey, fraught with the usual things with which epic journeys are traditionally fraught, not to mention the somewhat less customary elements of late-night coding sessions, stinging rebukes from investors, server headaches and alpha tests, and — most wondrous of all — a henceforth non-anthropomorphized protagonist. That’s right: the author shall hereby revert to the only slightly less pretentious and annoying affectation of referring to ourselves in the plural. If you’re a good audience, we might even start dropping that.

* p.b., post bubble