Article

Jason Fried: “Build half a product, not a half-assed product”

John McCaffrey

Published on: September 24th, 2008

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Hammer

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 it’s 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 it’s 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

Working at a consulting company like Orthogonal 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 it’s 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 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

“We like to think of ourselves as curators 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 aren’t carefully selected isn’t a museum, it’s 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,

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, it’s 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?