swombat.com

daily articles for founders

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

Startups and growth rate  

Under the guise of providing a new and updated definition of "startup", Paul Graham provides a fascinating insight into the way YCombinator focuses their startup founders. The key is a focus on relentless, week-on-week growth

We usually advise startups to pick a growth rate they think they can hit, and then just try to hit it every week. The key word here is "just." If they decide to grow at 7% a week and they hit that number, they're successful for that week. There's nothing more they need to do. But if they don't hit it, they've failed in the only thing that mattered, and should be correspondingly alarmed.

It's an interesting way to drive activity, to be contrasted with the "Lean Startup" approach that focuses on validated learning. Certainly YCombinator is successful with it, no doubt about that. However, YCombinator startups benefit from the regular input and insight of a set of people who, individually, have broad, deep and long experience building, watching and helping startups in many contexts. Collectively, these people (Paul G, Jessica, Harj, Paul B, Garry, and many others - and let's not forget the network of YC Alumni) represent, by far, the greatest concentration of startup-relevant experience, wisdom and connections in the world.

And even so their success rate is very far from 100%.

Competing incubators, accelerators, and indeed startups, would do well to bear that in mind before they try to emulate this model without the same advantages, and instead of trying to copy the focus on growth, they perhaps should try to reproduce the impressive support system that enables such an approach to work.

How to find a technical cofounder  

Jeffrey Talajic discusses how to find a technical cofounder. In short, go to the relevant networking events, talk to people, discuss your project, let them self-select, and bring them on slowly while testing out the relationship. Oh, and be picky about who you select.

Decent advice, apart from one thing: I believe that if you've started your business already, it's probably too late to find a technical cofounder for this one (though you can find a good CTO-for-hire). But you can find a tech cofounder for your next business.

You shouldn't start a business with someone you've just met. Let the relationship evolve, grow, and solidify, and then consider starting a business with them.

What have you done wrong?  

We've all made mistakes. We've all done things wrong. We all know it. The important thing is what we've learned from those. It doesn't matter what you got right or wrong, but what you walked away from that experience with and how you'll use that information to your advantage in the future.

Over the last few years, even while things have been going well, I've made it a regular exercise to reflect on the last 6-12 months and write a brief "lessons learned" document, as if the startup was in fact a failure.

It's a fairly negative thing to do, and can be a bit demoralising, but every time I've come away with a useful insight.

It's also interesting how hindsight changes your "lessons learned".

How to use Business Development in a startup  

Via this post, here's a great set of slides by Charles Hudson, about when to hire someone for Business Development, and how to use them properly.

Here's a summary/extract of some of the key slides:

The purpose of business development is:

  • Licence someone else's technology or content for use in your product or service
  • Distribute your product or service through someone else's network

Revenue growth, sales, "business guy" are not BD roles.

First, make sure you actually need BD. Maybe you want a business hire who is not a BD person, to work on relationships with key partners, do market research, or help you sell your company. BD is costly to staff, more so than even a talented engineer or designer, so make sure you really need it.

BD creates extra work for the product team. If you're not willing to do the extra work, don't hire a BD person. Be aware that internal projects will often get deferred to process deals signed by BD.

Make sure the relationship between BD and product is healthy: don't allow overly padded estimates of delivery time, but also don't allow BD to over-estimate their likelihood of closing deals. In addition, make sure that your BD people don't treat pre-deal engineering work as "free" - spec work and mockups cost, and bringing in your top engineers to a meeting is very expensive. But make sure your engineers respect the BD function too.

The presentation also includes information on how to evaluate Business Development deals, and how to make sure you're not caught out by typical BD problems. It's worth a read.

Commit to being an entrepreneur  

We've all heard the old parable. The chickens and the pigs decided to make breakfast. The chickens provide the eggs, and the pigs provide the bacon. The chickens are involved, but the pigs are committed.

Jeff Bussgang, VC at Flybridge Capital, makes the point that VCs naturally prefer investing in founders who are committed to the startup - i.e. they've quit their job, they've gotten started, they're getting it done with or without VC money.

Following on from this morning's article about shutting down your startup, I think it's worth drawing an important distinction here.

"Being committed" is important. I've observed founders who could have made a company work, but failed to do so because they never really committed into a sink-or-swim push. Being very good at keeping multiple options open, they never jumped into the startup struggle with enough single-minded focus to actually make their startup work.

However, conversely, I'd argue that the commitment is to being an entrepreneur, not to a specific company. Many of the successful entrepreneurs I know have their fingers in multiple pies. They're committed to working for themselves, they're committed to launching cool new things and making them profitable - but they are not committed to any single specific venture (at least not until that venture is clearly taking off and a surefire winner). They juggle, they make multiple things happen, and they follow success wherever it appears.

