Search This Blog

Showing posts with label escalations. Show all posts
Showing posts with label escalations. Show all posts

Monday, November 21, 2011

Interviewing a Product Manager


Abstracts from an interview of a candidate for the post of product manager. Feel like hiring him, though not after my manager gave me staring looks on this candidate. Interesting interview conversation though.

Your experience is largely into Project Management. What convinced you to change your career path?
Yes – I have done project management for 8 years now and I happened to visit product camp in Bangalore, I guess it’s called pcampblr after which I thought it was good to be in something less pressing job. So I requested my VP and they agreed to move me to Product Management department. So for over last one year or more I am doing product management for the same product that I managed as Project Manager.

Interesting , though not fully convinced. And you are liking the job?
Yes – I am.

How different is it from project management?
Well somewhat. As project manager I was involved in full deliverable cycle, now I just author requirements, explain them to engineering and then I am busy attending customer calls and sales calls and escalation calls.

So you do not actually participate in engineering process?
Occasionally I join bug reviews and answer mails from engineering.

What’s the most interesting part of your profile?
I learned this at pcamp that product managers are owner of product something like CEO of product line they manage. I like to be a CEO someday and really feel I am one right now for my product line.

Interesting and what is one thing that you would like to change about product management?
I read lot on Product Management on web, blogs to be precise. Really feel that the role of product manager is not understood by people across the community.

Oh! Wow. Which blogs do you read?
Many, I remember few though. onproductmanagement.net, crankypm.com, blackbolt, the rich mironov and few more.

And what’s so confusing about the job?
I see many people drawing the circles overlapping like that in Venn-diagram, circles are marked sales, executive, engineering and the overlapping area is Product Management. And then there are circles which has Engineering, UX team and marketing and overlapping areas is Product Management. Are product managers just in those overlapping areas? I thing we have our own circle, part of which is overlapped with engineering, part with sales, part with strategy and part with project management. We are lot more than those overlapping areas.

Interesting thoughts. Let me understand how do you prioritize features and bugs for engineering? How does your prioritization matrix looks like?
Nothing rocket science in it. Do what sales and customer support is most cribbing for, rest designing matrix and putting weights against each item is like waste of time. Actually we never get a chance to think so much. On most occasions sales people would have already committed something on behalf of the organizations and then all department heads come running to us and I am left with no option but to get that feature or bug fix deliver in current release or worst case in patch release. It never goes to next release, all project planning does not hold good here.

I thought you wanted to be a CEO and learn how to negotiate on such critical things.
As a CEO I would rather prefer to focus more on business strategy, board of directors and mergers rather worry about what features goes in when. I thing I am doing right by not putting lots of time on which feature and when.

Good. So why are you looking for a change now? You are just little over a year’s experience in Product Management, maybe you may want to continue and get some real good insight of the role and then plan to move on.
I guess it will not help. Product managers job is great and if I stay back I will just repeat my experience. I rather move on and understand different products and business models before applying for a CEO’s post. Staying for long on a job as product manager will not help me grow faster, after all release after release its same stuff.

Great. Have you worked in agile methodology.
Yes and I like agile.

What’s the best part of agile?
I do bare minimal paper work, attend scrums as and when required which allows me to focus on customer care and sales meet, where I spend my most time. Agile really makes me free of unwanted silly documentation. Beyond this, it’s just another way of saying engineers, ‘Please deliver it fast and good’.

Good. Do you have any questions for me.
None. I always have answers to questions and never let any question remain open for long for others to answer.

Thanks for your time. We will get back to you.

Saturday, September 19, 2009

Escalation that wasn't

Escalation that wasn't - is a false alarm. Raised by customer and escalated by friend’s next door (customer care) to top executives as business critical bulge. This falls as lighting on engineering, who then keep aside all planned activities to look into this. Although engineering maintains limited buffer for such unplanned activities, and most of the time ensures release on plan but lighting like this leaves certain impact that results in loss of productivity, compromise on quality or if nothing else then at least causes distractions from roadmap. And worst, engineering assessment of escalation is a known limitation or a known issue with version that customer is using, probably an workaround solution is already covered in release documents.

While engineering may struggle to find an answer to such situations, it is up to the Product Manager to minimize such distractions. The mystery of escalations that wasn’t is solved by ensuring proper programs on educating the users (end user, Tier x support, marketing, and customer care) on product usage. So how different it is from regular NPI process. Why and how could this objective be achieved?

Well, the training (as part of NPI or independent process) is largely held either during a product launch, or when a new deal is signed / renewed or on could be on customer request. Most of the times these trainings have contents like videos, audios, large documents etc which probably are never referred again or simply not good enough to highlight Do's and Don'ts or Is, Is Not of the product usage. Emphasis on trivial things gets lost in understanding the solution set.

Educating the users (periodically) has two very important advantages;
  1. It reduces pain points for engineering
  2. It improves the product image

Some of the ways to ensure proper product usage or educating the customer could be;

Insulate Installation:
Make software installation more robust. Let the installer be intelligent enough to check for exact pre-requisites, eg Service Packs, specific driver version etc. and conflicting application, if any.

Product tips on login:
Customer should be advised with tips as and when he/ she logs in to your application. Such tips are optional and can be turned-off by user. So you as a Product Manager need not to worry of customer complaining of annoyance.

Quick reference note / do's and don'ts:
They are available on end user machine and can be popped through your application on a single click. Whenever a user hits an issue / error situation, he gets a pop asking to refer specific section in help file or a release document.

Bench marking:
Eg. The software takes 60 secs to launch when connected to internet and 30 secs when your computer is not attached to a network. Such benchmarking helps setting the right expectation. These are important as they directly impact the user response behavior and product image. They also improve moment of truth for your product / service.

Escalation tools:
Ensure that you have clearly defined escalation path. Escalation is accepted only with some bare minimal information such as OS flavors, Service Packs, logs, registry information etc. Make your tools validate the escalation content first before it goes to top. For eg. Software ver 3.5 is certified only on Windows XP and Mac while software version 4.0 is certified on Windows XP, Vista and Mac. Now if an escalation is raised for 3.5 on Vista the tool manages on its own.

You as product owner can possible think of more and better options to manage such escalations. While whatever may the method be, Product Managers must always remember that your users (customers) can be your best salesman. Educate them and keep them informed on regular updates.