“Build half a product, not a half-assed product” - tips on clarity and focus from Jason Fried of 37Signals

John McCaffrey, Wednesday, September 24, 2008 @ 3:31 pm

Jason Fried from 37Signals spoke yesterday at the ITA "Speaking of Success" event, about the history of 37Signals, their philosophy and culture, and the critical business decisions they've made to get them where they are today.

The software biz is fundamentally broken. Too many products fail because of the obsession of adding more and more, and trying to do too much.

Jason went on to say that the approach of adding more and more only works for companies that have lots of money and lots of time, but that for the average company the main goal should be to build something that is "good enough," get it out to the users, and improve the design based on their feedback. The challenge of which features to include, and which to say "No" to, is covered well in the "The Innovator's Dilemma," which he said "everyone in this room should have read." The book resonates the core philosophy of 37Signals, which is evident from their blogs, their book "Getting Real," and the design of the Rails framework. As an example of the "Good Enough" philosophy, Jason used his laptop and its basic webcam to stream the Q&A session out over justin.tv and send out a text to the 37signals Twitter group. "The quality probably isn't that great, but its good enough," and with that quick setup he had now broadened the audience by 1,000 users or so. (I searched for the video archive at justin.tv, but didn't find it yet.)

"Our products do less than the competition"

While this quote isn't new, I still find that its worth digesting, particularly as it relates to product planning and product design. I'm a big fan of Agile and iterative development, and the idea that we don't have to have the full product requirements solidified before we can get started. I like to take a product vision to market quickly, improve on the design, and add features as their necessity becomes more clear.

I found that the things that Jason mentioned that resonated with me the most were closely in line with what I liked about DHH's Q&A session at last week's WindyCityRails conference in Chicago. I think a big part of 37Signals success is due to the fact that its two primary partners are totally on the same page.

Working at a consulting company like Pathfinder presents two major challenges in this area. First, the customer most likely doesn't know anything about Agile, nor do they really care about it. They want to see results and the details of how those results come about may not be something they care to explore. Secondly, our customer cares deeply about the design of the product, and the features that absolutely HAVE to be in for the release. The idea of going to market with "less" is a difficult concept to swallow. I've found that the more the design process explicitly involves the actual end user, the easier it is to investigate the importance of a given feature, ask them about it, prototype it, and figure out if its going to make things better for them. Conversely, if the end-user isn't closely involved in the design process, feature priority is more of a guess, and out of fear and lack of certainty features are included because "yeah, we might need that too". So when the question is raised, "Which is a higher priority, feature A, or feature B?", the answer is often an unequivocal "BOTH!"

On this point Jason had two elegant explanations that I hope to draw from. First, doing "less" really means covering the "essentials" of what is needed, and doing those "fewer" things better. He mentioned their products as being like a tool, with a specific, focused purpose.

"A hammer is a tool, its very focused, and has a clean, simple interface."

It strikes me as a perfect example of clarity and focus, because no one is screaming for a hammer that measures distance, cuts wood, or tightens nuts & bolts. Its intended use is clear, it doesn't need to do more than that.

"We like to think of ourselves as curator's of the product. A curator at a museum chooses which pieces of Art should be included in the collection. They say "No" to many things. A building full of lots of Art that isn't carefully selected isn't a museum, its a warehouse"

I've certainly seen applications that were a "warehouse" of features in need of greater focus and "tasteful selection" for what should be included. My mission now is to find a better way to deliver the message that "less is more," and that in most cases, its better to get the application out to the users quickly, and leave room to iterate and improve on the design, than it is to try to build and release the perfect product all in one shot.

How do you deal with this issue in your day to day work? What effective techniques have you found for bringing clarity to the design of a product?

Photo Credit:
Darren Hester
under a Creative Commons Attribution License

agile ajax

Comments: 2 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I don’t link people comparing software to “Cars”, “Hammers”, “Nails”, “Tools”, because software is fundamentally a different entity. Applications should have features which should be on demand, but services should be focused on doing single thing.

   Doing less may be good for all the sites that have cropped up, that are task specific or cater to users single need, but not for application which demand functionality and features on one page.

   Comment by Ranjan, Tuesday, September 30, 2008 @ 3:13 am

2. 

   I agree that software is a different animal. I think there could be a whole post on “the top 10 worst things that people try to compare software development to”, but honestly I think those comparisons will always happen. In a way its kind of hard-wired into how people learn about and understand new concepts.
   What comparisons do you make when explaining the dev process to someone? What effective techniques have you found for handling the balance of “its like planning a building, in that you need to know certain things in advance, but its not so rigid…so its like being able to call a new play while you are on the field…”

   Comment by John McCaffrey, Thursday, October 2, 2008 @ 11:25 am

Leave a comment