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

Comments

  1. good post of what I also found to be a good session and one that FT could really learn from in the process of developing new services.
    The ability to spin out a new ‘lab’ (for want of a better word) who could approach product design like this would give us an edge over other operators

    Reply

Leave a Reply to Ian Hay Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.