In part I, I made the case for looking at features as having many releasable levels vs. just done or not-done. In this second part of the article, we’ll actually exercise the idea against an example to illustrate the nuances and benefits of this approach:

Imagine that a customer calls you to request the addition of search functionality to their case-study catalog. They sell rich content and research to academic customers; the easier the content is to find, the more they sell. She emails you a few links to some reference sites using similar functionality and sketches out how the results might appear. The result is the same if you iterate the design with them into a mature spec. You wind up with a detailed and all-encompassing vision of the new feature.

Once the end concept is relatively clear and both sides agree that the designed functionality has business value and is feasible, it’s time to look at this feature through a different lens. This neatly divides the robust feature into self-contained release levels, each resulting in value to the user or business.
continue reading this article >

If you design, develop or manage products, you’re certainly familiar with the new feature request. Let’s be honest: Adding features is what product managers, customers and businesses love to discuss, because they view new features as advancing the product. If you’re a more seasoned product manager or designer, you’ll know that eliminating and refining features is just as important as adding ones, but we’ll leave that for another discussion. Here, we’ll focus on audacious additions.

If you’ve experienced the excitement of a juicy idea for a new feature, you likely also have been surprised to run into push back from your engineering or implementation team. This can be summarized as the ever-present tension of “my vision” vs. “our reality.” Meaning, while I see dollar signs and adoption, you see implementation headaches, lack of resources and an overflowing backlog of to-dos.

This is likely because both of you are approaching the feature with an all-or-nothing, on/off mindset.

Almost every customer I’ve ever dealt with — and most senior managers who are funding product development — understand the big picture of a new feature or product addition. Even the most detail-minded customers, who provide specs on how the end product should look and function, are solely focused on the end game. We’ll call this the on/off approach — either done or not done.
continue reading this article >