swombat.com

daily articles for founders

Here are 10 quality posts from the Founder's Library:

How to start a startup  

As I mentioned earlier, I will be posting older articles for the Founder's Library.

This classic from Paul Graham is a must-read for startup founders, and very much deserves to be the first to receive the "Library treatment".

You need three things to create a successful startup: to start with good people, to make something customers actually want, and to spend as little money as possible. Most startups that fail do it because they fail at one of these. A startup that does all three will probably succeed.

Bearing in mind that Paul wrote this around the time when he started YCombinator, and so didn't have the vast amounts of experience watching over 200 startups grow, this is nevertheless an excellent pattern.

Starting with good people means to start with the right kind of obsessive, determined, smart people:

It means someone who takes their work a little too seriously; someone who does what they do so well that they pass right through professional and cross over into obsessive.

Building what customers want means getting something out and quickly iterating it based on customer feedback:

In a startup, your initial plans are almost certain to be wrong in some way, and your first priority should be to figure out where. The only way to do that is to try implementing them.

This, however, should come with the caveat that not all product problems are revealed by coding - nor is the quickest way to check off hypotheses always to build something. See this article, or most of the Lean Startup methodology.

Paul's final point is about spending as little as possible - both in terms of hiring, and in terms of other miscellaneous expenses like Aeron chairs. This fits in with the Lean Startup methodology which is popular today, although one update from Lean is that, once you reach profitable product/market fit, i.e. once you have built a process that takes in $1 at one end and turns it into $2 at the other end, then you should invest money into scaling that process to saturation.

Product scope: where to draw the line  

Des Traynor:

The most important thing a product manager does is decide where their product stops and someone else’s product takes over. If the product doesn’t do enough, it won’t be worth the cost of installation, registration, maintenance, let alone purchase. If it does do too much, it’ll clash with some pre-existing software or workflow that is already well defined.

Des provides some great guidelines for where to stop.

You should usually stop your product when the next step…

  • has well defined market leaders looking after it (e.g. PayPal, IMDB, Expedia), and you don’t intend to compete.
  • is done in lots of different ways by lots of different types of users (e.g. trying to process salaries in a time tracking app would be tricky)
  • involves different end-users than the previous steps (e.g. managers, accountants etc.)
  • is an area you can’t deliver any value.

Can you think of examples which overstepped this boundary and failed because of it? What about the opposite? Products which broke the rules and yet took the market?

Are startups 10x cheaper than ten years ago?

This article was posted last week, and spurred an interesting discussion on Hacker News. At key is the question of whether startups are really cheaper than they used to be.

This is, of course, relevant because the idea that startups are cheaper than ever to launch is often brandied about to support this or that argument, whether it's about the increased number of tech startups, or the investment climate, or the reasoning about why you should start a startup right away, or the disruption to the VC industry, and so on.

Thesis and antithesis

One side of the debate claims that actually, startups are no cheaper than they used to be. In the late 1990s, it was possible to launch a startup on the cheap, on a shared hosting package, for puny amounts of money, and wait until it picked up before investing in more expensive infrastructure (just like it is today).

Hiring has not gotten cheaper, and infrastructure costs on the low end are just as low as they used to be, and so, the argument goes, it isn't cheaper to start up today than it was ten years ago.

The other side of the debate points out that many startups in the late 90s spent a lot of money buying overpriced Oracle licences, hiring rare and expensive specialists to deal with all this pricy technology, and that this was part of the cost of doing business. Today, MySQL (free) has replaced Oracle, and there are a lot of free hosting packages, and there are hyper-productive technologies like Ruby on Rails which allow you to build an entire web business with a handful of people and dollars.

Hiring costs may not be cheaper, this side claims, but technologies are more productive and deliver better results.

To this, the first side replies that you didn't need to buy Oracle in the 90s any more than you do now, and that this was just an inflated cost caused by too much VC investment in unsound startups. And, ten years ago, a tiny team of hotshot programmer could build a business out of nothing just as well as they can today.

And so the endless Saṃsāra of arguments goes on. If you have a few hours to kill, you may wish to join in!

The reality

As with every unsolvable debate, the truth lies... on both sides.

It was indeed just as possible to start a startup on the cheap ten years ago as it is today. Many people did then, and many people do today. If you're scrappy, smart and determined, you can start a tech startup for pennies. That's as true now as it was then.

But not all startups are started at the very cheapest end. Some businesses do require investment of some sort before they're viable businesses, or even require it as growth money. And this amount of money has been going down, at least as far as the technical expenses is concerned, because both the technologies (Rails as well as others), the infrastructure (AWS, Heroku, but also the vast number of supporting apps that make it easier to do things like accounting, support, or user testing more efficiently), and even the available knowledge and mentoring (via movements like the Lean Startup, or even communities like Hacker News), have been getting better.

