swombat.com

daily articles for founders

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

How to stop startups from failing in 4 common ways  

Most articles listing ways startups fail are not very interesting. There are millions of ways startups can fail.

This article by Elad Gil is different, because it offers some concrete advice about what to do to prevent each of those issues: running out of money, team implosion, a living dead company, or a bad board/investors. Have a read.

How to choose a domain name  

A company or domain name seems so inconsequential in the greater scheme of things. After all, what will sell is the product, right? Google would still have stormed the world even if it was launched as searchforstuff.com, right?

Whenever starting a new business, venture, site, or other thing that needs a name, it always feels like finding the name takes a disproportionate amount of time compared to its impact. But from experience, I find that actually, the right name can be very important depending on the context.

Really, the importance of a name depends on your business. For something like GrantTree, having a clear, memorable and trustworthy business name is essential, since we often introduce ourselves over the phone, and our customers want to feel reassured that we are not some rip-off outfit. Would you get your tax credits handled by "Rapid Lobster Inc" (one of our quickly-discarded brainstorming options)? However cool that name may be in the right context, it would be disastrous in ours.

For something like Bushido, having a cool-sounding name is probably more important, and the clash with the existing concept of Bushido is not too much of a problem, given how Rails-related stuff has tended to dominate whatever word it's adopted.

On this topic, here's an excellent article by The Name Inspector about some common, older myths of selecting domain names, and how they have evolved over the last 10 years.

Some of the key points:

  • Short is good, but memorable and clear longer names are better than opaque shorter names.
  • Ideally the name should have some meaning associated with it that helps bolster your brand (I certainly agree).
  • You should be able to dominate the search engine results page for your name (i.e. avoid names with a very popular existing use).
  • Alphabetical order is not very relevant today.
  • There are no magic letters that make a domain name better.
  • All types and patterns of names can be good.

Chris Dixon also pipes in with some advice, focused more on naming startups rather than domains:

  • Your name should be easy to spell once heard in conversation.
  • Different products require different naming strategies.
  • Related Words on RhymeZone can be a great way to come up with a good domain.

All good stuff, to keep in mind when you're next looking for a domain.

I'll conclude with this quote from Umberto Eco's excellent book, "The Name of the Rose":

Stat rosa pristina nomine, nomina nuda tenemus.

Or, for those who don't speak Latin:

The name of the rose of yesteryear is but a name, but only names remain among us.

How not to recruit cofounders  

Like many other technical people with startup experience, Tristan Kromer gets approached by non-technical founders and is tired of people making basic mistakes in their pitch to him. Here's his list of don't's when approaching a technical cofounder:

  • Don't bullshit. If you don't know, say so.
  • Have more than an idea to offer.
  • Don't ask for an NDA.
  • Be clear. If you can't be clear even this early in the relationship, working with you will be a hassle.
  • Show that you can do it by yourself.
  • Know your metrics.
  • Don't make up words to describe your way of working.
  • Don't negotiate about share percentages.

The last point is interesting:

If you offer me 1% of the equity, I'll do 1% of the work. If you offer me 25% percent, I'll do 25%. If you offer me 60%, I'll insist on only taking 25% and I'll work 24/7 for you.

It's a bit tongue-in-cheek, but makes the point that if you're arguing about percentage points already this early in the startup, chances are the relationship will struggle. If you want to encourage loyalty, err towards generosity (but only with committed cofounders).

Get a VC to mentor you  

Larry Chiang shares some ideas about how to get a VC's attention, including:

  • Don't ask them for investment (that will turn them off)
  • Ask for a phone call, not for coffee
  • Follow up methodically at the right times, consistently over a period
  • Write articles naming the VC directly to set off their Google Alerts
  • Process all their advice to show you're listening
  • Keep showing that you're paying attention to their advice
  • Ask for their phone number
  • Publish thought-leadership articles that the VC will want to repeat to their contacts

Good method on the whole, but be careful about being too aggressive. No one, not even VCs, wants to have a personal spammer.

Running a startup without hiring  

Gabriel Weinberg, respected entrepreneur and angel investor, proposes that until you have significant and growing revenues, you should refrain from hiring any permanent workers and, instead, use freelancers or do it yourself. This is in contrast to the typical funded startup approach, and is very good advice for those attempting to bootstrap their business.

[...] hiring takes money. It increases your burn rate significantly. Companies before product/market fit, i.e. traction, need to stay around long enough until they get it. That can take a lot of time, like years. There are countless cases where companies folded only to miss their moment and see other companies rise up where they might have done so.

This approach will probably not work for everyone, but if you are an experienced and multi-talented founder, I agree that it can be a better approach - allowing you to keep your burn rate low and to spend money on things other than staff costs.

Side projects  

Andrew Dumont makes an interesting point:

Know that when you start just a side project, you're starting so much more. It'll completely consume you. The worst failure in any side project is to devote time, energy and sanity for any sustained period only to close the doors.

Side projects are a means to an end.

They need to start with an end-state in mind - create a passive income stream, validate my idea. They need to have deadlines and key metrics - six months to profitability, 10 paying users to validate my idea. But most importantly, they need to be a sprint. The longer a project lingers, the harder it becomes to keep morale high and pull the plug if it's not working out.

There is, of course, a valid point there. Then again, I am reminded of those people who assault young musicians with questions like "But why do you want to play the violin? What are you trying to achieve?"

Isn't playing violin and starting side-projects just for the fun of it enough for a start?

