I was fortunate enough to recently stumble on the online edition of “Getting Real,” a book written by the founders of 37signals (you can click the link above to read it for free online, or check out the updated version titled “Rework”). If you’re not familiar with 37signals as a company, you probably are with at least one of their products. They’re the guys responsible for Ruby on Rails and Basecamp, as well as other well-received Web applications for project management and collaboration. The book is broken up into short chapters drawing on 37signals’ own experiences in building successful products.
A few takeaways:
- build only the most essential features for your product (say “no” again and again)
- don’t write functional specs
- use real words in Web prototypes vs. the ubiquitous lorem ipsum verbiage
I became interested in 37signals a few years ago when I found myself the only non-Rails user on a plane full of users bound for a Ruby user group conference. Asking “what is Ruby on Rails?” elicited an enthusiastic discussion on what they did and why they LOVED Ruby on Rails. Looking back, their passion was reminiscent of SolidWorks users. Curious about the company, I ended up becoming a Basecamp user (the SolidWorks marketing team uses Basecamp extensively).
Given all of the Apple succession discussions taking place in the wake of Steve Jobs' departure and passing, the “saying no” theme is particularly relevant. Jobs famously called thousands of features “ugly” in response to a record industry exec’s demand for additional features in iTunes pre-launch. In fact, the Apple culture is to say “no” in order to focus on making the best products you can.
"Getting Real" states “each time you say yes to a feature, you’re adopting a child” and talks about the need to make each feature prove itself and show it’s a survivor. I asked a few members of the Product Management and R&D teams how this “fight club” process applied to SolidWorks, given that we just rolled our our 2012 release, which includes hundreds of customer-requested features. Not surprisingly, SolidWorks follows a pretty rigorous process of elimination as well. In fact, in the early days, the prioritization of which features would go into the next launch was affectionately termed “the food-fight.”
Today, Bruce Holway, the Director of Product Definition, plays a substantial role. Product Managers collect customer requirements and requests from support, the field, and customer prioritization systems. Bruce’s team then does additional customer research and winnows the proposed feature list down even further. Each feature is ranked either 1,2, or 3 with 1 being a “must have” and 3 a “nice to have.” The big question for every feature is “do our users really need it?” R&D also factors in the ROI of each feature and time/effort to build a capability vs. the perceived customer value of a capability.
In many cases, the discussions are particularly lively because the developers and product managers feel strongly about never building something they wouldn’t love using themselves. In fact, SolidWorks employees across the company use SoldWorks for their own side projects -- their boats, their souped up vehicles, and fine wood-working projects. Jeremy Luchini is but one great example.
To quote Aviator Antoine de Saint-Exupery, “a designer knows he has achieved perfection not when there is nothing more to add, but when there is nothing left to take away.” While it may seem contradictory, in product design and business strategy, subtraction can add value. What about your products? Can you identify maybe just one feature that you could remove from a product you are designing right now? How might removing that feature make the product better?
Recent Comments