Requirements are the challenge every Product Manager faces. Each software company manages to deal with the requirements headache more or less successfully, and headache – or heartache – is exactly how many people look upon the whole process.
Yet viewing requirements as a necessary evil can get you into trouble. After all, requirements are how your product moves forward, and such a critical aspect of your business must take center stage and have the full and enthusiastic backing of the entire organization, from sales and marketing to engineering, consulting, and customer service.
Given that you must face this necessary, painstaking process, the question becomes: How much pain should it take? You want to find the minimum amount – the minimum daily requirement, so to speak – that will fulfill your development function’s nutritional needs. There’s no sense in overkill, because the developers won’t necessarily listen to the details anyway.
So here are a few guidelines to help you get the most return on your investment in the requirements process, and choose the appropriate path for your organization in an industry that demonstrates widely different levels of effort from company to company.
[private]
What’s the Minimum Requirement?
Okay, so we’ve established that requirements are, well, required. We also know that most people who will be involved in the process find them hard to face. This means that you want to aim for doing only what is necessary and not a stitch more. This is not to say that you can get away with a slapdash effort.
I work to adhere to the following dictum when creating requirements that are not too little and not too much: What, not how.
What, Not How
The point of thinking in terms of what, not how, is to focus on what you as a Product Manager know best, and let the software developers take care of what they do best. You know what you want when it comes to new features, capabilities, or integration with third party products. The developers are the ones who can come up with the best ideas for how to implement those ideas — and more likely the fastest solutions, too, since it’s in their best interest to keep the work to reasonable proportions.
Spend the requirements time writing about what it is you want. For example, your product needs to provide a set of options for assigning cost to inventory rather than dictating how costs are assigned. So focus your attention on what those options are (LIFO FIFO, Average Cost, or Actual Cost), what elements of information need to exist (tracking of the First, or Last, or Average Cost), and what they apply to. In this case they apply to the cost of an inventory item when it is removed from stock, that cost being used in GL entries recording cost and profit.
No need to get into the fact that you think there should be a table with dates, quantities, and purchase costs from which to select the appropriate cost. No need to list every single point in the software where Average Cost gets recalculated. Leave that to the developers to determine. On the other hand, providing and explaining the commonly accepted Average Cost formula would be very helpful.
What If It’s Too Little?
The first pitfall to avoid is providing too little in terms of requirements. If you don’t provide enough specifics, the joint sessions where you explain the requirements to developers will get bogged down in a whole lot of back and forth about just what it is that you’re asking for. And that’s just counting the first, official discussions.
(For some pointers on putting enough content into requirements, you can request a copy of a past topic in this newsletter called “Requirements: From Hype-ful to Helpful”. See the Previous Topics section below.
You also run the risk of simply not getting what you asked for, since nobody in Engineering understands what was requested.
This is not to say that you won’t have an additional need for summarized requirements — boiled down to bullet items describing the business benefits — for distribution throughout the organization, especially to the sales reps. But this situation calls for a separate document, not the self-same instructions covered in detail with developers.
What If It’s Too Much?
The second pitfall is overkill: too much detail, with suggestions and even guidance on how to store and manipulate data. If you’ve got lots of creative ideas and have even learned how other products fulfill a capability you are requesting, you will be tempted to do this.
But this effort is largely futile. You wind up boxing programmers into a way of doing things that isn’t as efficient as the one they could find, given their motivation to save themselves time and complexity. Or you end up wasting time writing up details that are quickly overridden by better ideas from the people who know better than you how to code.
There is another version of overkill. This comes from an insistence that features and capabilities be laid out in great detail, so that programmers require no judgment calls to do their coding work. I believe this only encourages a rigidity and dependence on the part of programmers that you want to move away from in this market where development cycles are ever shorter and new enhancements must come out ever faster if you want your product to keep pace with the competition.
Empowerment: Your Best Friend
In the end, if you can fully hand the how part over to programmers and engineers, you as Product Manager — and the organization as a whole — benefit from the flexibility and initiative that develops as a result. By providing good requirements — clear indications of what you want — you provide the fuel that feeds the software development engine at your company. But once it has the fuel, it remains that engine’s job to propel the product forward powerfully and steadily.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]