I am pretty sure that most people who eventually started side projects with clear end-states in mind first started side-projects just for the heck of it. They probably did that for years before the thought that a side-project could have an end-state right from the beginning entered their mind. That certainly was the case for me: most of my early programming, writing or web activities were done purely for the heck of it.

So, perhaps better advice is to be aware that some day you will want to graduate to definite goals.

But if you want to start a side-project today for the heck of it? Go for it.

Dropping out for a startup  

Joel Gascoigne's cofounder, Leo Widrich, dropped out of university to start successful startup Buffer. Here are Joel's insights (some gleaned from Leo) about the interaction between university and startups.

My belief and experience with going through Leo dropping out is that when it is good to drop out for your startup, you will know it. That said, I think one of the biggest misconceptions is that you have to abruptly cut everything off and burn all your bridges with university.

How I've seen it play out more often than not, is that someone does many different side-projects during college and then when something begins to work, they go through a massive amount of learning and progress in an incredibly short space of time. This is very much related to Paul Graham's notion of compressing your life:

But don't be too keen to do it:

[M]y advice to anyone thinking of dropping out is to keep studying, and use every opportunity to build projects and startups on the side. When something starts to work, you'll have that same feeling that many others have, and you'll know that it's your duty to keep building it and bring it to the world. Until that happens, keep studying and keep building. When it happens, drop out slowly.

Fit your product to the right market

On my first startup, I made the mistake of not talking to customers at all until launch day. As a result, the product sucked - it was not fit for any market. And because it was unfocused, it was impossible to define any sort of effective marketing strategy, either. This is the kind of expensive mistake you don't make twice, and I extracted it as a one of my "N tips" posts later (see tip number 4).

So imagine how surprised I was when I managed to make a variation on this mistake again with the next startup - albeit in a different flavour. We launched within 2 months, had active users from the right industry right away, saw the product spread... and yet when it came to charging people, the process of getting those happy users to pay was harder than pulling teeth from a cat! Moreover, when trying to sell to other potential customers, who had been unwilling to use the product for free but seemed more inclined to pay for it, there was always a feeling that the product was exciting and had potential, but it didn't quite do what they needed in order to justify paying for it.

In startup lingo, that's known as a product/market fit issue.

Fit the right market

It turns out that getting a prototype out there is not enough. You have to get the prototype into the hands of the right market. If you're planning to sell a paid SaaS product, this means finding early users, from day one if possible, who will pay. Otherwise, you're getting product-market fit - with the wrong market.

In that context, it was good to see, recently, the following story about SyncPad, who did launch to paying customers right away - which enabled them to discover that their paying market was not who they thought initially:

After Davide launched his app he hit the streets and began talking with his actual customers. What he discovered surprised him. Instead of taking the art world by storm, Davide discovered that his true customers for SyncPad were in the business market. He found that companies were using SyncPad to help manage meetings (both remote and locally), real time visual communication, and for presentations.

SyncPad made some wrong assumptions about who their customers would be, but by charging early, they found those assumptions out very quickly, and were able to pivot their product into the right market.

The price selector

Price is a very strong selector when it comes to users. The people who pay are often not the same as the people who want a free product. This is especially obvious in the B2B market, where "how much the customer wants to pay" allows you to select between enterprises, small businesses, freelancers, etc.

If you build a product with the feedback from free users, you'll build a product that's great for free users. If you want to build a product which users will pay for, you need to be charging them as early as possible so your product feedback comes from paying users.

Charging early

One approach for charging early is to ask users to pay from day one, even while your product is in early beta. Even though they're helping you out a lot by being some of your first users, you need to validate that they are the right kind of user, and the only reliable way to do that is to ask them to pay you.

Of course, you can't charge them the full price. They'll laugh you out the door and you'll lose a potentially very valuable relationship. So, what do you do?

You give them a steep discount. "We're still early in the development, so you will get a 90% discount for the first three months, and we'll review the price upwards as more features are developed." This can also lead very nicely into a discussion of what feature they would most like to see in order to accept the price increase in three months. This can turn into your product road map, if you manage it well.

Of course, perhaps no one will want your product even at a 90% discount - but if that's the case, you should revise your assumption that they'll be willing to pay for it at full price, ever, and perhaps pivot into a different product, one that people are actually willing to pay for.


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.

Questions asked at YC interviews  

Kevin Gao shares what he believes are key questions asked by the YCombinator team during interviews, with do's and don'ts:

  1. How did you come up with the idea?
  2. How big do you think your market is?
  3. What have you already accomplished?
  4. What is the equity split among your team?
  5. Are you going to work on your startup even if we don't fund you?

Even more interesting than this post (which unfortunately lacks any mention of whether Kevin has been through any YC interviews or has spoken with many alumni) are the comments by Paul Graham himself on the HN thread:

These are all things we care about, but they are probably not the most common questions we ask. E.g. we already know about the equity split because we ask about it on the application form, so we only bring it up during the interview if we noticed something odd about it.

The thing we care most about in interviews (at least of things one can change) is how engaged the founders are with users. How do they know people actually want what they're building? Have they talked to real, live users? What have they learned from them?

We don't care super much how big the initial market is, so long as the startup is making something that (a) some subset of people want a lot, and (b) if that market is not itself huge, there is an easy path into bigger neighboring ones. Basically, we're looking for startups building Altair Basic.

The whole thread is worth reading if you're interviewing at YC, or, in fact, any other incubator (and probably most savvy angels will ask similar questions).

Even if you have no intention to raise funding, some of these points (e.g. how you're building engagement with users) are worth thinking about for yourself.

more