In 2011, it's not unreasonable for one person to be running several startups. Be committed to the entrepreneurial way, but don't put all your eggs into a single startup until you create one that's clearly a winner.

Joel Spolsky's method for splitting shares in a startup  

Excellent, in-depth method. Worth reading through carefully to understand Joel's method and thinking. Some of the key points:

  • All founders should get an equal share (no matter who had the idea). Trying to calculate an uneven split is not worth the trouble.
  • Each successive layer of employees split an even-sized yearly pool (among progressively larger numbers of employees).
  • All shares vest, with a vesting schedule such as 25% in the first year and 2% for every successive month.
  • External investments just dilute everyone.
  • If an early employee/founder needs to take a salary, don't solve that problem with a different share allocation - just keep track of how much he/she was paid, and give an IOU to the other founders.
  • Having the idea doesn't mean you should get more equity.
  • People who don't work full-time on the idea are not founders.
  • If someone contributes assets to the company, pay them in cash or IOUs, not shares.

Great tips, well worth reading, though I think the startups that applied all of them can be counted on one hand.

Dangerous data for startups  

An interview with Patrick Vlaskovits, posted on the chart.io blog, outlining some good points about dangerous data:

Many people, especially those handicapped with a graduate level education, like myself, think that data is only interesting and can only be acted upon if it is "statistically significant". In the context of early stage Customer Development, I believe this is well-intentioned, but ultimately, misguided.

and

Evidence comes in a diversity of forms. It can be anecdotal, it can be in aggregate or it can be a trend line. If you take an open-minded approach to the types of evidence you'll accept, and adjust for their biases/problems/problems accordingly, you'll likely fare better in the chaos of startup-land than just simply jettisoning what you feel is low-quality data.

and

In my opinion, trying to make CustDev formulaic, well-that's a road to perdition. Some of the techniques that may work now, might not work as well in two, five, ten years, so there is no point writing a hyper-specific rule book because no book can know exactly the context you are operating in and when you are operating there.

There are a lot of other good points made, generally pointing to the fact that not all business decisions can be reduced to a statistical A/B test, and how techniques and methods for customer development need to remain contextually sensitive to be useful. It's worth reading the full article.

The MicroPreneur Manifesto  

Rob Walling of SoftwareByRob has just published a "MicroPreneur manifesto". In it, he presents some principles for building microbusinesses online - not the kind of business that will sell to Google for $10m or even $1b, the kind that will make a steady income for its owners, and grow slowly and organically, and enable its owners to eventually have a relaxed, pleasant lifestyle with enough time to focus on other things that they also enjoy.

It's a good overview of an online business philosophy, which is different from the typical Silicon Valley approach, but certainly works for some people (and, possibly, it works for more people than the so-called "startup lottery").

I'll list the headings here, but please do have a read to get the full text.

The headings:

  1. It's much harder than it looks.
  2. There is power in working alone.
  3. Focus on your strengths.
  4. Freelancing is dangerous.
  5. Seek leverage.
  6. Stay away from moonshot ideas.
  7. Product last. Market first.
  8. Charge for your product.
  9. Passion isn't all it's cracked up to be.
  10. The pressure of freedom.
  11. Become a black belt internet marketer.
  12. Think human automation.
  13. The more you do in public, the faster things will move.
  14. Failure is an option.
  15. Live like a pauper, treat your business like a king.
  16. Reject growth.
5 lessons about building apps  

Anthony Feint, the Australian founder of Task.fm shares five key lessons he's learned from his experience building apps:

  1. Stop adding features: each feature has a cost in complexity and customer support cost.
  2. Don't promise what you can't deliver: your priorities are ever shifting and unpredictable; promising things to customers who ask for them leads to disappointed customers, and even when you do deliver them they're never as important as they seemed while they were "hot".
  3. Communicate: if your app goes down, don't keep quiet about it, it's probably the worst thing you can do; let them know what's happening.
  4. Charge more: if your product is better than the competition, charge for that.
  5. Ignore the critics: don't waste time responding to overly harsh critics; they'll move on to something else.
How to get a job at a startup if you aren't a developer  

Some solid advice from Eric Stromberg. In short:

  1. Know the tech landscape better than anybody else.
  2. Form an opinion and start a blog.
  3. Be familiar with the startup culture.
  4. Offer a concrete skill.
  5. Take an internship.
  6. Send cold emails.
  7. Understand that most people get non-technical jobs at startups through their network, not job postings.
more