In Search Of

Product Management is something that should be easy to understand. The highest level goals of product management should be easy to articulate.

1) build a valuable product
2) maintain the value of a product relative to its customer community
3) manage the investment in the product, to ensure the best possible return

I believe that these goals are universal to product management across all domains, and all situations. I don't know that I can add anything that is not a derivative of one of these goals. There are many product domains, and many situations. The domain that I am most familiar with is software, and even within that domain, there are many situations:

• commissioned custom built software
• shrink-wrap software
• vendor vertical market software
• vendor highly configurable software frameworks
• software as a service
• open source software

These situations are different primarily because of different relationships between the customer community and the product manager or the customer community and value. In all cases, the product manager needs to understand who the customer community is, and what is relationship with them is based on. He needs to develop deep relationships in that community so that he can understand and articulate what that community values and so that he can discern changes in what the community values over time. He also needs to understand the flow of investment ($$$) into the product, and how that relates (or does not) to the customer community.

The product manager must be an advocate for or champion of the product, helping the customer community understand how to get value out of the product. Sometimes this is education, sometimes it is marketing, sometimes it is solution consulting services.

The product manager needs to understand and direct the "delivery" organization by communicating the sequence and pace of value delivery. Explaining the value of each deliverable to the delivery team, expressing the customer's perspective.

The product manager also needs to understand the technical risk arising from the delivery process, and communicate that to the customer community, effectively managing their expectations of delivery.

Overall, the product manager is the interface between the customer community regardless of how that is organized and the delivery organization. The product manager must adapt to the organization of the customer community, and the management processes in use by the delivery organization. She does not have control over either one, and so to be successful, she must learn enough about the delivery process to be effective, and she must build relationships and trust within the customer community as well.

Sometimes it would just be easier, and better for all parties if we were honest and just "Fired their sorry asses!" It would be easier for management, because there is less corporate drama around firing and hiring than around a reorg, or implementing alternative staffing models, and RIF's are either good (when the economy is going down) or bad (when it is going up), from a market analysts perspective - but firing ineffective employees and hiring new talent is always good.

Read the rest of this post »

I work in an environment that is somewhat dominated by a project governance mentality. What does this mean? What it means to me is this - that our diligence is focused on spending rather than on asset creation. Why is this significant? Because it changes how we focus the decisions in the process of software development.

Read the rest of this post »

Recently I have had to look back on my career and remind myself what I have done. I am leading a challenging project, and at times it feels like I have team members and customers projecting their expectations for how the work will be executed. Sometimes amid the cacophony of voices, I have to remind myself that I am capable of bringing the team to consensus around strategic decisions.

Read the rest of this post »

Product Portfolio
If you want to manage a portfolio of software products, it is necessary to understand the organizational goals that are met by those software products. The product portfolio is a vehicle for understanding the ongoing investment in development or deployment of software assets. It requires an ability to measure the value of software assets separate from their cost (rarely done in industry today), and an ability to measure the cost of ongoing support and maintenance of software product.

Read the rest of this post »

OH: (on twitter)
"Convinced. Everyone that says "agile doesn't work" or even "agile doesn't work for us" just doesn't know what it means to be agile."
 

I read this on Twitter over the weekend (12/17/11). It really got me fired up. Mind you, I am an avid agilist. The point is, that some situations are not particularly suited to derive benefit from agile practices.

Read the rest of this post »

Take anything. Any activity. Any Practice. Any Standard. Any Method. Ask the question "why?" - with fresh eyes, take a long hard look at why we are doing it. Now, ask yourself if the "why" is being accomplished. Ask yourself if you even know how to measure the benefits you originally sought. Ask yourself if all the acitivities, practices, standards, methods and other things we do make sense together.

Dogma is powerful. Questioning is more powerful. Dogma is required like training wheels. We need something to help us get up and rolling. Once we are rolling we need to get rid of the training wheels so we can go fast.

Read the rest of this post »

One thing that I have noticed at the beginning of a project is that there almost always appears to be confusion. Confusion about mission. Confusion about terminology. Confusion about what is important. Confusion about roles and responsiblilities. It feels bad, it looks bad and it smells bad.

It's like what drag racers do before a run. They used to pour bleach on the tires and spin the drive wheels, creating massive amounts of foul smelling smoke. The purpose of this exercise is to heat up the rubber, so on the actual run, the tire are already super sticky and get traction and the car launches like a "hole shot" down the strip. There is a science to this, but it feels, looks and smells bad.

Read the rest of this post »

Why is it that the customer in corporate software projects seems to want to pack the scope of every project with capabilities of dubious value, in the same way that our congressional leaders try to pack important bills with "pork"? Why do organizational leaders try to take a well funded project or initiative and use it as a means of funding their personal management agenda? Because like congress, if they can construe their agenda as essential to the completion of some important project - they bring the business value (pork) home to their department. They can use the project as a vehicle to accomplish things that ensure that they get their bonus. These leaders act as though their incentives are more important than the overall health of the corporation - just like congressmen act as if their re-election is more important than the overall health of the nation.

Read the rest of this post »

Real World developers prefer:

• Getting things done over sitting in meetings, but understand that communication is important.
• Working code over extensive documentation, but understand that government regulations, and product sustainability require a rational approach to documentation.
• Requirements that describe business value over requirements that prescribe implementation vectors, but understand that the customer often can only express requirements in concrete examples based on his or her experience.
• Practices that work HERE over elaborate methodologies that were designed elsewhere, but understand that some established repeatable practice is beneficial.

Read the rest of this post »