Recipes for startup failure

November 20, 2012 | 4 comments

Technical co-founderPaul Graham’s essay, How to Get Startup Ideas, is long but very much worth reading. Normally I’d pull a quote, but it’s a valuable piece from start to finish, and it’s hard to know what to choose. Go read it, then come back.

He makes clear that, more than anything else, if you want to be a tech entrepreneur you need to live in the future and build what’s missing. That’s an important idea, which we can break into parts:

  • Have a great idea
  • Build it.

Sounds simple, right? But that second bullet is the hard bit. It’s not anywhere near enough to come up with a great idea, although you can’t have a great startup without one. (Paul has some valuable thoughts on this, including turning off your “sexy” filter and allowing yourself to see problems whose solutions are going to be a pain in the ass for you, but valuable for your customers.) You also have to build it.

This is a complicated field, on which a lot has been written. But I think there are a couple of things that will never allow you to build a successful software-based startup.

If you’re not a geek, don’t outsource the product.

Forget what you may have heard about IT projects. Building a technology company isn’t as simple as coming up with the idea, sending a plan to an outsourcing company and then reselling the result. Not only will your technology be frozen in time, with the outsourcing company effectively holding all of your value (you’ll need to hire them again to make improvements, and it’s important to realize that software products are never actually done), and not only does it send a clear signal that you don’t really care about your product, but it’s also a certainty that no outsourcing company cares as much about your startup as you do. An outsourced software product will always be inferior to one produced in-house by a dedicated team.

There are no shortcuts. Your startup must know how to code. And you, as a startup founder, must learn enough about the technology to be able to make informed decisions. Don’t hand it off – and if you possibly can, learn to code yourself. It’ll be worth it, and as long as you can think logically, it isn’t as hard as you think.

(One quick special note: if you instinctively recoil from the idea of learning how code works, or DNS, or servers, or any of the fundamentals to running a technology company, don’t get involved in tech startups. Those things are the building blocks of your product.)

If you are a geek, don’t make the mistake of thinking it’s all about the code.

This is the mirror image of the above mistake. Building the product is important, as I’ve just laid out. But a startup isn’t a webpage, a service or an app: it’s a company. The temptation, particularly as a single founder or a small team of developers, is to spend all your time working on awesome code that works well. But, equally importantly, you need to nail down the fundamental framework of the business you’re creating.

How do you work? How is your company incorporated? How will you sell your product and market yourself to your potential customers? How will you find those customers? How can you grow? You can’t code the answers to these questions, and if you’ve never started a company before, you’ll find that they’re far harder than building software (because these are new challenges). You’ll need to be empathic, unless you’re building software for a million people who are just like you. (Hint: there aren’t a million people who are just like you.)

As far as the product goes: get something working, fast, and then iterate on it, while you work on the tough stuff. You’re a coder, so you probably don’t read manuals, but get used to not knowing stuff and having to test it in the real world. That’s how companies work. There’s no such thing as sitting in a dark room and – ta da! – coming up with a world-beating company that’ll make you millions. Any story that says otherwise is a lie (because the company in question will have worked out that it’s a great way to sell people their product).

(The geeks get a special note, too: design is marketing. It’s how people perceive your product. If you’re a back-end coder, not only will you need to learn the spreadsheet side of your startup, but you’ll need to learn how to make a clean design, too. You can’t outsource this, but luckily, projects like Bootstrap and Glyphicons help. Get a real in-house designer as soon as you can.)

Your business is the product, and your product is the business.

You can’t do just one. Starting a technology company is an amazing experience – but if you’re a spreadsheet person, you’re going to have to get used to looking at the technicals. And if you’re a technical person, you’re going to have to get used to looking at the spreadsheets. That’s just how it works.

Learning in hallways (with APIs)

November 18, 2012 | 4 comments

I can’t let Clay Shirky’s piece, Napster, Udacity and the Academy, go un-commented-on:

Open systems are open. For people used to dealing with institutions that go out of their way to hide their flaws, this makes these systems look terrible at first. But anyone who has watched a piece of open source software improve, or remembers the Britannica people throwing tantrums about Wikipedia, has seen how blistering public criticism makes open systems better. And once you imagine educating a thousand people in a single class, it becomes clear that open courses, even in their nascent state, will be able to raise quality and improve certification faster than traditional institutions can lower cost or increase enrollment.

You can – and should – read the whole piece here.

I completely agree with it, and I think that startups like Udacity will broadly be a good thing for the world. (Of course, it’s worth mentioning that this is a movement that OpenCourseWare started a long time ago.) Having said this, there are a few important tenets about learning that I think aren’t necessarily captured by the Udacity model.

  • There are different kinds of learners.
  • Learning with your peers is important to some people – and learning alone is important to others.
  • A one-size-fits-all approach doesn’t work when it comes to education.

I went to public (state-funded) schools, and a public university. I can’t claim to have experienced the one-on-one education that you might receive at Harvard, for example. But it’s nonetheless true that education has traditionally been, at least a little bit, tailored; you could always go to your Director of Studies if you had a problem, or talk to your professor about substituting work or taking a different focus.

In the modern web age, by which I mean from about the iPhone onwards, we’re used to cookie-cuttering users. Everyone gets the same interface, in the same design, with the same content types, because that design is good, it’s efficient, and don’t you love good design anyway? We’re all supposed to write a certain way, consume a certain way, look a certain way.

Applying this principle to education will be disastrous.

There’s a lot wrong with education right now, particularly in countries like the United States and Britain, where class systems are enforced through high fees and barriers to entry. But in a knowledge economy, we should be emphasizing creativity and individual strengths, rather than attempting to make learners fit an ever more rigid, dehumanizing template. (We should be doing that with users of our applications too, of course.)

