When it comes to developing new features for a software product, every Product Manager is faced with the following dilemma: more new features are needed than there are resources to add them to the product. You can’t possibly get all the features in that you want to put in.
We are told to prioritize, which most people take to mean determining which features we think are most and least important. Then you’re supposed to only do those features that are most important.
But there’s a problem with choosing to develop only the highest priority features. New developments in the marketplace are rarely limited to only one, two, or three key features. There are usually several important features being developed in the market at any given time. Competitive advantage goes to the product which manages to move forward with all those features, not the ones which only succeed at a couple of them.
Which is why I try to push for moving forward on all major fronts at once. But this is something that is much easier said than done. How can you possibly do it with so few resources? Read on for some tips on how to keep making progress on several new features with each software release.
[private]
Why Not Just Cut Some Features Out?
The decision to “move forward on all fronts” begs the question: “Why not just cut out some of the features you want? Surely they can’t all be so important.” That’s true, they aren’t.
First of all, the decision to move forward on all fronts is still a decision restricted to the higher priority features. You will always have features that simply must wait, or which you can’t justify allocating resources to compared to the most important enhancements. This is especially true if you are conscientious about noting down all features that are suggested from all sources.
But unless you anticipate that Development resources will significantly increase for the next release cycle, if you cut a major new feature out of the upcoming release entirely, you’ll find yourself that much further behind when it comes time to plan the next release.
Ask For a Little, Get a Little
Another reason to ignore the call to whittle a release down to just two or three new features has to do with the psychology of most software development organizations. There is always a tendency on the part of developers to schedule less than what they can realistically accomplish, for fear of unforeseen delays and unplanned feature requests.
You will always be called upon to push Development to do a little more than they will readily agree to do. If you ask for a little, you’ll get a little. But if you ask for more, Development will probably rise to the challenge.
It’s also more inspiring for a group of developers if the project they are working on has a bigger scope. It’s hard to boost morale and get people to rally around a cry of “We’re just going to clean up some things plus add reporting. We don’t have time to do anything more than that.”
Going Through a Phase
Many times when you talk with Development and Marketing about a given feature, the unspoken assumption is that the feature comes whole and entire, and cannot be broken up. As the Product Manager, this is your chance to point out that these features can be further broken down into phases, so that if you can’t put all of a new feature in the next release, maybe you can put in an important piece of it.
For example, when you decide you want to add a reporting function to your product, you are not required to provide it full-blown in one release. Perhaps the first release can provide a dozen basic reports. The next phase can provide an additional set of reports that are customizable in terms of date ranges and other criteria. A third phase can provide the ability to build reports from scratch. Yet a fourth phase can allow for exporting the report data to an Excel spreadsheet for further manipulation and customization.
So before you launch into development of any major new feature, you as Product Manager can work on structuring it into phases.
Customer Focus
How do you go about structuring a feature into phases? If you try to work with a team within your own company, you’re likely to get stuck in disagreement and debate.
The most profitable way to determine how to break out an enhancement into phases is by consulting customers. They are the ones who will ultimately be voting on how well you do at determining the highest priorities, by deciding to buy (or keep) the software or not. So go right to the ones whose decision counts most.
You will have a difficult time of it if you try to ask open questions of customers, such as “What do you think the top priorities are for this feature?” Instead, provide a list of features, with enough description, or even sample screens, so that customers (and prospects) can quickly grasp their significance and select between them.
Customer focus groups, either formal ones that take place in person or less formal ones over webcasts and conference calls, can be a great forum for different customers to speak up about their priorities. These are also an opportunity to get some worthwhile debate going between customers about the relative merits of the different capabilities on your list.
The outcome of focus groups or surveys is a valuable sales tool. Use this information with prospects to help them see how other companies are setting priorities as they struggle with the same issue. For example, prospects who are looking at a new customer service system don’t just want to hear about your system. They want to benchmark their own difficulties and priorities against other companies who are using the same system. They want to know which features are most important to companies like theirs.
Surprise! It’s Simpler Than You Thought
One thing you may be surprised to discover is that a capability that sounds grandiose may in fact boil down to something that’s reasonably simple to implement.
For example, when I presented a CRM product, I often heard prospects and customers talk about wanting an “email blast” capability. They had heard of sophisticated packages that spat out emails to tens of thousands of recipients. But such a capability was so complex and involved that it would take two years to develop. The software applications that had pioneered an integrated email blast function had huge price tags and took 18 months to implement.
It turned out that when individual customers scrutinized the various components of the capability, they were more than happy with the ability to call up a list of customers (something that was already available in the software) and press a button to export those customers into a comma delimited file (that was the new feature). The exported file was then used in Excel or brought into inexpensive email marketing applications to send out targeted campaigns. The Export button was the top priority, and it solved 80% of that fancy sounding “email blast” requirement.
A second priority was the ability to keep track of the customer lists that were exported, associate them with campaigns, and track results in terms of increased purchases or profitability for a campaign. That provided the other 20% of what was truly needed.
We would never have found out that we could provide the “email blast” features so simply and so quickly if we hadn’t brainstormed with customers on exactly what they needed.
Pioneering Major Architectural Changes
Implementing major architectural changes can be a special challenge.
Every Product Manager faces the daunting task of figuring out whether, and how, to move a product forward to the next technology platform. It was a market requirement to move to Windows, or Windows-like interfaces, from green screens. Nobody would argue that moving to a Web-based architecture has been vital for most software products.
But such sweeping architectural changes to a product risk eclipsing new and improved functionality. That’s because the effort required to make such a change can easily require all development resources. You often read about entire product releases which consist of “Web enablement” or “reengineering for .NET.”
Instead of sacrificing a whole release to rearchitecting, you have another option. You can conduct the effort over multiple releases, implementing the new architecture module by module. By trying the new architecture in one or two modules in a first release, you also create a pilot effort where you take the inevitable lessons learned and apply them to later releases. While you lose a little time reworking the initial modules, you more than make up for that by having a tried and true new architecture once it has been carried through to all the modules.
You also have a product that continues to add new features which are in demand in the marketplace, all at the same time that you move your product forward to the next industry standard architecture. This is the kind of product momentum that will leave the competition wondering how you did it.
Outsourcing
If you try to move forward on all fronts, some of the capabilities you want to add are likely core features where your developers are needed to apply their expertise and experience with the product and the business subject matter. But chances are that other features are more general, such as reporting, messaging, or the ability to build custom portals of information.
One tactic that adds development power to your in-house effort is to outsource capabilities that are outside the core features and technology of your system. Outsourcing can be as dramatic as offshoring or as traditional as hiring a group of contract programmers to work on site.
Outsourcing is appropriate when you can clearly define and bound a feature, and it is not intimately tied in with your core product. It can let you add breadth to your product capabilities as your core team adds depth.
Using Third-Party Products
Third-party products or technologies is another way to move forward on all fronts. If you want to implement alerts and messaging, there is no need to build the code from the ground up. By integrating a third party product, you benefit from the fact that the product’s development team will continue to refine, broaden, and deepen the features. You will have effectively set up a way to move forward with messaging capabilities with relatively little work on your own team’s part.
But from the customer’s perspective, the credit all goes to you when new messaging features come out in the third party product.
A Decent Feature Is Better Than a Future One
Many times, I see good ideas remain unrealized in the software while people debate the details of the features, and agonize over whether a feature is good enough. But if you make sure you use customers and prospects to identify the most important components of a capability, it’s far better to create a simple version of a feature and have people out there using it every day than to build a much more sophisticated version of that feature that won’t be put to use before two years from now.
By putting a simple version of the feature into active use, three things happen. First, people start using the feature and you can measure its impact on the value of the product. Second, customers provide helpful, practical feedback that only comes once someone starts using the feature regularly. Third, you find out just how well the simple version (or first phase) of the feature fulfills the overall need that the complete version was designed to handle. Often it turns out that what you thought would get you one-third of the way there actually takes you two-thirds of the way home.
And by having a steady stream of new features, although simpler than you’d like, and steady incremental improvements coming out with every release, your product develops a reputation as a market leader.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]