Read about my overall impression of the workshop. My raw notes from the workshop are below.

This workshop is based on ideas they developed while creating 37Signals products such as Basecamp and Campfire, and writing the Getting Real book. There is a lot more in this session than in the book.

Presenters: Jason Fried (Product Manager), Ryan Singer (Designer), David Heinemeier Hansson (Programmer)

Getting Real is not a set of guidelines it is a set of principles that guide the decisions they make

Not about having a repeatable process, GR isn't about codifying process
If you repeat process, you aren't incorporating previous learnings
Use common sense
Give your intuition space to work

Don't worry about the future and don't hire for the future
If you hire 8 people then you are setting yourself up to build products that require 8 people
You will build products that match the people you have
Don't scale ahead of time
Focus your attention on now
Worry about handling a million customers when you have a million customers
Focus energy on getting a million customers, not having a million customers

Figure out how to make money now, not later

Web 2.0 has confused what is a good idea vs what is a good business

Building something and throwing ads on the side isn't that interesting

People are paralyzed by mistakeaphobia
Getting Real is about making small decisions so if you make a mistake you can change it quickly
It is harder to change big decisions

GR is about doing the interface first. Let the interface be the spec.

The interface is not a wireframe or a photoshop mockup
You do it in HTML so you can use it while you build it
Get something that works very soon
It is not about doing integration at the end. The Frankenstein approach will surely produce a monster

They try to build documents that don't die

People hold Flickr up as a poster child of Web 2.0, but Jason doesn't think it is a very good business. They had to sell to Yahoo to stay in business.
If you have hundreds of thousands of customers and you are barely at breakeven, you have a problem

Q: What about Basecamp free subscriptions? Isn't that like Flickr?
A: Vast majority of people use the free accounts, but the minority of paying customers more than pay for the free ones. Flickr has a lot of processing requirements, whereas Basecamp is not very compute intensive

Ignore imaginary problems. "Well what if this happens?"

The future drives the future

The longer you can push off decisions, the better.

Making mistakes is a good thing.

Change is expensive when you make it expensive
David: When you use Java.

Just wing it (tm). They don't know if they are right or wrong. Just do it.

They spend a maximum of 5 minutes thinking about consequences
If a decision could destroy the company, they'll do something else

Q: I'm confident this works on a small scale, but I don't believe it is scalable for large organizations.
A: David: Disagrees, thinks this will work in a large org. When you are successful in Getting Real environment, there is a tendency to remove all the previous restrictions (money, etc.) and add more people, time, which is what causes problems. Start.com is an example at MS that started with only 3 people. Google Maps started with 6 people. iPod started with 9 people. It can happen in large companies.

Q: Have any of you ever worked in a large company
A: No

Less Mass - larger moving objects are harder to change than small. Less software. less code. less features. more change.
Just in Time Thinking

Suggests you hire only multi-tasking team members. Don't hire a "data architect" (David: or worse an "enterprise architect")

Have made many last minute changes

It just doesn't matter
People tend to overcorrect problems. People want to create a procedure so the problem doesn't happen ever again. You make a lot of mistakes so you wrack up a lot of these procedures and effectively tax everyone forever.

David: There is a million simple problems to solve before you get to the complex ones
Jason: Don't open up, one down.

There is no feature ever that is worth a month of their time. They can develop a new product in a month.

Clever software is too freaking hard and it doesn't work.

Q: How do you handle conflicts?
A: Surprisingly, we don't have many because we have agreed at a cultural level (less software, etc.) You tend to diverge when you have different goals. We make smaller decisions. You tend to but heads when you have to make big decisions.

Q: How do you implement this when you are working with big companies that require a lot of process?
A: Don't work with those clients. Don't let your clients hire you. You hire the clients. Just try these things and see what happens. Start slowly. Take things out of your proposals. They used to write 12 page proposals. Then 6 pages. Then 1 page. Everything worked out really well.

David: a little corporate disobedience is a good thing. Corporate loyalty is about doing the right thing for the business.

How do you start
It is all about people.
Hire generalists. Hire curious people. Don't worry about where they went to school or their GPA or their long resume.
Hire happy people - you want to hire people that will help the morale of the company
Hire great writers - A lot of work today is communicating through writing (email)
Great generalists can empathize with other fields. You don't want just a database expert that only thinks in his silo. Or a designer that only knows photoshop and not HTML

Hire less and hire later
They like to have three people work on version 1 of any new app. This restricts how much is done (which is a good thing). Only need 1 programmer to write a program. Only need 1 to design a product.

