swombat.com

daily articles for founders

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

Do you really need investment?  

Jean Derely on WooRank's early days:

We couldn’t get anyone to invest in WooRank when we got started, and despite this seeming like the hardest path at the beginning, it might well be the best thing that could have happened to us.

(...)

The first benefit is that there weren’t external pressures on us (from investors) to achieve specific levels of profits, or to develop WooRank in a way that was not necessarily in our customers’ or our own long-term best interests.

(...)

Another consequence of not having early investment is that we’ve had the flexibility to cultivate the company culture as we ideally envisioned it. This includes giving team members additional incentives and a great work environment – and despite long working hours at the beginning, to give the team the necessary professional freedom to maintain a healthy work/life balance. Who knows if this would have been possible with the pressure of measuring up to our investors’ wishes weighing us down?

Control over your company's destiny is definitely a huge benefit of bootstrapping. Another benefit that shouldn't be discounted is the financial side: all the profit is yours to keep, and to take out of the company right now if you so wish, without having to wait for a payout day sometimes in the future.

Horizontal vs vertical products  

Joel Spolsky:

Vertical software is much easier to pull off and make money with, and it’s a good choice for your first startup. Here are two key reasons:

  • It’s easier to find customers. If you make dentist software, you know which conventions to go to and which magazines to advertise in. All you have to do is find dentists.
  • The margins are better. Your users are professionals at work and it makes sense for them to give you money if you can solve their problems.

Making a major horizontal product that’s useful in any walk of life is almost impossible to pull off. You can’t charge very much, because you’re competing with other horizontal products that can amortize their development costs across a huge number of users. It’s high risk, high reward: not suitable for a young bootstrapped startup, but not a bad idea for a second or third product from a mature and stable company like Fog Creek.

Spot on. And with the ever decreasing costs of starting up, tiny vertical niches that were previously not worth anyone's time are becoming worthwhile targets for first-time entrepreneurs.

If you haven't checked out Trello, which is the product Joel is referring to, be sure to do so. It's probably the best generic people/process-management tool I've found online yet. I'm not kidding.

While we're on the subject of Trello and Spolsky, they both make a great example of an experienced entrepreneur (Joel has an array of profitable products under Fog Creek Software, and also cofounded the hugely successful StackOverflow) using a cash pile to protect a project from short term profit considerations.

Whether that leads to a profitable exit for Trello is another matter, of course.

Government grants  

Renowned VC Fred Wilson dismisses government grants:

The application process is usually long, involved, and distracting. And sometimes the grants come with strings attached; you can't move, you have to use it for a specific purpose, you have to hire a certain number of people with it, etc, etc.

(...)

I'm not a fan of this form of financing. First, in principle I think that government ought to stay out of the business of picking winners and let the market do that. But more practically, I've never seen an entrepreneur change the outcome of their startup with government money. It is never enough to really move the needle and the strings that are attached usually make it uninteresting to me.

Given that, these days, I spend most of my time getting tech companies government money, I can't quite agree with Fred here. Perhaps things are different in the US (in fact, they almost certainly are), but here's the situation in the UK:

Tax Credits

The first mechanism that the UK government has to help tech companies is a tax break. It can be quite complicated to apply for, and so many companies that should be getting that tax break don't apply for it. If you're spending at least £50k a year on developing your own software products, you can get a chunk of that reimbursed by the government.

It's easy to dismiss the amount (you might get about £10k back on a £50k expense, for example), as Fred does, but actually, several companies in our portfolio would argue differently. One of them was in the middle of raising funding when the tax credit (over £40k in their case) came in, and it gave them that extra couple of months of runway that allowed them to negotiate themselves a good funding deal.

In their own words, they were "on the floor, laughing" when they saw the money come into their account at that critical time. So much for not moving the needle.

How much work did it take them to get this money? None at all. We handled all the filing for them. It cost them money, but that money was a "success fee" - in other words, it was money they wouldn't have had anyway if it wasn't for our help.

