Category: Business

  • ABCs Of Design

    From Frog Design’s column at Gizmodo:

    A. Hire a competent designer at the C-Level in your company, and trust her/him to help integrate design into your infrastructure. Apple follows this model, as Jobs serves as the CDO (Chief Design Officer). He has a great aesthetic and works closely with his design team to build superior products.

    B. Take a user-centered approach to product design. Seek out real people and engage them in the design of your products by asking them what they need, prototyping the possibilities and getting feedback from them on the result. I’m not talking about focus groups, either. Groups end up being ruled by one or two strong-willed people, and the rest of the group will defer to their opinions. Do one-on-one interviews in people’s homes to get their personal opinion, and observe their surroundings. What they say and how they live will tell you more than the lemmings that comprise most focus groups.

    C. Craft a distinct look and feel for your entire product line, thereby setting your products apart. NAD has such a distinct look, and one could easily pick them out in of a line-up of components. The design isn’t award-winning, but at least it’s recognizable.

  • From the Garage: Lessons Learned Birthing and Building Web Start-Ups

    Mark Fletcher, founder of both Bloglines (just acquired by Ask Jeeves) and ONElist (now Yahoo Groups), presented a fascinating talk on what it takes to launch a startup in the online services market – notably how to design and build systems for reliability and scale and on budget. Fletcher’s talk was actually a useful compliment to Marc Hedlund’s earlier session on VC Funding for Geeks. Fletcher outlined a ‘garage philosophy’ for creating startups, consisting of a number of core principles:

    • Passion for the idea
    • Utilisation of cheap technologies
    • Simplicity
    • Releasing early & releasing often
    • Involving users – the best features come from user requests
    • Have fun, be passionate and enjoy the work
    • Moonlighting – limiting risks by continuing to work a ‘day job’
    • Obtain funding from friends & family before VCs
    • Begin with free services to lessen pressure
    • Offer a developer API to encourage innovation
    • Hire a lawyer, from this weblink online
    • Find good help – notably a sysadmin
    • Outsource tasks using freelance resources such as eLance

    Fletcher characterised registration-based websites as having two core infrastructures: front-end web servers and mail services (anything that talks directly to a user) and back-end systems for user data, other databases and storage. Software recommendations included:

    In terms of hardware choices, Fletcher recommends:

    • Dedicated servers rather than buying or hosting your own equipment
    • Design for cheap hardware
    • eBay!
    • APC power distribution units for remote power cycling
    • HP Procurve networking appliances
    • Avoid Seagate Ultra-SCSI drives
    • A good phone for SSH remote system administration

    To illustrate architectural choices, Fletcher actually cited some of the design decisions made in the development of Bloglines:

    • Bloglines RSS news feeds are actually copied to each of ten web servers rather than being served directly to each requesting client. Copying files can outperform client-server requests in many cases.
    • The number of subscribers to Bloglines is currently counted in one pass through all user records and saved, rather than calculated on the fly – improving performance, but shifting from real-time to periodic reporting, which is more than adequate for current needs.
    • The Bloglines desktop notifier experiences 1-200 hits per second, so data is held in memory rather than retrieved from disc.

    In deciding upon storage options, Fletcher contrasts relational databases with file-based storage and notably the use of RAID storage or redundant servers. ONElist utilised arrays of RAID drives to provide a storage infrastructure, where Bloglines utilises a software RAID-1 infrastructure based on Linux.

    In administering systems, Fletcher doesn’t give too much detail, but recommends:

    • Utilise DNS round-robin load balancing for for web servers
    • Employ hot backups for offline processing
    • Worry about cooling co-located data centers

    Finally, Fletcher urged entrepreneurs and innovators to avoid making stupid bets citing a bet to shave his head if ONElist was ever sold!

  • 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