It is about growing organically. Not trying to give birth to a 20 year old. You want to give birth to an infant.
Because you only have 3 people working on a project, you necessarily reduce the scope so you have to focus on the important stuff.

Staying away from one another is a good thing. You can have too much collaboration.
Just like REM sleep, there is REM programming and designing which is very hard to get into if you are constantly interrupting.
Very easy to bullshit when you are sitting beside each other and have too many meetings.

You don't want to make meetings the way to solve problems. They should be the exception, not the rule.

It is hard to figure out if a programmer is good by just talking with him for an hour. You need to work with him a sustained period of time to understand what they are about. This is a great reason to work with open source because you can look at a programmer's work over a period of time. Open source programmers love to program because they are doing it for free.

When they hired Ryan, they went out and found 5 people they like then gave them a task to redesign Verizon's home page in 5 days. Didn't give them any guidelines.

All of their new hires have been cherry picked.

Define your mantras
- Less software - attack the requirements and chop off the complex stuff
- Say no by default - but you need an environment where new ideas are encouraged even though they may not be accepted. Don't get so wrapped up in your ideas where a "No" will ruin your day. It is not that you can't do everything is that you shouldn't do everything. You can add equalizers and audio recording capabilities, but then you wouldn't have iPod. You should never cater to a few high powered clients because they have too much control over the product. You become a consulting firm but in a weird way because the client is telling you what to do. Better to say no to a few high paying customers and yes to a lot of low paying customers.
- It doesn't matter - many situations where they are debating certain features for a while and someone will say it doesn't matter. It takes a little bit of froth off your ego by realizing it just doesn't matter. David: The bigger companies get the more unique they think they are, but really they are more mundane and just like everyone else.
- Done - Be hungry for decisions. A group of people can decide where to go to lunch but are afraid to make a decision about software
- Half, Not Half Ass - Work on fewer things better

Define your vision
e.g., "Project management is communication" (Basecamp), "Word is overkill" (Writeboard), "Competing with a post-id note" (Ta-da list), "Chat is a destination" (Campfire)
Q: Couldn't you have used a Wiki with Writeboard?
A: David: Wikis are not for humans. Writeboard is not about teaching someone how to use a collaboration system. It is about writing small pieces of text.

No functional specs
They are political specs
They are "cover your ass" documents
They are "blame deflection" documents
Functional specs are all about "yes" - there are no "no's" in a functional spec
They give the illusion of agreement because there is a lot of room for interpretation
It is more important on having agreement 3 months ago than building a great product now
Not humanly possible to make 100 decisions within 2 weeks - the first 10 pages are typically good but the next 50 are horrible
When you've made 10 decisions in a day you've depleted your decision making power for the day
It is a lot easier to put a lot of stuff on a piece of paper than put it on a screen

Q: But functional specs are good as a communication tool
A: David: they are good for communicating things people don't care about

David: Functional specs suck because people don't know what they want before they see it.

How they do it: ideas, paper sketches, html screens, then a prototype
Prototypes should not be thrown away.

Their designers and programmers use the software from day one, so they don't have a QA team.
QA is a big deal in big software but they have bugs too. With web-based software you can change things much quicker.

Basecamp was 4000 lines of code when it was first released. Now it is around 9000 lines. You shouldn't look to the big software firms like MS for guidance on testing because they are writing millions of lines of code.

If you aren't using the software every day then you need the customers that will very close to you from the beginning.

Until you see something you real, you can't decide whether it is the right thing or not
Get as close to the real thing as quickly as possible

Architect Christopher Alexander (Father of Pattern Language) used to mock up his building designs in real and make changes based on that

First step: Brainstorm ideas
Second step: Make paper sketches - fast, easy, cheap. Nothing you wouldn't mind throwing away after 20 minutes.
Third step: Design screens in HTML. Using real data is real important.
Last: Get the Prototype working. Use it while you build it. You'll find mistakes earlier. You'll discover what's missing.

They start an app off with more than they end up with

Don't spend time on stuff that doesn't matter. They took out a search feature because no one has any data on day 1. Build it later when people actually need it.
They didn't have a billing system on day 1. They had 30 days to write it so they wrote it on day 23.

David rant: high level components are evil
He tried to abstract to-do list for ta-da list because to-do lists are in several products
They are pretty much roughly the same and abstraction doesn't work
Abstraction works when things are exactly the same
Reuse is way over-rated
It works well for infrastructure, but not business logic or app functionality
You need to work in an environment where the act of programming isn't so hideous so that you want to reuse everything
Context is more important than consistency - it is more important to tailor for the context than using the same underlying code

Don't confuse enthusiasm with priority