But as I said at the beginning, I don’t think this is a bad trend. It’s also an inevitable one. Educational content will be open, it will be delivered en masse, and you will be able to access it from anywhere in the world. It will be a great thing.

The trick is how you consume it.

You can use Udacity’s interface, if you like. But just as I have the freedom to take three classmates to the pub (I went to university in Britain, remember?) and talk over our notes there, I should have the freedom to take some of my classmates and discuss on Facebook, or a collaborative Google Drive space, or on some other custom platform.

And that’s where the technology focus becomes really interesting. Web applications have APIs: Application Programming Interfaces that let other applications talk to them programmatically. The same API approaches that allow people to build third-party Twitter apps or to sync Instagram with Facebook could allow people to take streams of learning from the learning service – let’s say Udacity – and pull them into the platforms of their choice. Other commercial applications, or freely-available open source projects, could take that learning and allow you to interact with it individually or in a group. And then you can use the app or method of your choice to submit your work back to be evaluated. And if everyone’s using the same APIs, then everyone benefits: learners get to pick and choose their courses, and the educational providers get to participate in an open marketplace that’s as big as the web.

In this model, the raw course is always the same. But suddenly there are a hundred thousand lenses that you can apply to it, so if you’re a visual learner, or a group learner, or a solitary text-based scholar, you can find the interaction method that appeals to you, pull in relevant third-party information and conversation to augment your learning, perhaps even talk to third-party tutors in other countries (or next door), and have a much deeper, richer, more personalized experience than you could ever have had before.

My worry with the new educational startups is that they’ll try and lock themselves down, in the way that Twitter and Facebook have locked themselves down. If, on the other hand, they can open up and embrace what the web really is, there’s the potential for a real revolution.

Why I wrote my own CMS so I could write a novel in a month

November 2, 2012 | 8 comments

Growing up, I always wanted to be a professional writer. It’s still something I aspire to, but I get just as many creative kicks out of building software – and the pleasure is even greater when, just occasionally, I get to combine the two.

I’ve tried to participate in NaNoWriMo, the National Novel Writing Month, before. Usually, I flake out. To have “won” NaNoWriMo means that you’ve written a complete novel of over 50,000 words over the course of the 30 days of November, and most of the time I stall at 3,000 or less. I’m ashamed to admit that part of my inability to complete any kind of long-form content is my dependence on the Internet: I’m so used to tweeting and getting feedback that the thought of getting to 50,000 words without anyone seeing it is daunting. (There’s a whole other piece to be written about this – I’ll get there another time.)

So, I decided that this year I’d try it again, but I’d publish publicly as I went. It’s an exercise in perseverance more than anything else, so I’ve tricked myself into thinking that this is okay. So here it is – but I’ve chosen to write it a homegrown CMS rather than using Word or WordPress. I wanted to prominently see the word count as I typed, to track my progress towards 50,000 words. And I didn’t want to deal with the increasingly-complicated WordPress interface (which I gladly use for this blog) or be tied to a single computer in the way I would be with Word. I also wanted to play around with some little bits of flair that would be hard with an existing piece of software.

So, I spent an hour or two the other night putting something together.

(My Writemo editor, above, vs WordPress’s editor, below.)

The CMS is a series of PHP scripts sitting on a single-table MySQL back-end. I’ve split the novel up into segments, which are effectively posts. That makes it easy for me to edit small chunks of the novel at once, rather than having to open the whole thing up each time. It also allows me to syndicate the novel in an RSS feed, and give people the choice to read it novel-style, with the segments in ascending order, or blog-style, with the newest segment at the top.

There are no images. I set the background to #eeeeee, the text color to #333333, and the font to Kameron from the Google Web Fonts collection. The editor is a simple textarea control, but in order to ensure I can use tabs, I use the following jQuery (which I found on StackOverflow, although I’ve now lost the source page):

$('#maintext').keypress(function (e) {
    if (e.keyCode == 9) {
        var myValue = "\t";
        var startPos = this.selectionStart;
        var endPos = this.selectionEnd;
        var scrollTop = this.scrollTop;
        this.value = this.value.substring(0, startPos) + myValue + this.value.substring(endPos,this.value.length);
        this.focus();
        this.selectionStart = startPos + myValue.length;
        this.selectionEnd = startPos + myValue.length;
        this.scrollTop = scrollTop;

        e.preventDefault();
    }
});

I also count the number of words in the textarea with each keypress, and display both the number of words in the current segment, but also the number of words across the whole project (top and bottom numbers respectively in the screenshot). For this, I used C. Bavota’s jQuery word count plugin as a starting point, and pared it down into something simple enough for my needs.

Because I didn’t want to mess with wysiwyg editing, I chose to use markdown notation in the editor. That way, I can italicize a passage by using _underscores on either side of it_, for example. It’s very intuitive, particularly if you’ve ever edited anything on Wikipedia or in Mediawiki. And Michel Fortin’s PHP Markdown project is extremely simple to use: you simply wrap your string with the Markdown($string) function in order to turn it into perfectly serviceable HTML. The only niggle is that I noticed it doesn’t handle single line-breaks very well, so I deliberately double-space my text before I convert it from markdown.

And that’s it; the editor itself is deliberately designed to be extremely simple, and (if I push Firefox to full-screen mode) feels like a low-rent iA Writer or other distraction-free writing utility. I can edit from anywhere, on anything that supports standard HTML, and my pages are extremely low-impact. And most importantly, I’m getting the words out.

Anyone else rolling their own software for this kind of thing? I’d love to compare notes.