“Everyone tries to do too much: solve too many problems, build products with too many features. We say ‘no’ to almost everything. If you include every decent idea that comes along, you’ll just wind up with a half-assed version of your product. What you want to do is build half a product that kicks ass.” Quote from the founders of 37signals (in Taylor, W. C. Practically Radical: Not-so-Crazy Ways to Transform Your Company, Shake up Your Industry, and Challenge Yourself, 2011).
“Doing less” is a deceptive term, one that gets you thinking. While you might be put off by the phrase because the mantra in most companies is to accomplish more, doing less actually means delivering more value, more throughput, more ROI, more creativity, and being more focused.
What the quote above from 37 signals’ founders says in effect is “think more, do less.” It’s easy to think about what to put into a product, we often get suggestions from a wide variety of sources—engineers, customers, managers, executives, the janitor, and other teams. Product backlogs can grow exponentially. It’s easier to say “yes” to various stakeholders than to say “no.” One of the consistent problems with engineering organizations is too much work-in-process (WIP). Projects are undertaken because the prioritization scheme breaks down (if there is one). It’s easier to tell the VP of manufacturing that “we’re working on your project,” than “we can start on your project in 2 months when we have adequate capacity.” So projects stack up in WIP and throughput drops, sometimes drastically, because of thrashing and multi-tasking.
Each of us have a handy “To Do List”, maybe what we need is a “To Do Less List.” There would of course be some process around these lists. For example, one rule might be that for every entry on the To Do List we have to make one on the To Do Less List. A product manager might create a backlog of features to do, and another backlog of features not to do. Having an explicit list of not to do features sends a message to everyone that this list is important. Deciding not to implement a feature isn’t enough—they have a tendency to creep back on the active pile.
Similarly, you might keep a list of all the meetings you decided not to attend (this one isn’t as difficult). As you start keeping meetings to attend and meetings not to attend lists, you begin to think about and refine the criteria for each. Actually, you will begin developing these criteria for each of your dueling lists.
You could even think about celebrating your “Not Done” lists at retrospectives. Here are all the features we did; here are all the ones we didn’t do. Here are all the meetings I didn’t attend this iteration. Here are all the projects we didn’t start this month. Here are all the overhead items we pushed aside last quarter. Obviously we also celebrate what we accomplished, and that those accomplishments were sharply focused on value, on real customer solutions, and on creative ideas. By lining up both lists, we begin to see how our focus on effectiveness rather than raw productivity actually improves overall performance.