Beware feature loops….features lead to features lead to features
e.g., adding a "meetings" tab to Basecamp
Requires a lot of features you wouldn't think about initially

Hidden costs of features (the cheapest part of a software business might be writing the software)
-support, docs, tour, terms of service, clutter, more software, localization

The technical aspects is just a tiny part of what makes localization hard

Make opinionated software (software that isn't right for everybody)
Avoid preferences
False idea that you are empowering users by giving them a lot of options but you are penalizing them
As a site designer, you'll never see all the permutations of options that user can select if you have tons of prefs
Made a lot of preference decisions in their apps (e.g., number of things displayed on the screen, how things are sorted, etc.)
For v1 you don't need permissions

Selecting good "Non-preferences"
Everyone benefits from having a good defaults.

When you go to a restaurant, you are paying for the chef's expertise to make the meal the right way. Software should be the same way. You are paying for them to make the right decisions. When you buy a CD you are paying for the music the band made, not what you want them to make.

Talked about Kathy Sierra: you can develop some boring and bland product that won't offend anyone or you can create something users can get passionate about and some people won't like it.

Focus on the Epicenter of the app, not the outer framework
Design centers of activity, not wireframes
Don't waste your time on wireframes - it’s a dead document, too many states
There are at least three states for any page: Working page, blank slate, error
Showing a potential customer the blank slate with nothing on it is a mistake - should show example data to get them excited

Take the stuff that matters and make it pop
Strong
Normal
Weak

Header
Some normal text (and some details)

Don't stay in the 256 web color palette

Try to leave the "interface out of the app" and "let the content shine"

Don't use many graphics, just a few icons

Emphasize (make bigger) the most important elements

The CSS, code, markup, and presentation should have similar relationships between elements

Use the "smallest effective difference" (from Tufte)

Yellow fade technique to make clear something was updated

Use the same interface for admins and clients
When you have a separate screen, it often looks much worse than what users get

When a problem is too hard, change the problem

Don't dictate what tools people use

Jason: they only hire people that use Mac as their primary OS.
Q: What about Linux?
A: David, if you have enough time to sit around and configure Linux, you probably need more hobbies

Q: But you don't use Mac for your servers?
A: David: Use FreeBSD. FreeBSD and Linux are great for servers

From screens to programming:
Motivation is the key to programming
Create a programming environment that promotes happiness
"Happiness-driven programming"
Optimize for happiness before anything

Beautiful code is the key to programming happiness
beautiful code is readable, short, easy to maintain, fast

One of the more controversial things with Rails is they don't put logic in the DB, no stored procedures, no triggers, constraints, foreign keys, etc. They can get away with this because they have a single interface into the DB
Q: What about indexes?
A: They use indexes to make the apps fast

Stored procedures are not necessary to make apps fast

Knowledge on performance optimization is some of the most perishable

They optimize when they need to, not ahead of time

They handwrite some SQL when necessary for edge cases

Be careful when you hear:
That should be easy
Quick fixes are the most dangerous
"Just" and "only" sedates you
It is never that easy.

Be wary of science projects - trying to be too clever when it just doesn't matter
The answer: cheat. If it looks clever, no one will know if it actually is or not

But will it scale?
Nothing ever scales on the first try
Look forward to the day people care

Work in iterations, preferably weekly
Stop treating bugs special
Treat the software like a person, listen to suggestions, mind long term health (don't pile on the hacks)
Trade concessions - do less
Start testing today - reduces stress, build confidence, enable courage. You don't want to be afraid of your code base

They don't do user tests, beta users, etc. They are using the apps from day 1.
They go from development to production. Deployment is real cheap
Sometimes they update once a week and sometimes 5 times per day
They don't care if a user hits the app at the 1 second the app is being updated

On to promo and launch
Don't get hung up on domain names - they couldn't get backpack.com, basecamp.com, etc so they chose alternatives
Memorable is better than descriptive
Don't issue Press Releases - blah blah blah
Tell a story instead
Best promotional tool is a good product. Let people try, use, and feel it.
Use your Marketing $ for something else. Free shipping with Amazon came from through their Marketing budget
Some level of advertising is ok, but down the road
Emulate drug dealers - give them a little taste, then hook them
Bulk of their paying accounts started off as free accounts
Campfire you have to sign up for a free account first then you can pay
Let people start using the product as soon as possible
Only have 5 fields on the sign up form
Don't forget common sense - don't hide the sign-up button. State costs prominently. Explain refund policy up front. Offer mailing list signup. Blog the product (let's you tell a story about the product).
Build buzz - tell mavens and insiders, buddy up to like minded journalists, offer a mailing list sign up
Monitor buzz: technorati, blogdex, feedster, del.icio.us, daypop
Feature food: Rails, RSS, iCal (got thousands of visits from the Mac community because they supported iCal)
Promote through education: you can either out-spend or out-reach (e.g., the yellow-fade technique)
Don't worry about giving away secrets because you don't have any
Don't go into stealth mode
Promote from the inside - do a good job of calling out upgrades within the product (inline ads that aren't obnoxious)
Describe benefits not features. Lightly prod people.

They don't worry about trademarks until the product is going to pan out

Things are simple until you make them difficult

They don't really know how they price things. How much would they pay for something? Think they got Basecamp pricing wrong to start. Started off too low. Didn't have any complaints from high end after raising the prices, but did get some complaints on the low end. Make a case as to why you are increasing the prices.

Launch is just the beginning
Betas are bullshit - shift responsibility from you to the customer. Not encouraging confidence in the product. Just launch it. Take responsibility.
You are going to be getting feedback and making changes regardless of whether you are in beta or not.
Betas made sense with CD-ROM software, but not now with the web
Release and iterate in the wild
Special betas won't be used
Nothing is ever perfect - betas set the wrong expectations
Release a major update 30 days post launch - demonstrates momentum, shows you are listening and adjusting, flights fatigue, hold back some features, and spread the good news
Always have something good to say every few weeks

Tech Support
Sucks. Decreases your faith in humanity. Raises your blood pressure.
But it is good pain to feel. Their pain should be your pain.
When you have a call center in India, you don't feel that pain
Builders should support it
It is like the Chefs becoming the waiters
Jason gets 60-70 emails a day for support
Preempt support with design ("Tell me more" links)
A common problem in tech support is the Us vs Them mentality
- Low expectations of who you are (told us of all the threats they received)
- High expectations with you solving their problems
Disarming techniques - people appreciate quick responses, be as honest and direct as you can, cut your losses with wackos, the more you write the more they can respond on
Only provide support via email - use gmail. Don't keep stats and don't have a ticket system.
Say they try to get back to users from 1-4 hours during business day
It is amazing how people think you are out to get them.
"ASAP" goes to "take your time" when you get back to customers quickly
Have canned responses at the ready: How do I cancel? How do I export? Where do I log in? I forgot my password. Feature requests. RSS/iCal
Uses TextPander to auto-generate canned responses
Get users feedback, we read, then we throw it out. They don't keep a long list. If the feature is important enough, customers will keep asking for it. The important stuff will keep bubbling up.
You don't want to offer phone support. It will destroy you.
Hard to scale with 500,000 users and only 7 employees
They don't offer support for free accounts (but they don't check when a support request comes in)

They use Campfire more than any other app. They use it constantly to communicate with others on the team. Their culture is in Campfire. They've only met Jamis (lives in Provo) in person 3 times

Mistakes they may be making
App-less app (e.g., Writeboard) - you don't have to sign up to use it. It is document-centric, not app-centric. You don't have to logon to use it.
Over-thinking affiliates program - eventually decided to credit a user's account instead of paying out cash (you get 50% of the user's first monthly payment)
Iteration fatigue - hard to keep doing weekly iterations when you aren't actively building the product
Acclimating hires - haven't done a great job so far acclimating new hires, pros and cons of remote workers. Campfire helps them. Voice if their last resort. Use skype as last resort. Considering adding a "push to talk" feature to Campfire.
Single sign-on - doesn't think it is a huge problem. Thinks techies are enamored on this problem and wasting a lot of time and money. Big science project.
Rotate chores - so people don't get sick of what they are doing like bug fixes
Backpack debt - Old stuff that they are afraid of touching

They use managed hosting for their infrastructure. They are switching to Rackspace.
You shouldn't spend money on servers until you really need it.

They don't see Matt and Jamis very often, but see everyone else a couple times per week.
Helps that the culture is to avoid the phone and meetings.

Q: Have you thought about bundling?
A: Have done some cross promotion, but they don't have integrated billing

Sometimes when they cross promote, they get some users that are really mad because they see it as advertisements

Has a problem with people that block ads because this stuff isn't free. Yahoo isn't free, ads cover the costs.

Programmers have their own installations, designers work on the dev box in their own sandbox

The use Ruby, MySQL, Apache, FreeBSD
Have only used custom C code one time (for Campfire)

Test on Safari, Firefox, and IE6.
IE6 is a big morale killer. They cringe every time they have to test their app in IE6.
Had to stop supporting IE5 because it was so bad.

Going to email discount to all attendees for 37signals products

They are ok with people posting notes on the web.

top