But enough about these unsexy tax matters. What about grants? Are they really that hard to file for?

UK Government Grants

Currently, GrantTree specialises in one of those grants, the Grants for R&D, which comes in the form of match funding with very few strings attached.

Are they hard to file? Yes, absolutely. The application form adds up to about 10 pages of very dense writing. It takes a lot of effort, great writing, persuasion, and technical skills, and of course experience in going through the process, to do this well, and it really does need your full attention for at least a few days to just get it done.

I certainly agree that in most cases, it's absolutely not worth it for tech founders, who already have their hands full with building their business, to dedicate a week or two of their mind-space to learning about the grant and preparing the application.

But here again, they can get help. And here again, the work is done mostly on a success fee, so that the cost is basically coming out of money which they wouldn't have had without the grant anyway. So it works out, once again, as free money.

Moving the needle

Can these things move the needle for entrepreneurs? Absolutely.

One entrepreneur I spoke to over a startup-themed dinner a few months ago claimed to have raised over £2m of government grants for his business, over the space of a few years. The Grants for R&D mentioned earlier can effectively extend your runway by 45% to 60% depending on the grant you apply for. Some UK-based companies can and do claim hundreds of thousands of pounds of tax credits every year. Even for a decently sized, mature company, that makes a difference. Money can clearly "move the needle". If it didn't, then why would people give up precious equity in exchange for it?

The same entrepreneur who had raised £2m of government funding made a great point that night. He said that the US, and in particular Silicon Valley, had a huge advantage in the density of VCs and hyperactive investment culture. In the UK, where VCs are scarcer and more risk-averse, the advantage that we have is that the government is willing to directly support small, innovative technology businesses.

If you want to learn more...

I don't want to turn this article into a pitch for my company's services, but if you're a UK company and you want to learn more, do get in touch. There's no guarantee that we can get you money (many startups are just too small and scrappy and don't qualify for either grants or tax credits), but we're always happy to discuss your options.

Make money from your web apps by starting with the market  

Here's another interesting article by Paras Chopra, proposing that building a cool application and then trying to make some money from it is not the best approach to making money. Instead:

If making money is the objective, I suggest going with the market-first approach (as opposed to idea-first approach).

Paras then provides some steps for this market-first approach:

  1. Pick and industry where people are making money
  2. Find a differentiator which will allow you to wedge in
  3. Make a web app, market, refine, monetise
  4. Slowly build up to being a market leader

As I proposed in this earlier article about how to evaluate startup ideas, if you're honest about your areas of uncertainty, as a builder/developer, market uncertainty will be at the top of your "hypotheses to resolve".

Another point, though: even better than starting with a market is starting with the set of markets which you have some access to. If you have some delivery channels already, building a startup around those is the path of least resistance.

Dropping out is probably not for you  

I've covered this topic before. Here's Jacques Mattheij's take on it is that you should only drop out if you are running towards something (basically, your own startup that's taking off like a rocket ship and making a lot of money already), rather than away from something (you're bored, don't like it, etc):

So, if dropping out is an escape of sorts, don't do it. Stick to it, finish what you start. If your school or university is holding you back from achieving your full potential then drop out with confidence.

The simplest test of whether or not you should drop out is this one: If you have to ask someone if you should then you shouldn't.

I'll add one more reason not to drop out:

You shouldn't drop out just because "other people have dropped out and did great". The chances that you're the next Steve Jobs or Bill Gates are, well, 1 in 3 billion.

There are plenty of reasons that are directly related to you and are not good reasons to drop out (and some are outlined by Jacques). Definitely do not drop out based on the idea that since it worked for someone else, it will work for you. Most people will lose a lot by dropping out. I know a fair few very smart people who dropped out of university or simply didn't consider going, and all of them, without exception, regret it.

Shutting down blaster.fm  

Continuing the topic of moving on from failed startups, Josh Sharp writes about his blaster.fm project and why he's shutting it down:

Choosing to let it go wasn’t easy. “Why can’t you just let it sit there and keep running?” I have been asked several times. But even though it doesn’t require active maintenance, it still exerts a mental toll. It weighs on me, the site-that-could’ve-been. The site that missed its opportunity to get big.

Yep. Moving on is good.

There's also a comment to be made about Josh's approach to building blaster.fm. Reading his article, I noticed a lot of "I built this" and "I built that", but not a whole lot of "I went and talked to people" or "I saw this opportunity to make some money". Perhaps that did happen and is just missing from the write-up.

However, on the assumption that it's not just a writing omission, this approach of building things and waiting for people to find them is perfectly fine for a side project, a hobby that may randomly pick up and become interesting, but ultimately it means that the project was fundamentally a lottery ticket. In this case, a lottery ticket that didn't win (the prize was acquisition by last.fm, it seems). One hopes that most of the enjoyment was derived in the building of the site and the learning that came with that.

In the long run, it's hard to get motivated about a project that sucks a lot of time and gives very little back. I believe in working on side-projects, but in my opinion, if you're going to do that, then you should probably err towards side projects that have at least some vague commercial potential beyond "a big company will want to buy it". I'm sure Josh would feel differently about blaster.fm if it was making even just a meagre $2k a month.

To raise or not to raise  

Joe Stump, founder of SimpleGeo, has written a pretty solid article examining whether people should raise capital or not. It's a balanced view that looks at both angles instead of dismissing or praising fund-raising outright, and mostly matches with my views on raising investment:

I look at capital, whether it comes from an angel, a VC, or a traditional bank loan, as an accelerant. It’s like gas. Sometimes your fire is burning nice and bright. You’re warm and have plenty of heat so why pour more gas on the fire? Sometimes, however, you’d like to start another fire, or maybe you’d like to burn down a house, or, possibly, you’d like your little glowing embers to be a fire more quickly than is otherwise naturally possible. These are all great reasons to reach for the can of gas.

Joe lists a number of good reasons to raise or not to raise. Reasons to raise:

  • Your business is capital-intensive.
  • You're at an inflection point and the capital will help you grow 10x faster.
  • You want to get some money out. (I find this one dubious - just pay yourself a better salary!)
  • You can't afford to keep working on your startup. (I disagree with this one, that's using investment as a cushion)
  • It'll give you access to a lucrative partnership.

Reasons not to raise:

  • It's hugely distracting.
  • If you raise too much, you might get hurt in later rounds.
  • If you raise at too high a valuation, you'll be taking early exit options off the table.
  • You give up control of your company.
  • Even after raising, investors are a huge distraction.
  • You may not get the attention you want or need from your investors.

Finally, Joe offers some tips about do's and don'ts of fund-raising, but you should really just go read the article to find them out.

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).

Questorming: exploring the unknown unknowns

Nominally, questorming is brainstorming with questions. In other words, it's a group technique designed to help a group of people to come up with creative solutions to a topic.

However, I've found it much, much more useful than that. One of the great uses for questorming is in Hypothesis Driven Development, where you explore a startup via questions, but there are many other uses for it. You can use it in any situation where you're trying to explore an unknown topic, by which I mean a topic where you think you know a thing or two, but you don't know what the boundaries of your knowledge are - i.e. a topic rife with unknown unknowns.

If Lean Startup is a method for developing a startup in conditions of extreme uncertainty, questorming is a method for exploring a topic in conditions of extreme uncertainty. It gives you a solid starting point which you can leverage into a fuller understanding of a topic that was previously a black box. It's like bootstrapping for your mind.