AWS may not be the cheapest, but as a "standard option" for the scale-minded startup, it's a damn sight cheaper than spending thousands of dollars a month for a bunch of dedicated Rackspace servers, or buying up colocation space, physical servers and sys-admin time for a similar amount, as you might have in 2001.

It is possible to get further with less money than it was ten years ago.

And that's the crux of the matter. As with Parkinson's Law and time budgets, startups will expand to take up the funding available. But they will get much further with the same amount of money than they typically did ten years ago. Of course it was possible to start up on the cheap ten years ago. But:

  • today's cheap startup will get further than yesterday's cheap startup;
  • today's mid-range startup will get further than yesterday's mid-range startup;
  • today's expensive startup will get further than yesterday's expensive startup.

Startup opportunities

Perhaps more importantly, there's another factor at play: the opportunity-space.

Thanks to the blossoming of internet users, countless web technologies, open APIs, and other web companies, there are more opportunities to build startups today than there were ten years ago.

This seems counter-intuitive at first - surely, back then there were so many more things left to do. If you think about it, however, you will see that many opportunities depend on other things being in place. You couldn't have started Twitter or Groupon in 2001. Not enough people would have understood either of these platforms. You couldn't have started any of the companies, like Instagram, Foursquare, or Bump, that thrive on the iOS ecosystem - it didn't exist. You couldn't have started DropBox, Heroku or Mint back in 2001 - the infrastructure wasn't there to support them.

The fact that there are so many opportunities to build something useful and monetisable is, in my opinion, a bigger factor in the rise of web startups than how cheaply a scrappy founder can launch a product.

And as far as this particular trend is concerned, I'm pretty certain we are still at the beginning of the tsunami. Cheap or not, expect many more startups in the next ten years than in the last.

Update: Someone pointed out that I didn't answer the question in the title, which is clearly very bad form and I apologise for this faux-pas. The proper answer to that question is: you can't compare startups directly. What you can do with a certain amount of money depends directly on when you start doing it, and what you're trying to do.

What you can reasonably say is that the scope of what you could do 10 years ago with $X is about the same as what you can do today with $X/N, where N is larger than 1 (but perhaps not as big as 10), because of the improved opportunities, technologies, and supporting infrastructure.


You can't apply startup methods blindly  

Reiterating my earlier point about how startup methodologies are no substitute for skills, here's a great article by Steve Blank attacking a dumb application of his own Customer Development approach:

But he was missing the bigger picture. The idea of the tests he ran wasn’t just to get data – it was to get insight. All of those activities – talking to customers, A/B testing, etc. needed to fit into his business model – how his company will find a repeatable and scalable business model and ultimately make money. And this is the step he had missed.

Methodologies like Lean or CustDev are no substitute for experience. They can complement experience to make it that much more effective, but ultimately without the underlying experience, they are as useless as a master chef's recipes might be to someone who's never even cooked an egg.

How designers and developers can work together  

Matt Gemmell has written two excellent articles recently, aiming to help developers and designers to work together:

Both are solid and worth reading. The key points for developers:

  • Know what you want
  • Examples are helpful
  • Trust your designer
  • A sketch goes a long way
  • Consider sample data
  • Present all the work up-front
  • Remember design constraints
  • Be responsive
  • Don't assume it's easy
  • Don't micro-manage
  • Use the same tools
  • Speak the same language
  • Allow use as a portfolio piece
  • Pay on time
  • Don't condone spec work
  • Understand the model
  • Source code is extra

And the key points for designers:

  • Use an intelligent method of version control
  • Keep your layers
  • Name all your layers meaningfully
  • Use groups, and do so sensibly
  • Prune unneeded layers
  • Use Layer Comps
  • Keep everything as vectors, and scaleable effects
  • Learn how to preserve rounded corners while resizing
  • Design at 72 ppi
  • Snap to whole pixels
  • Always use RGB mode
  • Asset-preparation is part of your job
  • Be careful with fonts
  • Mimic the platform's text-rendering (where possible)
  • Be sure of design dimensions
  • Use the platform's idioms
  • Design once for landscape, then design again for portrait
  • Design for each major screen-size, and their contexts
  • Use genuine or at least realistic content
  • Consider localisation
  • Respect the global light source
  • Make navigational or organisational constructs explicit
  • Export cut-ups without compression
  • Ask about shadows
  • Understand how buttons are constructed

Read, bookmark, and remember.

Hair of the dog  

Lucas Rayala:

And I’m closing down my startup.

I need to go for a run. I need to clean up my desktop and emails. I need to hire a tax attorney to straighten the jumble of receipts and ticket sales, so the government understands that Altsie was definitely a net loss.

