daily articles for founders

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

Dealing with a bad techcrunch review  

Update: Thanks to David Verhasselt for letting me know the link is dead. Luckily, I found a mirror here.

Josh Liu, London-based founder of MinuteBox, reacts to a bad TechCrunch review of his startup, and draws some key lessons:

  1. Great execution is key to getting your product understood;
  2. It is your responsibility to explain your product well, not the journalists';
  3. Not everyone will like your idea, and that's ok;
  4. Connect to the tech community to find the right team and/or cofounders.

This point is a familiar story:

When I was starting to work on MinuteBox, I knew no one in the tech community. I did not like social networking events. I was full of myself. I thought I had learnt a lot of things in business school. I just needed a developer and a designer to launch my business. Eventually, I found a developer and a designer through my friends. They are extremely nice people and were very helpful to me. However, they were not the right talent to execute the idea.

Non-violent communication  

First Round Capital's written a thought-provoking guide to internal startup communication:

When startups experience conflict — particularly between leaders — efforts quickly become uncoordinated, motivations get misunderstood, and results fall short of expectations. You simply can’t produce an incredible product if the team building it won’t agree on fundamentals.

Avoiding problems only allows them to fester and impact more people, while hasty, non-strategic communication can turn a small fire into a blaze.

It centralises around a commmon mistake:

Watch out, because the jump from observation to judgment happens almost immediately,

Which is often surfaced in unhelpful questions:

A. Will you get your work done this week?

rather than

B. What do you need to hit your deadline this week?

Open-ended questions ... acknowledge the level of effort you’re already putting in and offers to help. It asks for more than a one-word reply — it seeks valuable input.

While a lot of startups aim for modern team structures, they're still riddled with old-fashioned communication norms. A common one is assuming your perspective is complete enough that your assessment is accurate. Then, you start asking for things without communicating the context; you remove the others' ability to assess for themselves. The conflicting assessments are the root of more visible conflict, but those remain unaddressed.

A lesson can be drawn from large design firms that have become effective with functional silos - they make sure they communicate the options they're considering and the trade-offs between them, so others throughout the company can share relevant factors.

Mehl advises preparing constructive statements ahead of time before heading into any confrontational discussion. Doing this will help you stay focused and minimize incoherent or incomplete explanations. Preparing also sends the signal that you're invested in doing the right thing. It demonstrates good will.

Separate the person you’re in conflict with from that problem.

The post shares a few in-depth explanations of how to do this well, but it basically means assuming positive intent from the other person, respecting their time and sovereignty, sharing your feelings and needs, separating those from the outcome you'd like - and offering constructive suggestions.

They also share techniques for when team communication breaks down.

“It’s incredibly helpful to talk about the early days — the inside jokes, the long nights, what brought everyone together in the first place.”

“It's like a game of tennis — the longer you keep the ball in play, the more you learn from each other.” And, just as tennis players are happy winning best out of three or five sets, colleagues may need to go multiple rounds before a solution is reached.

If you're a startup founder, you probably have a big ego and a strong sense of direction. If you're co-founders, its' communication skills and empathy with your partners that'll manifest the multipliers between you.

Don't build a swiss-army knife product  

Des Traynor on the Swiss Army Knife disease of design:

When you’re drawing the line around your software, make sure you’re not leaving in marginal utility features in an attempt to add more value. These little wannabe-features hang around unloved, bloating your app, hogging the UI and adding to maintenance costs.

So far so good. However, I'm not convinced by the two-dimensional evaluation graph that Des proposes to decide which features to build. By reducing features to two questions (who will use it and how often), it reminds me of the Pritchard method for evaluating poetry, discussed in Dead Poets Society (script), where poetry is also reduced to two dimensions: the perfection/form of the poem, and the importance of its subject.

Deciding which features to include is not quite as much of an Art as poetry, but it's still complex, multi-faceted, and can be fairly subtle.

As a simple counter-example, Woobius's commercial model means that only a small proportion of users (project managers and company owners) will want to use the account upgrade feature, and they will do so very rarely (probably just once during their lifetime as a customer). This would place the "upgrade" feature down in the bottom left corner of Des's graph - and yet upgrading is obviously an essential functionality if Woobius is to make money.

So, my suggestion is to use Des's model as one data point in evaluating feature, but not as the only one. Products are complex creatures.

How to survive a due diligence  

It's often easier to start things than it is to finish them. Selling a company is not that unusual, especially in the tech startup world. What few people realise is that often, when you sell your company to any kind of decent acquirer, they won't just take your word about what's going on in the company and "open the package later" when you're out of sight.

Before you sell your company (and even, sometimes, before you take VC investment, which is a form of limited selling), there will be what's called a Due Diligence:

(...) due diligence is all about verification and risk assessment.


During a due diligence you'll likely be visited by a lawyer for the legal affairs, an accountant for the financial portion, and if you're a technology company someone that looks at the tech side of things.

