21st Century Product Manager
Posted for June 2nd, 2010
What are some of the more puzzling job titles that you hear when you meet someone in a networking event or casual setting?
When someone tells you that he or she is a Product Manager, do you give him or her a look of recognition, or provide a polite pause to allow your new friend to explain what he or she does for a living?
In this article, I offer to prepare you for this next encounter by providing a brief explanation of why the Product Manager exists and then describe some of the varying boundaries of this role. I base these explanations on my own experiences as a Product Manager in Financial Technology during the current century and the latter part of the last one.
- Problem of Two Nations Separated by a Common Language
- Span of the Product Manager
- Managing Expectations
- Cheers! (reactions from the front row seats)
Problem of Two Nations Separated by a Common Language
One analogy that resonates with many people is the image of the Product Manager as a bridge between business people and technology people, because these two island nations are separated by distinct cultures and dialects.
For example, if you want to have some fun, bring together a group of business people and technology people and ask for definitions of selected business acronyms and words (Not that this would be the most fun idea you could envision). For example, consider CIO, client, and clouds. What do these words mean to you?
Guess which of the following definitions belongs to which nation:
CIO
- Chief Investment Officer – Senior executive at an investment organization who is ultimately responsible for all investment decisions
- Chief Information Officer – Senior executive who has overall responsibility for the information and technology infrastructure at an organization (You might think that it would be better to call this man or woman the Chief Technology Officer and avoid any confusion, but that’s not always how things work)
Clients
- The people (or companies) to whom a company sell investments or products
- The personal computers or mobile devices connected to a network
Clouds
- Fluffy moisture-laden forms in the sky that produce rain, very bad to see if they are dark and you are taking the CIO or clients out for golf or other outdoor events
- A network of shared computer resources to which clients can connect
If the only gap between nations was the definitions of a few words and phrases then we could provide translation guides to minimize the communication problems and maximize the productivity during meetings between the two groups. However, there are larger issues of culture and perspective. Generally, the business people are focused on bringing in new revenue. They are not interested in the details of how clouds and other infrastructure work, but they know what information they need, and they understand the nuances between different types of information and the context of how they want to use this information to help meet the organization's goals.
In the other nation, the pure technologists excel at discerning how to gather, transport, transform, organization, store, and deliver information to the business people. Each technology person may be an expert in one particularly area, such as a database architect or an application developer. However, in most organizations they need guidance to understand the nuances of the information to be put into those databases and applications.
The description above is a simplified explanation of the different perspectives between the two groups, but I believe it gives you an idea of the gap between the groups that has to be addressed in order for the whole organization to excel. In rare cases, the business people and technologists learn enough about each other’s cultures that they can meet halfway. However, compared to last century, the gap has become larger and larger as the knowledge required on each side becomes more and more complicated. Consequently, more often than not, the organization needs a person or team who can facilitate that flow.
This person is known as the Product Manager.
|
The Product Manager connects the business and technology people and takes ownership for the creation and delivery of products by one group (the technologists) that is used by the other (business people). The boundaries of this role depend on the structure of the organization and other attributes of the organization’s culture. A Product Manager might have a very visible and public role, like Google’s Senior Product Manager, Rishi Chandra, who took the lead in announcing and explaining Google TV at the Google I/O event last month. In some organizations, a Product Manager is responsible for the complete life-cycle of a product, which might include the following steps:
A couple of caveats:
This cycle can last anywhere from a few months to years, so I like to remind my clients that the Product Life-Cycle is a half-marathon, not a sprint. Some folks say it’s a marathon, but a casual observation will uncover a larger distribution of people who find the half-distance to be achievable and can relate to it. In the interests of full disclosure, it’s the longest distance I have run in a timed race, so I choose to only speak in analogies that I fully understand. Often times a Product Manager is assigned to work on just one step or one collection of steps of the life-cycle, and then hands off the product like a relay-race baton. If you have watched the speed skating relays in the Olympics than you have a sense of the level of coordination required to make this exchange when you are both moving along at high speed. These specialized Product Managers might be referred to as a Development Product Managers or Marketing Product Managers according to the phase of the life cycle in which they operate. In many cases, a separate Product Marketing team has responsibility for the generation of collateral, pricing and other post-development tasks. In those cases, the Product Manager often collaborates with the Marketing team to describe the product’s features and benefits. |
|
|
In the 21st Century, the Product Manager typically faces pressure to deliver more quickly and at lower costs than in the past, resulting in smaller product projects and the use of distributed or off-shore resources to theoretically keep costs lower. The observation from many Product Managers is that the use of off-shore resources can be effective for very structured situations assuming the existence of thorough documentation or repeatable operations. If an organization wants to rapidly deliver new products and allow for dynamic changes to the plan, as with the Agile method of development, then off-shore resources can be a hindrance. Instead, those organizations are best served by having a single location where the business people, Product Managers and technologists can collaborate. Please send me your thoughts on this topic or follow us on Twitter for future observations on the bridging of finance and technology, half-marathons, and other topics. |
|
Cheers! (Reactions from the front row seats)
Thank you for your honest feedback and suggestions on this topic! "Absolutely loved it! So witty and to the point," says one colleauge who is a language expert in the country of the mother tongue. Needless to say, I was very honored to hear that endorsement. He liked the CIO example and had a funny story of an even more complicated example. Steve, a seasoned Product Manager in Foreign Exchange technology from NYC, generally concurs, "The article is pretty spot-on with regard to my role (at previous and current company)." However, he mentions a couple of events that that we might want to take a swing at: "One point you might want to emphasize is the creation of a business case, and the Go/No-go decision." Thanks Steve - The Business Case exercise is a very important step as it will provide analysis, validation, and documentation of the original idea prior to the Business Requirements definition, and may forecast some rough estimate of a potential return on investment. The Go/No-Go meetings have always been one of my favorite points in a release cycle. For the rest of you, this is the critical decision point where you conduct a "final" evaluation of test results and decide whether or not to launch a product or version upgrade as scheduled. I would say the key to effectively managing that event is to establish a set of criteria in advance of the decision so that a team of experts can be as objective as possible. Another colleague had some painful memories of Go/No-Go deja vu, because we had to rollback a product we had released and had to re-visit the Go/No-Go meeting after we had already 'gone'. The upgrade was eventually released for good and has had a succesful run. "Hey - it explained to me what a product manager is supposed to do," says my friend Chuck on LinkedIn. I will be sure to give him some easy shots to poach the next time we play tennis. Thanks! One last comment, from Vince, a respected member of that sparse group of data and technology experts who have worked in both nations (business and technology). Vince says the article was "well thought out and well written..." Please keep sending your thoughts and ideas. |
|
