Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h05/mnt/42598/domains/ideas.poundi.com/html/wp-settings.php on line 468

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h05/mnt/42598/domains/ideas.poundi.com/html/wp-settings.php on line 483

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h05/mnt/42598/domains/ideas.poundi.com/html/wp-settings.php on line 490

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h05/mnt/42598/domains/ideas.poundi.com/html/wp-settings.php on line 526

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h05/mnt/42598/domains/ideas.poundi.com/html/wp-includes/cache.php on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h05/mnt/42598/domains/ideas.poundi.com/html/wp-includes/query.php on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h05/mnt/42598/domains/ideas.poundi.com/html/wp-includes/theme.php on line 618
Pound Takes » Blog Archive » Release New Features Early and Often: Part I
Ideas on Engineering Breakthrough Applications

Release New Features Early and Often: Part I

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.

I, too, viewed features, additions and even entire applications this way for a long time.  It’s a natural tendency to want exactly what you envision. However, it can also undermine your product and business.

On the flip side, you have a much more sophisticated way of developing and releasing new features if you use multiple levels of implementation, each building on the previous level’s functionality. You also better manage the risk of spending time and attention on the wrong product developments. If you stand back and reassess your new feature, you likely can spot a minimum set of functionality that would make this feature useful. This can be viewed as the first level on the switch. If you look hard enough — and with the help of your implementation team — you’ll likely be able to break robust functionality into several releasable iterations. We’ll call this the level approach, in which we can iteratively raise the level of functionality over time, while producing a usable product at each and every level.

Regarding risk, the level approach allows you to release or beta test a new feature early, so that you can apply value and adjust expectations using real feedback rather than internal assumptions. In other words, don’t spend money improving a feature that customers don’t value.

In part II, we’ll look at a robust catalog search feature and break it into release levels.

Tags: , , ,

Leave a Reply