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.
@mathurabhay
No comments:
Post a Comment