When asked to comment on whether managing an internal-facing licensed application is like managing a product, I put myself into the situation of someone being asked to do this. . . which created the following "internal dialog":
“Hi, Bob, we’d like to talk to you about a product management position.”
“Terrific. Tell me about the problem the product solves in the marketplace.”
“Well, that’s a problem, because the product isn’t something we ship to customers. It’s an internal tool we license and use that helps us create the solutions we bring to market.”
“So who are my customers?”
“Our IT department. Oh, and you too, since you’d be living in IT.”
“So I’m not just the manager, I’m a user?”
“Yes.”
“Interesting. So why do you think you need a product manager?
“Because we need to balance the needs of multiple and often competing stakeholders who have an interest in what the product does.”
“And. . . as a user. . . my needs would be competing with theirs?”
“Correct.”
“Who does the development of new capabilities?”
“The vendor does.”
“And they’re balancing the needs of multiple and often competing stakeholders who have an interest in what the product does too, specifically all of their customers.”
“I guess that’s right.”
“So I can’t have any confidence that specific feature enhancements or bug fixes that our company needs will be addressed by the vendor.”
“Well, we do pay maintenance.”
“That doesn’t generally give you the ability to prioritize or force features or fixes.”
“But they’ve been very responsive.”
“I’m sure they have. So let me ask this - when you say that the job needs to balance multiple and often competing stakeholders who have an interest in the product, that refers to how the product is configured for use, and the sequence of how those configurations are integrated into the product, right?”
“That and more.”
“Would the ‘more’ include planning, definition, analysis, design, development, quality control, release, utilization and maintenance of the product?”
“Why yes, that’s a nice way of putting it.”
“OK, here’s what I’m thinking. This is a great job for an experienced IT project manager who would like to learn to be a product manager, because it requires a lot of the techniques and skills associated with being a product manager. Understanding the needs of a target market, prioritizing how you serve that market, those are PM disciplines. But the logistics of managing all of the various phases of how the application is customized. . . that’s a project management job.”
“So what do you recommend?”
“Find an experienced IT person in your company who knows the application, is a tested project manager, and introduce that person to the idea that they will be the product manager of this tool. Treat it like a product that would go to market - look for the biggest return for time invested, find out how each incremental release will align with the strategic direction of the company.”
“I think we have someone like that here already.”
“I don’t think you need a full formal PM process - just a mindset that this person is the repository of the voice of the customer, and that this person is going to be more than someone who owns the project plan. Just be careful to imbue the role with authority, so that all of the people whose interests this person needs to balance know that he or she is the ‘owner’ of the application. It’s that sense of ownership that makes someone a PM.”
“So why don’t you want the job?”
“Because the product itself is not market-facing, and because the company can’t control the resources who work on the product beyond configuring it for internal use. To a PM, those are two big strikes.”
“But you think that taking a PM approach towards managing it internally is a good idea?”
“It’s a great idea - but only if you staff it with someone who is also a capable project manager with an IT perspective on how the product will be used internally.”
"Thanks for your time, we have a lovely parting gift for you."
"You're welcome. . . . and thank you for the ham."
No comments:
Post a Comment