As your company gears up to start the next software release, a Product Manager reaches the point where carefully crafted requirements are ready to submit to the Engineering team. The Product Manager holds a long meeting with Engineering to review each and every requirement.
Holding this meeting feels a lot like watching the beloved little lambs you have shepherded so carefully all go marching off into the slaughterhouse. It’s as if each requirement were scrutinized, chopped up into little pieces, and swept into the trash one by one. But like Darwin’s natural selection process, this is an event that, while sometimes cruel, leaves the strong still standing to survive and thrive.
The trick is to understand that like natural selection, it’s, well, only natural that a lot of the ideas you propose won’t make it to the high priority pile, and from there to the product development plan. Read on below for a sampling of what gets said as requirements are debated and given the thumbs-up or the thumbs-down.
[private]
“That’s Easy!”
This is one you want to hear. You may propose a new feature with some trepidation, because it sounds difficult. But an engineer, upon hearing what’s needed, may pleasantly surprise you by explaining a simple and elegant way to make it happen.
“It’s Not As Easy As It Sounds”
This is the response you dread. A seemingly innocuous addition, like a Confirm button, could be complex and time-consuming due to architectural, data or other considerations. You’d be surprise how hard some features are to put in the code, when they sound so basic.
“There’s a Much Better Way to Do It”
It’s important to understand that in your role of Product Manager, you want to focus on what, not how. What you want the software to do is your domain. How to get the software to do that is largely in the domain of the engineers.
So don’t get too hung up on how a certain feature could be implemented. It never hurts to throw out a few basic ideas in a brainstorming kind of way, but the best response is one where a developer proposes an easier, better way to add a capability.
“That Depends”
One of the more complex aspects of choosing which requirements make the cut is understanding how requirements depend upon strategy and other requirements. As strategy is debated and changed, whole sections of requirements can drop down to low priority, or rise to the top.
For example, you don’t need a feature that tracks government regulatory approval status if your company decides not to go after a regulated market. Conversely, if you know you must first have the new functionality to break into the market, this seemingly tangential requirement may be crucial.
“We Can’t Do That”
Can’t means a lot of things. It can mean that people aren’t willing to. It can mean that people believe it’s impossible because they haven’t considered an alternative way to get it done. A phrase like that definitely warrants an extensive, probing discussion in response, with a good dose of challenging questions.
“We Have to Do This”
“Oh, and why is that?” should be the first thing out of everyone’s mouth when someone says something has to be done. That may very well be so, but it’s worth clearly defining the what, in case there’s a better way how to do it. Or in case it makes you realize it really isn’t a burning priority.
Sacrificial Lamb
Some requirements are just going to get the axe, no matter how attached you are to them, during the give-and-take discussions. What can I say, there are just some little lambs that have cleavers with their name on it.
Sometime it’s worth knowingly slipping in some sacrificial lambs, requirements that you can give in on as part of the overall negotiation of priorities. By giving in on these ones that you didn’t really want that much anyway, you can ask for other priorities in return, ones that you truly want.
Burnt Offering
As Product Manager, you might want to make sure you include pet requirements of important departments or individuals to help build goodwill and get their support for your own pet projects. Plus, you can step back and not be the bad guy who kills the idea, letting someone else play that role instead. You can even play the champion who strongly defends the idea (but unfortunately you fail), getting an ally squarely in your camp as a result.
Survival of the Fittest
In the end, you can rest assured that only the fittest requirements survive for the most part. Though realistically, it may take a couple of releases before some of those weaker requirements finally kick the bucket. The result is a good solid product that has been vetted by people from several perspectives: business, technical, marketing, finance, sales, and management.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]