The Lean Product: Saying No

By Justin Ekins

A core tenant of the Lean Startup approach to launching products is to constantly gather and use customer feedback to define the direction of your product. That’s why launching early with an Minimum Viable Product is so valuable—additional time “perfecting” the product is time that could have been better spent incorporating feedback from customers.

Despite this focus on customer feedback, often we hear of successful startups that specifically choose not to incorporate features that are most frequently requested from users. While on its face, this seems inconsistent with the Lean Startup approach, incorporating intuition and vision into one's design is, in fact, critical.

Fred Brooks, author of The Mythical Man Month, discussed the failings of "design by committee" in his book The Design of Design: Essays from a Computer Scientist:

“Each player has a wish list garnered from his constituents and weighted by his personal experiences...Who advocates in the requirements process for the product itself—its conceptual integrity, its efficiency, its economy and robustness? Often, no one...The result, of course, is a grossly obese set of requirements, the union of many wish lists, assembled without constraints.” 

In reality, designing products is about balancing delicate tradeoffs. A designer cannot add an additional feature to a product without simultaneously increasing the complexity of the user interface, or increasing memory/processing requirements, or decreasing the product’s battery life, or pushing back the release date, etc.

A large committee of bureaucrats, each with his or her own wish list, when tasked with building a product will maximize the number of included features, without necessarily considering the cost (in terms of product integrity and user experience) of each incremental addition. Broadening the committee from a dozen or so employees in a company to a user group, or to the entire base of users, does nothing to solve the problem of design by committee—in fact, the problems inherent with the process only worsen.

Instead, designers of products must filter the “wish lists” they receive from users with their own judgement and sense of the tradeoffs associated with the inclusion of each incremental feature.

For example, last winter I visited Dropbox during Westrek and discussed with their BD and engineering teams some of the most requested features they received from their users. One feature they frequently received was a hosted solution for enterprise and small business clients (as opposed to Dropbox’s current “cloud-based” solution). The Dropbox team understood that pursuing a hosted enterprise version of Dropbox would necessarily distract their team from the more consumer-focused product that they had been working on. It would add complexity to the back-end infrastructure, as well as more options to choose from on the product download webpage. Ultimately, they decided not to pursue this opportunity, as it did not fit with the strategic vision of the company. If they had instead built every feature requested of them, they could conceivably end up mired in several different versions of Dropbox, bogged down in a confusing user interface, and bloated with ever conceivable feature.

Steve Jobs famously said “Focus is about saying, No. And the result of that focus is going to be some really great products where the total is much greater than the sum of the parts.” Saying No is as important when it comes to user feature requests as it is with internal constituencies within a company. Pursuing every good idea that comes to the attention of a user or engineer will inevitably lead to overcomplicated, crappy products. Choosing only the great ideas and balancing the desire for additional functionality with the need for product integrity and simplicity is critical for creating a truly great product—and is entirely consistent with the Lean Startup methodology.