Amen Brother 08 Jul 05

Long-term client projects are very draining. By the time they’re over, no one is quite happy with them

Thank you for finally saying this out loud. I’ve been thinking this forever, many have alluded to it, but you’re the first I’ve heard to outright state it as fact. I guess it’s a bit easier to say that now that you’re not relying on clients for your core revenue, but it’s nonetheless reassuring to know I’m not alone.

Ed 08 Jul 05

“We’ve always looked at things differently from other people as far as design. For instance, we launched our initial site in 1999�you can find it now at 37signals.com/manifesto. That site is all text. There are no graphics anywhere.”

Actually, there are two: 37signalsmanifesto.gif and logo.gif.

JF 08 Jul 05

“Actually, there are two: 37signalsmanifesto.gif and logo.gif”

Umm, you know what we meant.

dmr 08 Jul 05

I don’t understand how projects aren’t planned. How are the building stages of an idea executed without any planning? Isn’t there a risk here of underthinking an idea or concept and having things really blow up; or is it crucial to keep things small at this stage so if there’s a problem you can handle it with agility?

I’m thinking how this could be applied to some of my own projects where 95% of a project’s timeline is spent planning, meeting and writing. Can 37 provide some insights into lightening the planning process in a bureaucracy? Let’s say we’re already working in small teams, but we’re kind of hindered by a large project scope up front… when do you know you’ve got too much/little to go on?

JF 08 Jul 05

Isn�t there a risk here of underthinking an idea or concept and having things really blow up; or is it crucial to keep things small at this stage so if there�s a problem you can handle it with agility?

There’s always a risk — but there’s more of a risk when you think you have all the answers up front. We do less planning up front because we know we’ll learn more as the process and product unfolds.

You know the *least* about something when you begin to build it. The more you build it, the more you use it, the more you know it. That’s when you should be making decisions — when you have more information, not less.

So, yes, if you stay simple, lower your cost of change, and focus on agile development methods you can change when you need to change. Change needs to be cheap. Making big key decisions up front makes change expensive because you have to fight signoffs, “but this is what we said,” and other red tape mentalities that put process in front of progress.

Keep an eye out for our next book. It will explain this in more detail.

8500 08 Jul 05

I know in my experience, working for a large corporation, many months are spent writing Use Cases. Once the business people and technical teams are satisfied, we convert these text heavy documents into interfaces. When the documents are converted into a UI, all sorts of questions pop up that no one considered during the previous months of planning (such as tab labels being too long and forcing horizontal scrolling at default screen and text size).

So skip the document writing and head straight to the screens. The same decisions are made but in a much more expedient manner. After weeks of reviewing an 80 page Use Case, most clients rejoice when seeing an actual interface that they can understand and talk about.

Don Schenck 08 Jul 05

This is too cool because I’m a huge Tom Peters fan. Read every book, listened to many audios … Tom rules! In fact, I use his principles in my personal life in my relationship with my wife.

Kudos.

Don Schenck 08 Jul 05

8500, it sounds like you’re using Functional Decomposition where you should be using a Use Case.

A Use Case should be pretty much high level and broad with a lot of room from GUI interpretation.

At least that’s what I do — with success.

Mark Gallagher 08 Jul 05

Jason, your comments about planning are way on target.

Working for big bank doing web project work, I found the people insisting on extensive requirements documents before starting any design were really “blockers” just trying to slow the process down (and usually people with nothing to contribute on design or innovative thinking).

All our best work was done with a few concepts in our heads about improving a site, doing a quick prototype (static), changing the design a bit and then building a live prototype with real data. After kicking the tires on this prototype, we usually had a real project in motion and good result.

Innovation can be very slow in a company that follows a strict project planning process.

Keep up the good work.

Mark

8500 08 Jul 05

“8500, it sounds like you�re using Functional Decomposition where you should be using a Use Case.”

Your right Don, most Use Cases alone don’t force design decisions but in my case there are pre-determined Visual Standards that are required. The problem comes in when these two “completed” documents don’t play well together.

Patrick Teng 08 Jul 05

Sorry, this is a bit off topic…

Is that Jason in the picture in the article?

Does anyone else thinks that he looks like Justin Timberlake in that picture?

kmilden 08 Jul 05

Read Tom’s book. No wonder why he is gravitating toward 37signals. The small will kill the big.

Wesley Walser 10 Jul 05

Great read, it was nice reading about the earlier years of the studio.

asfdasdff 10 Jul 05

asfdsaf

Chuck Norris 11 Jul 05

According to the feeburner banner - there are about 1000 less readers now than there were last week.

JF 11 Jul 05

According to the feeburner banner - there are about 1000 less readers now than there were last week.

It changes on a daily basis because the Feedburner banner counts readership over the last 24 hours and readership is always lower on the weekends.

emm ess eff 11 Jul 05

JF:

[If] you stay simple, lower your cost of change, and focus on agile development methods you can change when you need to change. Change needs to be cheap. Making big key decisions up front makes change expensive….

For some the above recipe might describe a far off promised land of achievement and gratification — especially to those mired in beaucracies that reward process over progress (and people), billable hours over value for fees, and “enterprise frameworks” that seem to be more about religion than liberty.

Perhaps one reason why ‘Getting Real’ is getting real traction is because it’s being preached by an agile team using agile methods to develop with an agile framework to produce agile products.

I wonder if the 37signals book (or whatever) will be a sort of ‘Rapid Redesign’ of something like Fowler’s treatise: similar elements with better delivery. I’ll stay tuned no matter what.

cathy 13 Jul 05

Jason, thanks for the acknowledgement. The interview is a great addition to the mix of Cool Friends on our site, and I see it stimulated great discussion on yours. So, we scored on all the goals we have behind posting those interviews.

And, yes, definitely Justin Timberlake.
Cathy Mosca
tompeters.com

beckie 15 Jul 05

If I’d be Justin, I’d take my backpack and travel the world with Miss Diaz ;)