Search This Blog

Wednesday, April 11, 2012

Product Managers, know your Requirements

They keep flowing in, they are everywhere and all of them come as top priority request or in just do it mode. On your phone as SMS, in your mailbox as subject line or at office lobby as a passing remark from your favorite colleague . I am talking about requirements. Requirements are mostly heared outside board room, sales calling me & ops yelling at me. none discussed in a weekly meeting or in any other forum. Recently over a coffee table discussion I learned that this from a product manage friend of mine that this is fast becoming a culture elsewhere as well, product managers and product owners often complain about this sudden bomb dropped from nowhere and  how it changes their planning, thinking & positioning. More over timing of such ‘sudden death’ requirements is always questionable, don’t know why but they typically comes in mid of a sprint.

To avoid getting upset and maintain my cool, I categories each requirement in following categories and then decided on how should I react, or do I need to react at all. Know your requirement to determine its true worth and priority.

Product Managers know your requirements

Increase revenue: does this requirement in any way opens up opportunity for newer sources of revenue or increase revenue from existing sources? If so WHY NOT JUST DO IT. Yes do it but these requirements need to be discussed with other stake holders as well. These are largely strategic initiatives so don’t get worried when you get an SMS feature request for such requirements. Just reply back that these are to be discussed first in steering committed or product council before I take them on in such a short notice. Remember all that glitters is not gold.

Reduce cost: does this requirement in any way reduces my cost to deliver (in terms of $s) product or service that I am owning? If yes it should be discussed on priority with stake holders. Call for a discussion and discuss proposal, appreciate the initiator and take a balanced decision on taking a hit on release. Remember $ saved is $ earned and this is good opportunity.

Enhance productivity: does this requirement in any way simplifies my standard operating process (SOP)? Will this in anyway improve productivity of users and in-turn saves some cost? Can I count on hours saved to deliver a service or product, if yes this requires thorough discussion with operations and sales team before taking it to executives. Do not panic but take them seriously as they too are linked to cost saving. Remember in a bid to simplifying SOP you may unknowingly cut on a critical corner, so subject matter expert involvement becomes important.

Competitive edge: Yes this is important but may not be urgent. They help sales talk strongly & win better. These are largely new feature request and you as product manager should be ready to turn it down mid sprint saying, ‘good features, little late in this sprint, let’s put this in backlog and prioritize it for coming sprints’. Remember, for sales they want everything YESTERDAY.

User experience: Think through such requirements thoroughly, if a requirement falls in this category take them on top priority because not addressing them may result into losing an existing customer. Your user may or may not get your future releases, simply because their company is not ready to take that cost. So it’s never next time for improving user experience, do it in current release and make sure all your user gets improvised experience. Remember getting a new customer is 10 times more costly than retaining and existing customer – JUST DO IT.

Technology innovation: Pass this on to your CTO or innovation teams or to senior folks in R&D / engineering. Technology innovations are tempting but may not always make good business sense. Get a prototype done first and establish confidance and than draft a comprehensive business case for such requirements. Once again these are strategic initiatives that you just cannot hurry on simply because it was told to you in car park as top priority urgent requirement / innovation. Remember innovations requirement are important but  mostly not urgent.

Pain points: These are common cribs from operations / customer care which may or may not impact sales. Everyone wish to simplify complex part of their job and there is nothing wrong in talking about these pain points. But once again, take these to product council or equivalent forum in your organization. You have limited resource and what make most sense get most priority. Remember, pain points are put emotionally and product manager must not let emotions overrule prudence.

So next time you get a phone call, SMS, a mail with subject line as requirement or a running in colleague, simile first because you are not going to take these words on their face value but instead categories these requirements, decide course of action and prioritize these requirements.

Prioritizing requirements has always been challenging so is working with various stake holders and customers. In an ever daunting world of ‘my request first’ a product manager often finds himself in a situation where no one is happy and all are complaining. But that’s what I guess you are hired for, face the challenge and do optimal resource utilization. Forget situations, keep emotions aside and focus on what is being asked - ‘feature request’. A product manager must first validate the authenticity of the need prior to dropping this request on roadmap. Once authenticity is established prioritized requirements as discussed above.


No comments:

Post a Comment