I've used questorming for everything from exploring statup ideas to drafting a book's table of content (the book didn't get written, but the TOC was solid!). Questorming is very easy to apply once you know about the technique, so I hope this will be useful to others too.

How to apply questorming

As the saying goes, asking the right questions is half the battle. This is what questorming focuses on: questions. The objective of the game is to ask as many questions as possible, in a free-flowing, unscripted way, about the topic. Much like with brainstorming, there are no bad questions in the initial phase - anything goes. As the storm of questions grows, it provides a map of your current understanding of the topic, and some clear next steps for deepening that understanding.

Here's an example. I might want to know more about how to write a book. For such a common topic, I could probably just find some texts on the topic which would teach me the basics, but many other topics (for example, any startup idea) don't have volumes written about them, so for those there is often no source other than your own current understanding.

We start with a simple question:

  • How can I write a book?

And free-flow from there:

  • How can I not write a book?
  • Are there activities that will increase the chances of me writing a book?
  • Are there things that I absolutely must do to write a book?
  • Are there things that, if I do them, will guarantee I don't write a book?
  • What are all those things?
  • Do I need anyone else's help to write a book?
  • Is it possible to write a book without any help from anyone?
  • What are all the key things that need to happen before a book is ready?
  • What does it mean for a book to be ready?
  • Is a book ready when I decide it's ready, or are there other factors?
  • What are clear signs that a book is not ready?
  • Are there some books that can never be ready?
  • Can I do something to make sure that my book will some day be ready?
  • What could I do to ensure that my book will never be ready?
  • Is a book's readiness entirely driven by its content, or is there an external readiness too?
  • What does the external readiness consist of?
  • Is it ready externally when enough people know about it?
  • Are there different stages of internal/external readiness?
  • Does the external readiness help validate the internal readiness?
  • Are they related?
  • Can they be used to push each other forward?
  • Why do I want the book to be ready?
  • What do I want out of it?
  • How does that relate to whether it's ready?
  • Who am I writing this book for?
  • Do they have any impact on whether it's ready?
  • Can I find out if it's ready from the perspective of its audience, before actually publishing it?
  • Do I even need to publish a book?
  • Are there ways to publish a book so that it can be improved iteratively?
  • Are those ways better or worse than traditional ways? Why?
  • Are there benefits to publishing a book in the traditional way, vs a more modern approach?
  • Which is better to match what I want out of this book?

Obviously I could go on... this is an exercise that ends when you decide it's over. For the purpose of illustrating questorming, I think this does the trick. Not all the questions are useful, of course, but on the whole, they provide a good starting point.

Within a few minutes of simply asking questions, I've identified several key actions to take the activity of writing a book to the next level:

  • Finding out what sorts of things people do to get their books finished
  • Thinking about what I actually would want out of a book
  • Figuring out who I know that can advise or help with this
  • Thinking through what I actually mean by a book being ready, and finding out what the industry means by this, and comparing the two
  • In particular, exploring the interplay between a book's content and its market (perhaps in a startup-like fashion, where content is validated in some way before being developed)
  • Defining my audience for this book
  • Exploring traditional vs electronic publishing, and deciding which one suits me better

Of course, these concerns and starting point are deeply related to my own concerns and my knowledge of book writing - and that's exactly as it should be. They provide a map of what I know about the topic, and some next steps about how to expand that knowledge.

In my experience, no subject is safe from questorming. You can always use questorming to expand your knowledge of a topic, no matter how little or how much you know about it. That, in my opinion, makes it an incredibly valuable tool when operating in situations where there is often no authoritative source to tell you what to learn or think about next.


Startup Therapy: Ten questions  

Not a new article, but one that bears reposting as we approach the new year, a traditional time of reflection.

See if you can find the time, over the next couple of weeks, to answer the following questions about your business:

  1. In one sentence, what does your product do and who buys it?
  2. In one sentence, why does someone buy your product?
  3. What one thing is most responsible for preventing sales?
  4. What one thing could you do to get more feedback from customers, potential customers, or sales you've lost?
  5. If you had zero revenue from now on, on what date would you run out of money?
  6. If someone handed you $100,000 today, how would you spend it to maximize future profits?
  7. If you were forced to hire someone today, how would you define her job such that she would contribute enough revenue to cover her expenses?
  8. Which of your business operations do you hate?
  9. What initiatives could be done half-assed without significant impact?
  10. If you could get one solid hour of advice from a guru you respect, what would you discuss and what would be the goal of the meeting?
more
Google Analytics Alternative