This excellent blog post by Jacques Mattheij, who has conducted numerous technical due diligences himself, is full of useful information and will come in very handy if you're about to go through this process.

A golden opportunity, or not  

Peter Robinett makes a pretty solid case for why even (or especially) when reaching out to cool, startup-friendly developers, "ideas people" won't necessarily encounter that much success in recruiting them to work on their startup:

  • Ideas are easy, execution is hard.
  • People approaching developers often dramatically underestimate the amount of development work, or the complexity of it.
  • Proposing a revenue share means the developer has to take as much risk as the idea guy (for very low pay, given the point above), and trust that the business will receive the right amount of marketing/sales follow-through.
  • There's an opportunity cost to working on someone else's idea instead of for paying clients.
  • The idea being proposed is often very unrealistic (and the developer, having worked on a number of such ideas, can tell).
  • Developers have their own ideas to work in anyway.

These points will seem blindingly obvious if you're a developer yourself, or if you have some experience in the field, but to new startup founders, this is not so obvious.

Start something small  

Joel Gascoigne:

What I’m starting to notice more and more, is that great things almost always start small. Most of us know that Branson started the Virgin brand with a student magazine, but Virgin is just one of many examples which shows that the reality is counterintuitive: actually, the best things we know and love started as tiny things.

I’ve found that if I look into my own life, I find similarly that some of the most important achievements I’ve made started as little projects. My startup Buffer itself is a great example: it started as a two page website and in addition the short blog post describing this process has now turned into a talk I’ve given more than 30 times.

This applies in other areas of life - programming, for example, has Gall's Law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Questions to ask a VC  

Depending on how you ask those questions, they may be needlessly antagonistic, so be smart about how you ask them. In my experience, most VCs will talk about these points whether asked or not, as part of their standard "this is who we are" pitch.

The questions:

  • Are you accredited?
  • What's your background?
  • When was the VC founded?
  • What is the vintage year of the fund?
  • How much capital is under management across how many funds?
  • How much capital has been deployed out of the current fund?
  • Who are your LPs?
  • What is your investment thesis?
  • How many investments have you made in my space?
  • Can I speak with some other founders you have invested in?

Certainly, if a VC refuses to answer, or appears to try to wiggle out of, one of these reasonable questions (asked politely and in a friendly manner), that's a red flag, and you should dig further before taking investment.

Update: Thomas Ptacek points out that asking VCs about their accreditations is pointless.

Getting users for your new startup  

Philip Kaplan, founder of quite a few companies that you've heard of (FuckedCompany, AdBrite, and others), shares some advice about how to get those initial users:

The best sites seem to take of magically by themselves. Truth is, every site needs a little kickstart to get to its first 10,000 to 100,000 users. Consider this a list of kickstarters. But keep in mind the saying, “nothing kills a bad product faster than good marketing.” You have been warned.

The techniques covered include starting controversies, using viral tricks, affiliate programs, SEO, press, celebrity endorsements, business development deals, and offline events. None of the tips are covered in too much depth, but Philip does give examples (some based on his own experience) of how each of them has worked in practice, and so this article is certainly worth a good read.

Management is a support function  

Here's a great article from Joel Spolsky, which makes the point that management is not about command and control, but about providing support:

Thus, the upside-down pyramid. Stop thinking of the management team at the top of the organization. Start thinking of the software developers, the designers, the product managers, and the front line sales people as the top of the organization.

The “management team” isn’t the “decision making” team. It’s a support function. You may want to call them administration instead of management, which will keep them from getting too big for their britches.

While there is certainly plenty of decision-making required at the "top" (mostly about strategic direction and key hires), the decisions on what to do to react to specific daily business situations should be driven by those closest to those decisions.

The sad thing is, management gurus like Peter Drucker have banged on that drum since the 50's, and yet many businesses still operate as if centralised decision making was viable to build large businesses. It's not. As Spolsky (and, a few decades ago, Drucker) point out, centralised decision-making is simply not scalable.

That being said, of course, "building a large business" is not everyone's aim. If you don't want your business to get big anyway, you can probably sustain centralised decision-making until your business gets to a few people or so.

Leading indicators of engaged users  

Very interesting. Richard Price reports on the Growth Hackers conference:

(...) it’s important for the operational metric to be concrete, and also relatively early in the funnel of the user’s experience of the site. As the funnel continues, drop-off becomes high, and you want to find a leading indicator as close as possible to the top of the funnel that you can work on to minimize the drop-off.

Richard also gives some good examples of leading indicators from well-known examples. Figuring out those leading indicators can be very difficult, so this is useful too:

[Facebook] looked at cohorts of users that became engaged, and cohorts of users that did not become engaged, and the pattern that emerged was that the engaged cohorts had hit at least 7 friends within 10 days of signing up.

So even a company the scale of Facebook had to use good old eyeballing to figure out what was going on!

Google Analytics Alternative