If you have ever watched people playing on the tennis courts, you see two, or four, players in a game, actively running around and hitting a ball back and forth. Many rackets, one ball in the game.
Have you ever taken a look at the edge of the court? There are tennis balls, lots of them, scattered around in little clusters all around the outer edge. All through the game, when someone misses a ball or serves one out of bounds, sometimes the ball ends up so far away that the players just go get another one from their bags. Before you know it, everyone has lost count of how many balls have rolled off.
That’s what it’s like at a software company, too. Only the players are developers, and the balls are requirements. In the heat of the game, with deadlines looming and tasks to complete, requirements get cut, skipped, or forgotten. They roll off the playing field.
And the person who is best positioned to notice those many requirements that have been left for another day is the Product Manager. If you ever wanted a snappy and memorable definition of a Product Manager, it’s this: “The Product Manager is the person who makes sure that the requirements don’t get lost or forgotten.”
Read on for a discussion of how Product Managers can play a vital role as the Requirements Police, making sure that important requirements are not forgotten.
[private]
Why Me? Why?
Tennis matches have people, often children, who are in charge of collecting the stray balls. If the prospect of being the equivalent of a ball boy at your company makes you feel offended and unappreciated, you’ll naturally find yourself asking why such a menial task has to devolve to you.
But requirements are one of the very few pieces of the product that a Product Manager really owns. And you’ll be hard pressed to come up with any other role in the company that has more ownership of requirements than the Product Manager. So this sometimes thankless, often unappreciated, and definitely unglamorous task falls to the Product Manager.
Plenty of other jobs have their equivalent. The Marketing professional who has to go verify the color proofs for typos and quality, the sales rep who goes and fetches the coffee when his prospects for a multimillion dollar deal arrive for a meeting, the developer who has to do a search-and-replace of a field name across dozens of files. Think of this as one of those small but meaningful ways that you can be useful, instead of wondering why nobody else thought to pick up the dropped ball. They were busy coding, selling, and hyping the product.
The Trail of Cut Corners
There are a few common reasons why requirements wind up getting set aside during development. But mostly it’s a matter of saving time in order to meet deadlines and get projects completed. A specific requirement may have a dependency upon a business partner or an embedded technology that isn’t ready. Or the requirement may take as long to implement as four other requirements, and it’s easier to let it go for the time being. Something that sounded good in theory doesn’t turn out to be practical given the current state of the product. A few examples probably come to mind.
But as things are dropped and shortcuts are taken, you wind up with a whole lot of cut corners piling up. If the Product Manager doesn’t keep track of them somehow, they’re likely to be forgotten.
One method for keeping track of these cut corners is for a Product Manager to keep a list of them, like you keep a list of requirements. You could make a special category of requirements that get reviewed first when the team sits down to discuss and prioritize capabilities for the next release. By coming up with a special category or status such as Revisit or Incomplete or Deferred, you help them stand out when busy developers have to make hard choices to drop tasks and assignments.
Of course, ideally, you as Product Manager are involved in the decisions that are made to drop or defer a requirement, or a piece of one. But even if that’s not the case, encourage the entire team to flag such decisions and submit them to you so that you can put them on the list.
The Latest Is the Greatest
Often, a requirement was championed by one or more members of the team as essential for a release. But when it doesn’t make the release, when the next release comes around, nobody is suggesting it any more. There’s a whole new list of requirements. My, what short memories people have!
It’s not uncommon for the most recent suggestion by a customer or important member of the management team to be the top priority on the requirements list, simply because it’s fresh in everyone’s mind. That’s when it’s important to revisit the full list of requirements and remind people of what a high priority they gave to a given feature just one release ago. And if a capability was important enough to put in the product, the piece of it that got left out because of time constraints is important enough to review and consider again.
If the Product Manager doesn’t choose to have a long memory when it comes to requirements, chances are nobody else will.
We’ll Make It Part of the Standard Product
Here’s a situation you have probably encountered. An important customer or business partner pushes for a new capability. You agree about its significance, and want it as part of the standard product. So you start to develop it for the next release. But to accommodate the capability in the standard code, there are technical issues that necessitate rearchitecting work that you don’t have time for if you want to make the release. So you compromise. You create some custom code “just for now.” You’ll incorporate it all into the next release.
It’s a decision made quickly under tight deadlines, and you don’t think about writing it down on a list like a formal requirement. You’ll follow up for the next release.
And when the next release rolls around, the team is calling for a whole new list of capabilities, features that are fresh in everyone’s mind from the latest meetings with customers and prospects. The loose ends that weren’t tied up in the previous release get lost in the shuffle.
Next thing you know it’s six months later and a feature that a customer thought was standard turns out to be custom code, still. Your next release is due out, and that custom code hasn’t been upgraded. Somebody’s going to be surprised!
We’ll Do It Next Time
There are lots of cases where a portion of a capability is recognized as important, but you realize midway through development that it just can’t be fit into the schedule. So you put it off. It’s just a piece of the overall requirement, and not worth holding up the whole effort for that one part.
But so often the dropped functionality falls into a black hole and is never heard from again. I guess it’s just human nature to forget. There is no formal process to track such issues, and a year later, your customers are giving you flak for not having the capability like you said you would.
Not So Important After All
Not every requirement that gets deferred or dropped has to be put into the product later. It can also be a useful tactic to drop those parts of a requirement deemed nonessential – preferably deemed so by a focus group of customers when they review the product developed so far. So many times people are content with the product without those extra features, and nobody is clamoring to include the pieces that were eliminated earlier.
Sometimes the best way to determine whether a proposed requirement is truly a high priority one is to let time pass and see how enthusiastic people are for it after three months, six months, or a year.
Forgotten, But Not Gone
When developers are busy and working toward a deadline, they need to be able to forget the requirements that were dropped. Most of the team will forget about them. But the Product Manager must not forget. Keep them on a list and bring them up as the first thing to review for a new release.
Like A Broken Record
One of your roles as Product Manager is to be the broken record, the person who keeps reminding people of capabilities that were delayed, cut, and forgotten. Sometimes the only way to be heard is to repeat yourself, repeatedly.
Many people resist the idea that they have to repeat themselves. They ask: “Why should I have to say something again? Why don’t people just remember?” But the fact is that everyone’s busy, and the many corners that were cut are probably most important to the Product Manager, who knows why the capability was requested in the first place.
One of Your Proudest Moments
When you put a system in place for dealing with the dropped balls and cut corners, for tying up the loose ends in the next release, the software winds up appearing more complete and of higher quality.
Often the details of who remembered a forgotten feature – that would be you – will be lost on the team. Yet some of your most fulfilling achievements as a Product Manager may very well be making sure that capabilities were completed as you and your customers initially intended.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]