Enthiosys shares an interesting article concerning agile product managers and product owners. Of course they are painting a somewhat »ideal world«™ or at least a product manager under ideal circumstances. Real life, however, is much more complex as their article admits.
As a product manager, you might suffer from limited resources, both in terms of capital and time. Maybe your controllers think that it is worse enough to pay your salary and just a waste of time and money to let you do your job. If you think that they pay you in the hope to get a multiple of the investment out of your work, you might be wrong. Sometimes you may feel like a car whose owner saves the money to buy some petrol. If the car has good luck, noone will blame it for the missed chances.
As a product manager, it is part of your job to analyse the markets of your products and to get an understanding of the needs of your customers. In the software business, if you managed to grow a great product and a solid user base, it was best if your users all desperately are waiting for the next update and buy it immediately as soon it is available. In this case, the cash just was flowing in without much further individual interaction.
If you want to get as close to such a situation as possible, you need to add features to your product which are valuable for your customers. To achieve this you need to talk to customers (if possible, face to face) and to observe them while using your product. This is a very expensive task. Quoting the aforementioned article:
It’s the Agile Product Manager’s primary job to meet customers/prospects face-to-face and deeply understand what they want.
Especially the second half of the sentence is an important one. If you do not resist the requests of your sales guys, it is likely that you will create a product that does not fit your market well. A conversation between a sales guy and a product manager might look as follows:
»I need a checkbox in this dialog that reads as foo and does bar«
»Can you tell me what goal your prospect wants to achieve?«
»Errr, stop asking questions. The users want to have this checkbox!«
If you really want to know your audience, you need to invest resources. If this results in an internal discussion about travel expenses and a backlog of your daily work (which you likely need to compensate with some extra office hours) and you know your hackers will write insufficient code during your absence because you did not have the time to prepare their job beforehand, it is likely that your afterbrain tells you to better avoid the extra stress. It’s a tradeoff. You stay at the office instead of visiting customers. Your product will not become as good as it could. But noone will blame you for the invisible sales that did not materialize. It’s a loss for the company that pays you, but saves you some lost hair. It’s not your job to decide whether it is a strategic investment to get a better product. That’s the job of your management. If you point them to the right direction but get no feedback at all, it is frustrating to give up. But it’s the decision of your management how much outcome they expect from your work.
Enthiosys probably is talking about some medium sized to major companies. If you are, however, working for a company of 20+ employees, your job can become pretty interesting. Quoting the abovementioned article again:
When executives demand one neck to choke, a Product Manager steps forward.
It’s part of your job to take the responsibility for your decisions. If you have, however, neither the final saying over the features you need to stand for, nor the (human) resources to do them right, you are in a precarious position.
There are two further nice quotes in the article:
Most importantly, the Product Manager represents the customers to each internal organization.
We deeply believe that every single release must have at least one feature (story, improvement) requested by each major stakeholder group[...]
True. It’s your job to feed them all, at least a bit. You have to act as an animal tamer who follows the »Divide et impera« rule. If you are in good luck, you are working for a successful, sales driven company. But as soon as your sales department starts to behave too self confident, you will get fed with phrases like
- »I do not need new features, I’m selling it anyway. So why do you need resources?«
- »I’m not interested in how customers use the product after the purchase.«
- »I only need this feature for presentation issues. It’s not important whether the feature is fully implemented or not.«
Yeah, sales people usually are paid by provision, not by content customers who just order their updates without contacting them.
If you are a product manager who needs all facets of a daily job done, it is likely that you won’t have the power to constantly stand alone against a superiority of a sales armada. But it’s your job to shield your developers as much as possible so they can get their things done right. And if you give up, especially because you do not experience the backup you expected from your tech folks, you just neglect to do an important part of your job.
This expecially plays an important role when it comes to the implementation of new features. If you want to do agile software development, you need to cut features down into small chunks of achievable goals. Be prepared for a release at any time. If it happens, you will be blamed for missing details of the new features. But it’s encouraging if your users are content with the existing code rather than complaining about dozens of bugs in a huge (“waterfall”) feature set. Last but not least it’s your responsibility to reduce the costs for bugfix releases and support traffic as far as possible. Better invest the saved resources in developing small iterations and in testing them.
This also means you need to resist to put new features in bugfix releases. I’ve seen many occasions where we paid for putting (alleged) minor new features into bugfix releases. There’s nothing worse than an interrupt in the next feature iteration just because something went wrong and you need to do a bugfix release for the bugfix release of the first bugfix release.
As a product manager, you are just the man between all and any chairs. It just does not matter if the chair’s name is »customer«, »marketing«, »sales« or »developers«. You get paid for being bashed. Nothing for the faint-hearted. It’s a job for real men :) .
