As I returned to Atlanta from Barcelona this week, I had the pleasure of experiencing Atlanta's new international customs area. If you haven't been through the new terminal yet, it is truly beautiful. It is lined with great art that is educational (floor to ceiling stained glass reflecting slide views of wood veneers) and promotional (photos of many of the places in Georgia). Glowing ceiling lights illuminate the tunnel on your way to customs while soft zen music plays.
What made it a product management moment was the division of customers. (I use the word CUSTOMERS although I don't know that USCIS would every think of us as CUSTOMERS- that's a different blog.) Individuals entering customs were divided into two groups, those connecting through Atlanta and those with Atlanta as a final destination. Those of us with Atlanta as a final destination had the pleasure of using the new customs area, those that were connecting were shuffled to the old E terminal to connect to their flights. Of the 92 Million passengers that travel through Atlanta at least 2/3rd of these passengers are connecting passengers. So the majority of visitors to the Atlanta airport will not experience this beautiful new space. This reminded me of many a software practice where software is released, but under circumstances in which only a handful of customers can take advantage of it's features or version.
As product managers we are the owners of our product roadmaps. Too often though we allow upgrade and migration requirements to fall to the bottom of our requirement priorities; opting to focus on getting new and exciting features to market first. Developing a strong upgrade process for new releases requires planning proper development techniques, the right architectural approach and investment in solid upgrade utilities. It also requires the dedication at at difficult time in the development process, usually between a first and second version when we are often faced with an enormous backlog of requirements from the new market. As owners of SaaS products, this upgrade strategy becomes a must. When we OWN the environment for our customer's software without an upgrade strategy that brings our entire customer base to the new version in a flash cut, we are increasing our companies overhead exponentially by version. Version proliferation and technical debt may not seem daunting initially, but with a quarterly and/or monthly release schedule the costs quickly add up.
Therefore good readers, I recommend that with any green field development you begin your upgrade planning with release one and lay the foundation early. If you haven't developed such a strategy and look at your portfolio and see a string of versions and (server farms) its time to hit the pause button and execute a strategy to consolidate.
Saturday, July 14, 2012
Thursday, July 5, 2012
Formulaic Job Descriptions - the product manager
I am currently working on a project which attempts to apply a value chain approach to the decisions, management and evaluation processes that are applied in the Human Capital Management arena. I am not "going gentle into that great night" as I am heavily armed with the research and mounds of ideals from one of the best know analysts in this space Naomi Bloom.
As I started my work this fine morning around 6 am, armed with a diet coke, something in the research gave me pause. The idea that developing, maintaining and evaluating organizational components is a strategic task. Now, if you ask most big companies, they will proudly show you their compensation and classification studies that they paid someone in the industry handsomely (a Hewitt or a Mercer) to develop for them. Nine times out of ten, I'd bet that the investments was predicated by a decision to avoid legal woes in the future and the other one time, it was because a Human Resources executive saw the task for what it is a daunting undertaking. I don't know that I ever really thought of this excruciatingly detailed task as strategic though.
When I poured through the sub tasks of creating job descriptions, position descriptions and assigning competencies though, I had my 'ah ha' moment. This is one of those tasks in life that while daunting and fraught with detail it is STILL strategic because it lays the foundation for organizational success. It reminds me of some friends that decided to build their own home (using a subcontractor of course). Every morning he would travel to the job site and watch the workers build the foundation of the house- this puzzled me. In response, my friend said, "I know if the builder screws up the foundation the house will never be right. So I feel it is important for me to be there through every step of the foundation."
I further pondered as to how this applies to the field of Product Management. Often, the Product Manager is asked to take on the position of Product Owner or Product Manager because of their knowledge of the product. Sometimes, as in my case, because they have strong project management skills and can deliver technology to their clients on task and on time. It is often this lack of clarity to the position description and the supporting competencies required to move the appropriate 'levers' on the job that make us Product Janitors rather than Product Managers. Additionally, we often do not take on the third verb in the sentence EVALUATE as the product lifecycle changes for a product.
As products mature, sometimes we leave those start up superstars behind- nursing a growth product into maturity. And to the opposite, sometimes we don't recognize that the competencies that are needed to bring a product to market might not be possessed or at least might not be as strong in a product manager that is successfully managing a mature product line. For example, during a conversation I had at SHRM with a peer in the industry who was struggling to find the right resource to join her team, I challenged her to look within her own team. One of the offerings that they manage is in a growth product cycle verses others that she is hiring for which are in 'introductory' and 'fix' cycles. Why not move the superstar from growth to introductory; they were the catalyst for getting the Growth product through it's introduction period.
All of this thought brought me to the same questions for our profession- How often do we include the step of evaluating the competencies required for the job at 'that' particular point in the product AND market life cycle for the product managers we manage? Are we thinking about these like a solar system with products orbiting their markets and the tilt and rotation of the product life cycle exhibiting gravitational pull on the required competencies of the job? Do we actively account for and apply individual strengths against specific market needs for that time?
As I started my work this fine morning around 6 am, armed with a diet coke, something in the research gave me pause. The idea that developing, maintaining and evaluating organizational components is a strategic task. Now, if you ask most big companies, they will proudly show you their compensation and classification studies that they paid someone in the industry handsomely (a Hewitt or a Mercer) to develop for them. Nine times out of ten, I'd bet that the investments was predicated by a decision to avoid legal woes in the future and the other one time, it was because a Human Resources executive saw the task for what it is a daunting undertaking. I don't know that I ever really thought of this excruciatingly detailed task as strategic though.
When I poured through the sub tasks of creating job descriptions, position descriptions and assigning competencies though, I had my 'ah ha' moment. This is one of those tasks in life that while daunting and fraught with detail it is STILL strategic because it lays the foundation for organizational success. It reminds me of some friends that decided to build their own home (using a subcontractor of course). Every morning he would travel to the job site and watch the workers build the foundation of the house- this puzzled me. In response, my friend said, "I know if the builder screws up the foundation the house will never be right. So I feel it is important for me to be there through every step of the foundation."
I further pondered as to how this applies to the field of Product Management. Often, the Product Manager is asked to take on the position of Product Owner or Product Manager because of their knowledge of the product. Sometimes, as in my case, because they have strong project management skills and can deliver technology to their clients on task and on time. It is often this lack of clarity to the position description and the supporting competencies required to move the appropriate 'levers' on the job that make us Product Janitors rather than Product Managers. Additionally, we often do not take on the third verb in the sentence EVALUATE as the product lifecycle changes for a product.
As products mature, sometimes we leave those start up superstars behind- nursing a growth product into maturity. And to the opposite, sometimes we don't recognize that the competencies that are needed to bring a product to market might not be possessed or at least might not be as strong in a product manager that is successfully managing a mature product line. For example, during a conversation I had at SHRM with a peer in the industry who was struggling to find the right resource to join her team, I challenged her to look within her own team. One of the offerings that they manage is in a growth product cycle verses others that she is hiring for which are in 'introductory' and 'fix' cycles. Why not move the superstar from growth to introductory; they were the catalyst for getting the Growth product through it's introduction period.
All of this thought brought me to the same questions for our profession- How often do we include the step of evaluating the competencies required for the job at 'that' particular point in the product AND market life cycle for the product managers we manage? Are we thinking about these like a solar system with products orbiting their markets and the tilt and rotation of the product life cycle exhibiting gravitational pull on the required competencies of the job? Do we actively account for and apply individual strengths against specific market needs for that time?
Subscribe to:
Posts (Atom)