Product End of Life.

Product managers are very passionate about their product. They by their DNA can only envisage success and fame of the product they own. Rarely would you see a product manager  talking passionately about declaring EOL of their product. However there are situations wherein it becomes important to think of alternates, situations where limiting the losses takes higher priority than enhancing product features. Here are few signs of aging product that might be causing similar situation in your organization, and if you happen to observe similar behaviors / patterns with the product that you own than it may be the time to initiate EOL

Monitor Feature Usage

Exploring user usage data to determine what he/ she is liking and valuing is of great importance for a product manager. User data helps in knowing what strategies are working and which needs to be re-worked upon. Importantly, inputs from user usage data may also influence product road-map in a greater way as it is direct input from users to product owner. 

User usage data will help a product manager in knowing;

• who is using feature, and when (time, circumstance etc) is he using them.
• most commonly used features and least used features
• is this feature being used for the purpose it was designed for? 
• feature combinations used
• duration for which software is used for
• how often user visits helps page and what content do they search for in help files
• abnormal software exit

....and many more similar questions that a product owner or product manager is expected to answer.

Product Managers: Time to Move on

Product managers must plan out career roadmap for themselves, and one of the most important aspect to this roadmap will be, when to move on from current job to next. This cannot be an emotional decision but definitely a decision derived from your vision for yourself.

When I decided to move on a year back, two most daunting question I asked to myself was , “Why should I move on?” and “Why should I stay?” And today nearly an year after that decision, I can confidently say that points that helped in taking decision were real strong and I made the right move.

Factors that influence such decision change and today when a close friend of mine sought my opinion on moving on, I crafted factors that helped him in taking decision for himself. These are not the only factor but these definitely are very important if you are seriously thinking about moving on. These factors change based on trends, technology & time so please do take a note of this that they have a expiry date that you will determine over period of time.

Move on if 3 or more of following 5 holds true for your:

In-bound role (Stuck in development center): I spent around 75% of time with engineering team, rest in meetings with key stake holders and very little in market place with customers and studying trends and competition. My organization is happy with my performance and they want me to continue in same fashion for coming quarters.

Cloud solutions (No Cloud No Rain): I do not see any opportunity to drive a cloud base solutions in next 6 to 18 months. My product roadmap continues to embrace philosophy of desktop solution and management is not keen to take any exposure on cloud solutions.

Focus (cost cutting will not increase revenue): We are working on features & process that will help company save operational cost. Most of our features are around reducing cost to deliver. We are not talking about increasing revenue or seeking out opportunities to increase revenue. Bottom line and not top line is what the focus is on.

Apps (they too are serious business): My company believes that Applications on Smartphone, Tablets and other smart devices are for fun & leisure, they really do not mean any serious business. Investment in such technology offers no good returns.

Thought leadership (who is on driver’s seat?): We deliver what sales pushes for or engineering believes we should. Sales & Engineering influence our roadmap most and we do not really waste time doing lot many research, market study, competitive intelligence etc.

Success of a product manager depends upon character that he/ she builds over time. This includes strong decision making ability for organization and for self. Read Not now, not ever – by @vivekv emphasizing exactly on how strong you need to be.

@mathurabhay

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.

@mathurabhay