I had a presentation today for a whole bunch of people. These guys were from all over the company; implementation consultants, service desk employees and sales people. When you think about that is a fairly diverse group of people. As I was standing there taking the usual abuse why we didn’t do this or that, I came to realize how many stakeholders I actually have, and skewed my time table is, considering who I spend my time on these days.
These days I spend a lot of time with development team in Manila. It is a group of very talented developers and testers, but since they have no experience with this kind of application, we are spending a lot of time attempting to transfer the necessary knowledge. Unfortunately that means that I have neglected my usual stakeholders. So, just for the fun of it I decided to use my Friday evening on making a diagram of all the stakeholders I have as a product manager. I know I need a life, but be that as it may, you can see the diagram below.
I know I should have made a Visio diagram, but even I have my limits, especially on Friday evening. So anyway, what does this over simple drawing show? Basically, it shows that top management wants to develop some kind of feature. It can either be to position the product in the market or to live up to contract requirements etc. Normally, product management would have a pretty big say in these decisions, considering we are supposed to know not only the application but also the market, the users and the competitors.
Firstly, we need to coordinate with the development department. How are we going to solve this issue? How does it fit with the existing code? These discussions are usually quite iterative in nature and result in a specification, which in my case is a user story.
And this is where I believe the flow must never stop. If we are to really capitalize on our investment in the product, we need to tell the sales force what they are going to sell and why. We need to tell consulting how it works and how it is implemented. We need to tell operations how to support this new feature and finally we need to provide input to marketing about what they should say to the market.
All of these tasks make product development a complicated task, because even if the arrows above only point in one direction, they should also go the other way. Most departments have requirements to our product. It should be sexy, so it is easier to sell, it should be robust so it is easy for operations to support it etc. And this leads me to the point of this post, and the point is that perhaps the most intricate part of the PM’s job is to ensure profitability on the products. We derive profitability not only from the top line, meaning revenue, but also by ensuring that the software and services we create are easy to work with so the organization does not need to spend a lot of resources in order to make this thing work. This also means that, at least theoretically, that it will be more profitable to say no to the customer, if they request a feature we cannot sell to other customers, or that the operations are too high or even if we move beyond our product domain. Not exactly a popular opinion among all people, but nevertheless an argument I fully believe in.
If we applied general systems theory, we could draw a diagram of subsystems that are intertwined and together form the basis of our return on investment.