I need to send my last checks to my last distributors and thank them for their trust. I need to throw a party and tell my friends I appreciate their support. I need to find my friends again and thank them for sticking by me. I need to call my filmmakers and thank them for taking a chance with me. I need to take my wife to dinner and thank her for her love.

This is what you do when you close down your business on a Thursday night.

Speaking from personal experience, the end of a startup is tough. It's not just the mechanical act of winding a company down. Throwing away your dreams is painful. For some, if they really invested everything into that one venture, and have nothing left to take the next swing, then it can be the end of the road.

However, I really do believe that entrepreneurship is a career, not a one-shot thing. If you play your cards right and don't throw everything at your first idea (especially since it's very likely not to work out), you can just keep taking swings at it until you get it.

And, with businesses as with many other things in life, there's no better cure for a heart-broken ending than a fresh beginning.

Running a business vs building a product  

Elad Gil writes:

As the CEO, you need to keep your eye on the underlying product and business fundamentals of what you are doing. If you can not keep focused on the business side you must hire someone who will. Otherwise there is a reasonable chance your company will die. The two most common ways for a startup to die are founder conflicts and running out of cash. Running out of cash is often avoidable.

This is why I often advise people who want to play the startup lottery but have no business experience to try building a profitable bootstrapped business first. You learn a lot from running such a business that is just as essential when running a funded business.

Failing in an interesting way is hard. If you fail at the basics of running a business, you've not failed in an interesting way. If you fail because of some predictable startup issue like a founder conflict or building something nobody wants, you've not failed in an interesting way.

Failing in an interesting way means avoiding all those obvious traps and failing for some reason that is actually challenging and unforeseeable - for example, a smarter, more aggressive competitor stole your lunch, or if a political event simply made your product unsellable - those are interesting ways to fail.

The fatal pinch  

Paul Graham explains how startups that are burning through their first round of funding often don't realise they're about to die, and need to either make more money or cut expenses:

There may be nothing founders are so prone to delude themselves about as how interested investors will be in giving them additional funding. It's hard to convince investors the first time too, but founders expect that. What bites them the second time is a confluence of three forces:

  1. The company is spending more now than it did the first time it raised money.

  2. Investors have much higher standards for companies that have already raised money.

  3. The company is now starting to read as a failure. The first time it raised money, it was neither a success nor a failure; it was too early to ask. Now it's possible to ask that question, and the default answer is failure, because that is at this point the default outcome.

What is most interesting to me, though, is this paragraph:

Whereas if you only have a handful of people, it may be better to focus on trying to make more money. It may seem facile to suggest a startup make more money, as if that could be done for the asking. Usually a startup is already trying as hard as it can to sell whatever it sells. What I'm suggesting here is not so much to try harder to make money but to try to make money in a different way. For example, if you have only one person selling while the rest are writing code, consider having everyone work on selling. What good will more code do you when you're out of business? If you have to write code to close a certain deal, go ahead; that follows from everyone working on selling. But only work on whatever will get you the most revenue the soonest.

The bit in bold applies to every startup, funded or not. Which brings me to the obvious conclusion, that won't be very surprising to regular readers of this blog... why not skip the funding and go straight towards having "everyone working on sales"?

The answer is, that's not possible for some businesses. But it is possible for most businesses, despite the apparent, loud popularity of the Valley model of "raise funds first, figure out how to make money later". And, from the above sentence, I deduce that it is also possible for most Valley startups.

So the next question is, which one is better? I guess they both have pros and cons. As I've argued before, investment is a springboard, not a cushion. If you're an experienced entrepreneur, who knows how to build a business, and you want to do it faster, raising investment makes a lot of sense even if you could bootstrap the business. If you're a new entrepreneur, though, I still recommend going without, and learning the basics of how to build and run businesses before hitting the "boost" button.

What's clear is that even amongst the Valley model startups, those companies that can afford to neglect sales and other "proper" business topics are few and far between.

Product Launch Checklist  

A very decent list of "things to do" to help a launch go better. However, It's worth pointing out that none of those things (save, perhaps, the SSL certificate) should stop you from launching your product, at least in the sense of allowing people to sign up, use the service, and pay you money.

Comic books and web pages  

This great article by comic artist Rachel Nabors drawing parallels between the construction of a comic book page and the design of web page. Killer quote:

Both mediums tell stories and convey ideas using words and pictures. People will scan boring or confusing sites as well as comics. In both mediums, you have to either pull readers into a narrative or immediately offer up the meatiest part of the content, lest readers skip to the next page.

Emphasis mine. I'd never thought of it like that, but it makes sense as a general concept of how to think about a page you're designing. Are you offering "the meat" up front, or are you drawing the reader into a narrative?

The article is worth reading if only for all the neat illustrations.

more
Google Analytics Alternative