This is the 100th issue of Product Management Challenges. When I began writing this newsletter a little over three years ago, it was my hope to build up an unmatched source of real-world tips and guidance about software Product Management. I am pleased to say that the many back issues have covered a multitutde of topics which are important, essential even, to the successful Product Management of software.
For this milestone 100th issue, I have chosen a topic that gets right to the core of how a software Product Manager makes a difference. That would be Requirements. Requirements loom large in the life of any Product Manager, and it seems like they are always a challenge. And what I have discovered is that the best requirements seem to be derived, seem to be an indirect result of all the direct input a Product Manager receives. Read on for a closer look at this idea.
[private]
Not As Easy As It Sounds
Creating requirements is by no means a straightforward process of collecting ideas from the field, from customers and prospects, experts and colleagues, and then writing it down. In fact, much of the input you get is incomplete or even flat out off base. The value of a Product Manager comes in hearing the many suggestions and extrapolating the patterns and needs from out of the clutter and distraction of too much — and too specific — information.
Paint the Big Picture
As Product Manager, you will collect many ideas. Some are huge: “We need a self-learning, fuzzy logic, holistic multi-modal survey tool with an analysis engine.” Many are much smaller: “The Report User field needs to change to Yes automatically if the Superuser field is Yes.”
Others are vague: “The survey screens need to give you a clearer idea of the progress you’re making.” Still others are exasperatingly specific: “Can you make the buttons wider? I like wide buttons.”
(The worst ones are the opposite of informative: “The report builder needs to be better because the way it works now is wrong.” Thanks for the input!)
In the end you will receive all sorts of suggestions, and it’s your job to put them all together, and help put them into context. Split the requirements into categories that correspond to the modules or major purposes of your product. Look for themes that become apparent as the number of suggestions build.
Then run everything through the filter that screens out capabilities that won’t give you an advantage over your competitors (or parity if you’re behind) and won’t get you much mileage with an audience of objective experts. Paint a big picture that looks good and fits the major marketing and differentiating themes of your product. What you don’t want is simply a laundry list of little improvements.
Dig For the Real Need
People, especially experienced users of your software and similar products, tend to look at a software screen and express suggestions that are only one pixel deep. “I need a Merge Mail button that lets me mail out letters for direct mail campaigns.” What has happened is that the person making the suggestion is thinking too far ahead, and too literally, about how they want to use your software screens.
Take those suggestions and clarify what the real need is. The real need is both more abstract and more applicable to a wide range of uses. The request for the Merge Mail button is really about needing to take lists that are the result of your product’s great analytical ability and using those lists for other purposes, projects such as a mass mailing if it’s a list of names, or charts if it’s a list of totals by category.
Other products, such as Microsoft Word or Excel, are your customers’ best option for creating those merge mailings or charts from the lists you develop. You don’t want to waste Development bodies reinventing the wheel. In this case the wheel you reinvent cannot possibly be as nice as the one the whole market already uses today.
So the resulting requirement in this case is to develop the ability to take a list that the user sees on the screen and export it to a delimited text file for use in all sorts of ways in all sorts of other applications. This ability, developed once, could be implemented throughout your product to apply far beyond mass mailings. The real need was the ability to get information out of your product to use it elsewhere in other specialized products.
Confusing the Software With the Purpose
It’s easy for users of the software to get so involved in the details of the tasks they perform in the product that they lose sight of the whole reason they are using the software to begin with. For example, the current product I work on has one big purpose: to help organizations become more resilient in the face of disruptions and disasters. That’s the idea in the abstract. One main way of accomplishing that idea is to build, print, and distribute plans that include instructions on what to do in the case of specific disruptions or disasters.
Consequently, there are users of the software whose sole focus is to build, print, and distribute thick plans in big binders. These users often have specific requests relating to details of how they want their specific plans to print. These details are important to them, because their jobs duties are defined as “Build, print, and distribute plans.”
But the purpose of the product is to help organizations build instructions and get those instructions into the hands of every person who needs them, right when they need them. One way, the traditional way, is to create printed plans in binders. However, another way which our software does this it to provide just the necessary tasks and instructions online, when an incident occurs, to the specific people responsible for those tasks. Targeted online distribution of this information has the potential to transform an organization’s response to a disaster.
So whenever I receive requests about printing out plans, I know that I need to step back and consider the real purpose of the software. The resulting requirement may wind up compromising some of the printing capabilities in order to provide both online and printed content.
Private and Personal Agendas
Personal agendas are another aspect of not seeing the whole picture. Customers in different segments (small vs. large companies, banking vs. marketing professionals, etc.) have different — and often partial — perspectives. It’s always important to understand what personal agenda may be associated with a given requirement. Your aim in selecting the highest priority requirements is to define those that will meet the needs of the broadest group of customers. Even if you split your product into different lines for different customer segments, you still want to satisfy the broadest group in each segment.
Technical and Business Bias
In addition to agendas, there’s bias in suggested requirements that stems from an individual’s technical or business focus and aptitude. Programmers may provide a suggestion such as “Pre-format documents in advance so that when you print them, they print faster. It doesn’t matter if they have a title page.” An executive might respond: “I don’t care if reports print quickly, but they absolutely must have a title page and our company logo on them.”
Both of those suggestions need to be tempered by the reality that neither one is so important that the other should be ignored completely. It will be up to you as Product Manager to try to reasonably accommodate both.
Requirements Are Interactive
One misconception that frequently causes the requirements process to break down is the idea that all it takes is for someone to make a suggestion, then the Product Manager records it, makes it as accurate and specific as possible, and hands it over to Development. In reality, developing requirements is interactive, the product of a back-and-forth discussion involving those making the request and those responsible for developing it.
Here’s a simple scenario:
Customer: “We need to be able to print out surveys several times as respondents fill them out. We want to see detailed progress at any point in time.”
Developer: “Because of the way survey information is stored dynamically, printing surveys while in progress would probably take three months of development time.”
Product Manager: “If you had to choose, could you live with seeing a summary screen of progress, such as the number of respondents who haven’t started, who are in process, and who are finished, with percent complete for those in process? How long would that take to develop?”
Developer: “We keep that information already, so it would take a maximum of two weeks to develop, maybe even less if we keep the percentage tracking simple.”
Customer: “Oh, I could live with a summary screen. That would really help me report progress to my management. Could I print those figures?”
Developer: “We could add a print button with about a week’s worth of additional coding.”
The end result reflects not only the most important priorities of the requestor but also the real-world limitations of your Development resources.
Requirements Are Iterative
Requirements are also something that become clearer and more elaborate over time, as the customer base builds experience with your product’s capabilities, and learns valuable lessons in how to use it. So much of the challenge of implementing a big new requirement is to figure out how widely it will be used and what its total return will be. It’s hard to estimate the potential return on something entirely new. It’s only reasonable to doubt whether it’s worth implementing at all.
Where possible, you want to implement an initial, basic phase of a new capability, then see how it plays out in the customer base. You may find to your surprise that customers don’t need part of the functionality you provided, but rely heavily on specific aspects of the functionality and need more in that area. The second phase has you expanding in the areas customers have found to be most promising, and you’re that much more confident of a solid return.
What You Ask For Depends On What You Have
Many of us have had the experience of asking for directions and getting the response: “You can’t get there from here.” The same is true with your software product. Existing development has taken you down a certain path, and unless you plan to devote significant development resources, certain requirements are simply not cost effective to implement, while others are much easier.
So while it may seem arbitrary, a Product Manager has to sort requests based on how easily they can be accommodated by your product architecture and personality. This can lead to requirements that are transformed for easy development.
The Good As the Enemy of the Best
Finally, when painting the big picture, it pays to never forget that sometimes the good can be the enemy of the best. Your company only has so many Development resources to build the product. Each suggestion uses some of those finite resources. So a requirement that might sound good, even very good, has to be ruled out if it takes time away from the highest priority requirements, the ones that are more important than all the others. Trying to accommodate too many requirements, or too many refinements of a single requirement, can mean that you fail to complete the most important new capabilities.
In the end, your loyalty as the Product Manager is to the overall product, not to specific requirements, and that must guide you as you consider, transform, and define the many suggestions for new capabilities that are brought to you.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]