Note: I am pleased to announced that I am a nominee for the 2006 Excellence in Product Management award for Thought Leadership given by the AIPMM. I will be at the AIPMM conference this April 19-21 (see www.aipmm.com) and hope to see some of you there.
Every culture has its blind spots and weak points that can trip it up despite its strengths and clear-sightedness. So, too, every industry struggles with common shortcomings that seem to grow out of misperceptions and failings learned at many companies and steadily spread across the industry.
For a Product Manager, who is usually deeply involved in all the major workings of a company, from sales and marketing to product development and the business model, it can be a sobering experience to try to overcome widespread weaknesses with few positive examples for guidance. Like personal failings, a company's flaws, especially when typical of the whole industry, can prove fiercely resistant to improvement.
Today's issue is an ambitious – perhaps overly ambitious? – discussion of common pitfalls that I have seen in the software industry when it came to attitudes towards and understanding of product requirements.
Read on below for a discussion of how to better understand software requirements – and how to misunderstand them a little less.
[private]
Requirements and Solving Your Problems
If Product Management is the wild frontier of the software industry, then product requirements are the wild frontier of Product Management. Many, many organizations judge that they have a poorly defined notion of requirements, and have had poor success at producing them. Consequently they tend to believe that solving their requirements challenges will solve all their problems.
But structured, consistent requirements, while calling for a more extensive effort than many companies do today, do not resolve as much of the software development process as many software companies would believe. Solving your requirements issues will by no means set you up to successfully develop software.
Requirements and Design
Requirements are often confused with design specs. An easy way to remember the difference is that requirements focus on the what. For example: "Provide a report that rolls up resources across departments."
Design documents and specifications focus on the how, and can be much more extensive and specific. For example: "The Resource Rollup Report groups resources by Resource Category, and contains columns for Resource, Minimum, Standard, Maximum, and Forecast."
And that's just the beginning. Design specs can include screen mockups and significant detail about how to handle different scenarios. For example: "If the Minimum and Maximum are the same as the Standard column, only the Standard column displays a number."
Requirements and Planning
Requirements are often confused with planning. Somewhere there is the expectation that if you can just get the requirements done, then development will naturally follow.
But again, requirements stick to the what. Planning, on the other hand, is where Development sits down and decides how to divide up and order the tasks.
You can have great requirements, which, if developed, would advance your product handsomely. But poor planning will result in developing those requirements much more slowly, if at all.
Requirements and Requirements
Then there are all the different types of requirements. In my most successful experience, one- and two-sentence requirements that focused on the what were passed to Development, which created a simple plan and some short design specs for areas of uncertainty.
Yet other organizations, particularly larger ones, like to split requirements into market or business requirements and technical requirements. Technical requirements are still focused mostly on the what, but include technical information necessary to build the design specs.
Ultimately your organization needs to decide whether to split out market and technical requirements, and whether to separate technical requirements from design specs. Your decision depends upon how much time you wish to spend on requirements and design documents rather than coding activities.
If I were king of the company, I would have simple requirements that represent market or business requirements. These would be followed by short documents about the intended design, which would be built as prototypes and reviewed by knowledgeable coworkers and customers. The emphasis would be on building and showing, and getting detailed feedback from groups of people. Then the key would be briefly documenting the feedback and design decisions before modifying the prototype. The prototype would become the final software as it gets reviewed and revised.
The What and the How
When you do not separate out the what and the how in software requirements, any requirements document inevitably bleeds into design specs, and becomes quite voluminous. It also means that people who are less qualified than the developers are making technical decisions on how to accomplish a requirement.
Sticking to the what makes for more concise, clearer requirements. And it lets Development figure out how to fulfill the requirements with the least amount of effort. Less effort to develop a capability means you get it sooner, and have more time for other capabilities.
Constituents and Compromise
Requirements come from many different constituents with different agendas and priorities. Those who install the software and administer the application have very different requirements from implementation consultants, developers, marketers, sales reps, and management. It's rare when people submitting a requirement see other perspectives. Usually everyone thinks their own category of requirements should hold the most weight.
As a Product Manager, you have to balance the needs of various groups and the benefits they need against your choice of which capabilities to develop. While any one group of coworkers and customers may propose a very imbalanced list of requirements, you must aim for a balance of different goals.
A software release will fare better if it includes some requirements which result in sales appeal, others in technical architecture improvements, some which benefit partners, some which make existing tasks easier or smoother, some which cut costs or provide a new revenue stream, some which catch up with competitors, and some which blow away the market with feature leadership.
It can be difficult to make individuals from Sales, Marketing, Development, and Customer Care accept the compromises that result in a balance of benefits or return for any given release. Yet it is essential to create this balance and get the understanding and backing of the management team for the final selection of what to develop for the next release.
What Market?
Focusing requirements on the market, and what the market wants, can also be a confusing proposition. If you use your existing customer base to take suggestions, you run the risk of receiving a laundry list of small changes. Specific customers often don't see why their highly arcane use of your software product isn't the highest priority for development. They are not looking at what would make your product gain market share and sell better, they are merely looking at their own goals and convenience.
So input from the market often needs to be taken with a grain of salt. Do you rely on experts for objectivity? Do you use groups of customers to debate and refine a list of needs? Do you have customers vote, only to discover that the resulting laundry list isn't going to get you any new sales against your competition?
So you may be better off obtaining some of your "market input" from visionaries in your company and the industry who are looking beyond the horizon and the problems of today. Your product needs to continue to clearly have a competitive advantage in terms of capabilities as the years go by.
Requirements and Uncertainty
Requirements are the subject of much uncertainty, and different kinds of uncertainty. And they don't do well in an uncertain environment.
The first uncertainty is the goal and scope of requirements. Are they supposed to be business-oriented or technical? What should good requirements include? Should you split out the market requirements from the technical ones? Are requirements like design specs?
Another big uncertainty centers on how to use software requirements. Who creates them and who reviews them? Is it the management team or every single developer?
But it may be uncertainty about when to create software requirements that creates the biggest obstacle to successfully transmitting instructions to Development to keep them fueled and running. Do you have them all ready before the beginning of the next release cycle? Do you wait until one release is out (at least in beta) to begin the next round of requirements? Do you build requirements continuously and have them ready any time somebody asks for them? And since when would that last option be realistic, to be constantly interrupting your work to add new requirements as people communicate them to you?
The most effective way to solve this uncertainty is to establish fixed dates for software releases, and all other points in the development cycle, and to stick to them. It can become impossible for a Product Manager to constantly update a long requirements list in order to have it ready to hand off to Development by a date which is constantly slipping.
Democracy and Dictatorship
Encouraging requirements from all coworkers and customers can result in an expectation of mob rule. People expect to see their suggestions implemented. Yet in most situations requirements will be set by enlightened tyrants, the founders, owners, architects or visionaries with a holistic understanding of the market and the competition, and an understanding of your organization's business model.
Certain priorities, such as specific partnerships or technical migrations, will be dictated from on high. Often the Product Manager's pet requirements are given no more consideration than those of other special interest groups. The Product Manager's greatest contribution to the requirements effort is not to decide which requirements make the list, but to make sure that they are thoroughly and consistently defined, and that their benefits and competitive effects are thoroughly understood and agreed upon.
Objectivity and Bias
Technology companies tend to give great weight to objectivity. Often one of the struggles with requirements is the belief that their selection and prioritization should be entirely objective. The effort to be thorough and consistent can lead to the impression that somewhere out there an independently derived priority will be assigned to each requirement. One that is rational and unbiased.
But the fact is that deciding which requirements have the highest priority is a judgment call based on a holistic view of the product and the business. And many of the top priorities will be preselected by benevolent tyrants, and were never up for discussion. The focus of the Product Manager needs to be in identifying risks and pros and cons that may not have been considered in the early judgments about priority.
Yet in the end, well considered and clearly defined requirements are the fuel that drive your product's development engine. If you can get beyond the common weaknesses and misconceptions which are holding your organization back from a successful requirements effort, you can speed development and create a more competitive product.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]