daily articles for founders

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

Is it the right idea?  

Paras Chopra offers three key questions in determining whether an idea is worth pursuing. He calls them "validation", but I hesitate to accept that, since validation is external, whereas the questions Paras picks out are basically introspective angles on an idea:

  • Do you think what you are providing is creating significant value for anyone? Value should be so significant that people should curse you if you take that service away from them. Do you think it could happen?
  • Do you think there is big enough market for the service AND the market is easy to reach (without spending bootloads of money)?
  • Are you enjoying doing this? Do you see yourself doing this for several next years?

Notice the "do you think" angle. Validation questions would be "Are people telling you that what you are providing creates significant value for them?" and the answer to that question would involve data. An idea is not validated just because you think you know the answer.

That said, those are three important questions to consider before throwing yourself into an idea. If you're providing no value, the market is too small for your ambitions, or it's not an idea you feel passionate about, it's probably not the right idea.

Should you really be a startup entrepreneur?  

Great read, by Mark Suster, about the difference between being an entrepreneur and being a VC. The description of being an entrepreneur is pretty spot on, and if you cannot read that story and think, "wow, ok, I'm alright with that", you probably shouldn't start your own business... yet... maybe...

The one thing that those "Entrepreneurship is scary" posts always miss is the progression in one's character. I am a very different person than who I was when I quit my safe Accenture job to jump into my first flaming disaster of a startup. Most entrepreneurs I've talked to agree that you learn a whole lot about both how to run a business, and about yourself, when you spend a few years running a startup.

I'd argue that most people who start startups aren't ready for them, at the beginning. They progress towards this Zen-like resistance to risk, stress, and rejection, but it takes a couple of years of constant terror to get there. So, even if you don't see yourself in that list of characteristics yet, it's probably enough if you think you might be able to see yourself there sometime in the next few years.

Properly following up  

I guess by now I don't need to tell you that you should always follow up. No exception. If someone spends time with you, listens to you, probably gives you some advice or helps you in any other way, you follow up. A follow up is not only an act of courtesy, but your opportunity to build a long-term relationship, ask for a favor or simply say thank you. Its the good manners that your Mom taught you.

I was talking to a "super-networker" type at a networking event last week, and to this he added the following:

Always follow up on the same day.

I can't say I've managed to apply that consistently yet, but it certainly makes sense. Following up on the same day shows a certain keenness and energy that people will usually respect. Also, it ensures that the person you're following up with won't have forgotten you.

Another good point:

Don't trick yourself into believing that it ends here and all will be good. This is only the beginning - granted you got it of a good start, but now you want to mature your relationship (think long term, not short term again — no-one likes to feel used). Send an email every once in a while, pointing out some interesting news or research which is relevant for your contact. Ask for the occasional coffee to compare notes. Get creative and add value for the other person - trust me, it will pay back twice over.

Ask yourself: how many opportunities have you missed because you didn't follow up consistently enough?

How to choose a cofounder  

Excellent article by Elad Gil, outlining many points that are worth thinking about before deciding to work with someone. As I've mentioned in an earlier article, starting up with someone else can be fraught with peril, particularly if they're a friend. Together with my article, this checklist of questions could save you a lot of pain.

Here are the high-level points, but please read the full article to get the substance:

Key criteria for selecting a cofounder:

  1. Ability to communicate with each other. Can you have an honest and frank conversation with your cofounder?
  2. Alignment on key questions. What are their objectives? Why a startup? What do they care about in company culture? Who do they want to hire? How do they view investors? How ethical are they? What is your role versus theirs?

Elad also points out that you should be clear about who's in charge, or else your disagreements will freeze the company, that you should avoid starting up with someone with strongly overlapping skills, and that it's a big bonus to have known them for a few years and even worked together before.

Why pitches fail  

Here's a great article from a few years back, by Eric Ries. It breaks down pitches into several types, and examines the key questions that need to be answered by each type of pitch. Worth reading alongside this article, posted a couple of weeks, ago, about startup itch archetypes.

Eric outlines the following pitch types with their relevant "key questions":

  1. Printing money
  2. Promising results
  3. Micro-scale results
  4. Working product
  5. Prototype product
  6. Breakthrough technology
  7. All-star team
  8. Good product idea
Three traffic triage questions  

Ilya Lichtenstein on traffic triage, the activity of efficiently filtering which online marketing channels are worth investing in, and which aren't:

The trick to allocating your marketing effectively is implementing some kind of traffic source triage system. When encountering a new traffic source, you want to be able to quickly and consistently categorize it into a low, medium, or high priority group, before spending any time or money testing it.

Ilya then proposes three key questions to ask about any kind of traffic, and goes into detail about how to answer them:

  • Is there enough volume?
  • Is the traffic cheap enough?
  • Does the traffic convert well enough?

Importantly, Ilya describes ways to answer these questions without having to invest money into the traffic source.

Business storytelling  

I have an article sitting on my hard drive that I wrote, some time ago, about telling stories to teach. I wrote about 2/3 of it, but never published it.

A few weeks ago, I was chatting to a good friend, who was trying to get a point across to me about this blog. Three times, he tried to make the point. I felt quite thick - here he was, spending a good chunk of time explaining what was obviously the same concept to me over and over again. Clearly it was something important, yet somehow I wasn't quite getting it.

