Blog

  • VC Funding for Geeks; or, How to Get Your Technology to Emerge the VC Way

    Geekvc Marc Hedlund is O’Reilly’s Entrepreneur-in-residence – his session on VC funding used software development, coding and hacking analogies to illustrate the intricacies of securing venture funding for a startup business. Hedlund is a veteran of three startups and around a hundred VC pitches, so he speaks with some authority on the process.

    Though the idea is the creative spark for a startup – Hedlund stresses that its is not the most important element – the most important first step is incorporation and that it is a process worth learning, if only to guide others in choosing partners and setting up a new business.

    Helund advises thinking about the pitch – ensuring a description of the company if articulated so that the time consuming process of atracting attracting can begin.

    VCs will examine others who may be exploring similar opportunities, the backgrounds of individuals involved in a venture and potential customers. Hedlund describes this phase as a tedious merry-go-round where an infinte number of questions can be asked. Gaining progress with one VC is often the breakthrough that enables a startup to attract interest from other VCs and gain investor momentum.

    Hedlund notes that it’s important to remember that VCs don’t create companies and are not the first or last step for a company…more close to the beginning of the end, though not even close to the end! It’s down to the startup to create the organisation from nothing (technology, people, equipment, stationary!) in order to attract funding and the sought after ‘term sheet’ – the terms under which a VC will provide funding,

    1) Things to do before looking for VC

    • You need real customers, even a single customer who believes in your idea.
    • Consulting – doing other work to pay costs, whilst developing the product.
    • Attract angel investors.
    • Secure bank loans.
    • Secure government grants – Flickr/Ludicorp first secured grants, followed by angels and then customers.
    • Invest yourself (Bloglines & Jotspot were self-funded).

    2) Focus on the business, not the funding

    • Look for alternatives for funding; dependence on VC is risky, though can enable a faster pace of development.
    • Build a product.
    • Get users.
    • Make money – dont spend it!

    The advantages of VC not only cover funding, but also credibility and a degree of guidance and review from VC partners. Also, VCs can make introductions, act as advocates for the company. One thing to baer in mind is they will usually have the power to remove you from the board, unless the board is structured to favour your position. Hedlund identifies the key to successful VC investment ironically as being in the position where VC is not required, the business is self-supporting and simply requires VC to accelerate growth.

    There are however exceptions – where millions are required for development costs, when competing with other VC-backed competitors or large partners (such as handset manufacturers) are required.

    3) No means maybe, Yes means maybe!

    • Mever walk away from a VC who doesn’t accept.
    • Keep feeding the VC information – unless you hate them!
    • If the reaction is positive (enthusiam is inveserly proporitional to response!)
    • The physical performance of a VC in the first meeting can indicate their board management style – nurturing, advisiry, good listener though comments like Super! Great! can be indicative of a lack of substance.
    • ‘If the other guys fund you – then I will!’
    • Proceed only with those you’re happy doing buisiness and get them all to closure – dont allow feature creep.

    4) Funding is more than a fulltime job

    • One person needs to do all the communicating with VCs and look for patterns.
    • Do the marketing using a strategy like the ones at Victorious, business development and HR yourselves – find the best people and hire them.

    Average efforts/timescales

    • 10 face-to-face meetings = 1 term sheet
    • 3 term sheets = 1 financing
    • From pitch to term sheet = 2 months (10+ meetings)
    • From term sheet to money – 1 month
    • 6-12 months overall
    • Avoid August and December – people are on vacation 🙂

    Hedlund advises startups to follow the blogs of noted VCs (Feld Thoughts, VentureBlog) to better understand the business of being a VC. VCs are also businesses and their goal is to make more money than is invested.

    Hedulnd also states that when VC isn’t correctly applied, then an exit strategy (by IPO or otherwise) becomes difficult. Also, it’s worth noting that ‘funders do not equal founders and investors are not inventors’ and most pertinently that VC is a consensus business – many intelligent people agree on a business.

    What You Need

    • One Powerpoint deck of 10-15 slides
    • 2-3 page executive summary
    • An introduction to a VC – don’t submit online, but get a personal introduction
    • Don’t send web sites or blogs – stick to the conventions of Powerpoint!

    Finally…the Technologists Trap

    • Don’t focus too much on the product (limit to just one slide).
    • Will customers care about this product?
    • Are they high margin?
    • What has changed to allow a startup to grow?
    • Are there enough customers willing to pay?
    • Is there a profitable sales channel?
    • Do I want to work with these people for five years.
    • Are the numbers believable?
    • Try the Steven Silbiger’s Ten-Day MBA/
    • It’s easier to learn a business, but harder to have an idea and product.

    Hedlund’s complete presentation can be downloaded here…

  • Lessons Learned While Building Basecamp

    37 Signals promotes itself as an elite team of expert web design and usability specialists, dedicated to simple, clear and usable customer-focused design. Their Basecamp and Ta-da List take simple social software applications such as wikis and blogs, adapting them for enterprise users – applying the simplicity and intuitive nature of those applications to otherwise costly and bloated Office suites.

    The CEO of 37 Signals, Jason Fried, presented a session describing the development and support of Basecamp by a small development team, undertaken within a relatively short timeframe.

    Fried begins by outlining the importance of hiring good people who are positive, well-rounded such that they can perform many overlapping roles, quick learners, trusted to work independently and interestingly suggesting that they need to be good writers – given the reliance on electronic communication in modern development. Fried stated that he’d take someone happy and average over and above a ‘guru’ figure!

    Secondly, Fried stressed the importance of embracing the constraints that a business works within, rather than adding more resources or finances to solve a problem:

    • 7-hour time differences between geo-distributed teams are often seen as a problem, but can actually be beneficial to round-the-clock development & support.
    • Self funding is preferable, whether by revenues or your own money – every penny is a hard penny to spend if it’s your own!
    • Small teams are a blessing, allowing individuals to be more empowered and actually more accountable as there s little room to hide behind others.

    However, Fried did underline constraints that a business can place upon itself – 37 Things actually decided to build simpler, fewer products with less features. This ensures:

    • A lower cost of change
    • Less room for error
    • Less support
    • The encouragement of human rather than technological solutions to problems

    Like other speakers at ETech, Fried recommended a rolling release strategy – ‘build a half a product, not a half-ass product…have enough confidence to do a rolling 1.0 rather than a perpetual beta’. Fried advocates:

    • Start with the UI – there’s nothing functional, about a functional spec!
    • Ignoring detail early on.
    • Decisions are temporary; make them just-in-time when you have real information.
    • Listen to the product and how it’s used by users.
    • Improve what you have with constant refinement.

    In essence, Fried’s recipe for development can be distilled to:

    • Start Designing
    • Start Prototyping
    • Start Experiencing
    • Start Changing
    • Rinse & Repeat

    It was noted that this style of development is really only suitable for fine for Windows applications, GUIs and web-based services…as one audience member pointed out, he could not apply such a methodology to the development of microprocessors or ASICs.

    Fried was keen to underline the notion of reducing the mass in development, but undertaking only what is needed as it’s required. Employing the Japanese method of Just-In-Time production, allows development to remaining flexible with parts and components:

    • Scalability – buy infrastructure as needed; one box for 1000s of users for 3-4 months.
    • Reporting – get the basics in place for auditing, reporting and looking at accounts.

    As an example, Fried illustrated how the billing system for Basecamp was not available for launch, but completed in time for the first billing cycle after thirty days…37 Things only made this decision as the right information on usage flowed back from the launch platform.

    In terms of service support, Fried oddly suggested that developers should actually undertake support activity – ‘chefs become waiters!‘ – so they can share the annoyances suffered by users!

    Fried went on to highlight a number of random tips for promoting usage and creating passionate amongst users and developers:

    • Offer feature food – e.g. you may not have a Mac product, but can output iCal diaries
    • Run 30-day major upgrades, holding some features back to build momentum & good will.
    • Articulate transparency on all user information and usage to build trust.
    • Encourage your staff and others to write about your product, talk about your product, the experience of building it and the problems encountered.

    In conclusion, Fried’s advice can be summarised as:

    • Reducing Mass
    • Embracing Constraints
    • Getting Real
    • Managing Debt
  • Where The Girls Aren’t

    In three days of tutorials, keynotes and other sessions, I’ve seen no female speakers… though I think there are a handful in some sessions later today – maybe five in total throughout the week.

    Interesting.

    Though I’m sure the robot community is equally under represented.

  • Networked Objects

    http://conferences.oreillynet.com/cs/et2005/view/e_sess/6327

    Tom Igoe

    network programming has become central to all programming

    saw computer as endpoint rather than a passthru – literally by removing the computer

    controlling all spotlights in a civic space

    carenet display for intel – older people living alone to have contact with relatives without ‘placing calls’ www.petercessler.com/ubi-comp

    white stone – emotional communication over the net, placing hand on stone in one pocket, would relay the buy CBD products to another stone

    building for one – CBA style

    wifisense – wandring round NYC to find wireless hotpsors – a purse that spots wifi networks (nyc wireless! mugging!)

    protest button – press the button simultaneously infront of their building and also DoS’ing their website! distribtung responsibiltiy in network and phyisical space

    needies –

    junkies little helper – furniture that participates in a chat room (coutney love’s medicine cabinet), logs into chatroom and jumps into chatroom and sas ‘dont listen shes high’ based on contents of cabinet – also could call 911!

    KU – iyashikei-net sculptures that would cry – caress to comfort which would light the light of happiness!