Finally, I understood - my articles were a little too dry, I had boiled them down to the raw facts, and thereby, I had made them less effective. I needed to make it "softer", more human, to get the points across. That was the point he was making (and it is a very good one). After all this, I finally remembered the unfinished article, and pulled this quote out from it:

People's attention is a precious commodity, so it is easy to try to spare it by condensing our points too much. Yet, by removing the storied aspects of our messages, we can easily make them forgettable and ultimately ineffective.

There is something ironic (and sad) about having someone spend an hour telling you something you not only once knew, but even wrote an article about.

I wonder how many other good points I've forgotten. It's hard enough to learn new life lessons, and to make it that much harder, our brains are constantly recycling, dumping, forgetting old wisdoms that were once familiar. Perhaps we would all be geniuses and wise men if we stopped forgetting so much of the good stuff that we learn. Or perhaps we would all go mad.

Regardless, here's an excellent article by Mark Suster that begins with a story, and ends with some really practical points about how to tell these teaching stories. I'll let you read the article for yourself, but in case you need to whet your appetite, here is an overview of the advice:

  1. Have a thesis from which to build the story.
  2. Have supporting evidence.
  3. Use analogies.
  4. Keep it human.
  5. Reinforce the storyline at the end.

I'll add a key point to this, drawn from more traditional storytelling:

  • Have a dramatic arc.

Good fiction stories follow some kind of dramatic arc. Drama is the conflict that makes the story move forward. Teaching stories are no different. Your protagonist (whether yourself or someone else) needs to encounter a problem, face a difficulty in solving it, and finally resolving it in some kind of way that teaches something to the listener or reader. Drama (not to be confused with melodrama) helps connect to the audience on an emotional level. People empathise with the conflict that the protagonists is facing. If you want your stories to stick, don't forget the dramatic arc.

Picking technologies on the right side of history

When we started Woobius back in 2007, we believed (rightly or wrongly) that we needed to be able to provide a relatively complex, "UI-heavy" front-end to make things simple for our non-technical users. For example, one of the key screens in Woobius is an explorer-like file browser, loved by users, and only possible because of the technology we picked.

We surveyed the field in 2007, which was in the very early days of jQuery, Dojo and other rudimentary toolkits, and came to the conclusion that it would be very hard indeed to use them to deliver our vision (particularly since IE6 support was not optional for us).

So we picked... Adobe Flex.

Based on our perspective, it was the right choice. But our perspective was wrong. There was a factor which we didn't take into account, though we knew about it. It was clear to us that, because of the greater dynamicism and wider community behind javascript toolkits, they would eventually surpass Flex's power, flexibility and speed (and indeed that is what has happened). We knew Flex was on the wrong side of history, we just didn't realise how much it mattered.

As a technology cofounder, one of your unspoken functions is to be a visionary. Businesses are long-term endeavours (or should be). When you make fundamental technology choices for a business, they are there to stay. The longer such a choice is made and not changed, the longer it will take to change it. So, when we chose Flex, we chose it not for the short term (as we may have thought), but for years to come.

And, in hindsight, that was a mistake that cost us.

The cost of using Flex

Adobe (perhaps seeing for themselves that the writing was on the wall for Flex, though I think it was probably sheer laziness) never stood behind Flex the way they should have. They let ridiculous bugs and limitations fester over the years, and in the meantime, the chaotic horde of Javascript toolkits advanced, took over, became superior, better, and became the standard.

All the community effort that took the web into the design-centric UI richness that we know today went into Javascript, not Flex. Flex is now a relic that must be extirpated at great cost to guarantee a future to the Woobius collaboration product. And this is only 4 years after starting development.

When Kublax (a Mint clone) closed its doors in February 2010, articles mentioned there was an alternative called Money Dashboard. I went to check it out. I signed up. I went to the login screen, and I felt this sinking feeling in my stomach. Money Dashboard uses Silverlight. Oh woe! In 2010? Sure enough, within a year, Silverlight was doomed by Microsoft themselves (followed, a year later, by Flex itself). The anonymous tech cofounder of MoneyDashboard made the same mistake we did, though even more flagrantly. I never even bothered to log in, in the end, put off and saddened by the choice of Silverlight.

The history test

When you're picking what technologies to use in your brand spanking new startup, your responsibility as a technology cofounder is not just to make the best choice for today, but to look 3 to 7 years into the future, and make a choice that will be sustainable for at least that long, if not longer. Don't lock your startup into a technology path that is a dead end.

Yes, technology changes rapidly and somewhat unpredictably. That is precisely why you need to make sure that the fundamental, critical pieces of technology that your company depends on are there for the long haul, not dependent on a single vendor, and, most importantly, pass the "history test".

Every time you choose a critical technology to lock yourself into, ask yourself: "Is this technology on the right side of history?"

If it's not, think again.

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.

A design for each budget  

Here's a set of different design options, broken down by budget, from the Folyo blog.

  • $0: Use a free framework and UI freebies
  • $0-$100: Get a pre-made theme and nice typeface
  • $100-$500: Consider crowdsourcing
  • $500-$1000: Crowdsourcing or freelancers?
  • $1000-$10000: Get a good designer
  • $10000+: Agencies

The anonymous author also describes each of these options in some detail and proposes some options. Definitely worth a bookmark!