Defining Product Management: Making It Work (Part 5 of 5)

“I want you to look to your left and to your right. You are now a Green Beret. These are your friends, these are your brothers, this is your family. I don’t know anybody who isn’t a Green Beret. I don’t have friends who aren’t Green Berets! You know my mother? She’s not my friend. Why? Because she’s not a Green Beret!” – Instructor to Green Beret Phase IV Candidates

You are in the middle of a warzone. There are bombs going off above your head. There is shells landing in your vicinity. There is small-arms fire erupting in rapid bursts around you. In this situation, would it be the right time to ask any of the following questions:

1. What’s the right position for me to be in?
2. Who’s driving the truck?
3. Who’s providing the coordinates for air cover? Is that my duty today?
4. Where do we go to if we get out of this situation?
5. Where’s the combat medic?
6. What do I do if I’m injured?
7. What am I supposed to be doing?

Obviously, if those questions are being asked, there’s a big problem, and the result isn’t going to be pretty.

Now, thankfully, most of us do not build products or do projects in warzones – it’s far from the equivalent. But there are principles that can be taken from the above example, and from the above quote. Let’s tackle the warzone first.

For a Green Beret in the above situation, he never asks any of those questions. He already knows the answers. He’s been trained to know exactly who he is and what his role is to do. Within that identification of his role and his identity, he has the freedom to do whatever it is necessary to be successful at that. It is his job to do his job to the best of his ability so that the survival of the team is ensured – and the survival of his team ensures the meeting of the larger goals that his team is involved in, whether it’s infiltrating a foreign country or landing supplies in a hostile zone.

There is no limit the depth of creativity and expertise that he can bring to bear as long as he limits himself to not doing someone else’s job. Imagine if the above situation, he and another team member both went to drive the truck. In the ensuing confusion, who gets hurt? Everyone. Likewise, imagine if he decided in that moment, he didn’t feel like driving the truck (his role), who gets hurt? Everyone.

Every role, however small or large, has value when it is executed the way it should be. Every role, however small or large, detracts and destroys value, when it is not executed, or done halfheartedly, or done by the wrong person. In technology organizations in non-technology companies, we assign status and prestige to certain roles, functions, or titles. We give additional weight that is psychological in nature and we assume one thing is ‘better’ than the other.

That attitude is detrimental to the whole because no organization, whether it’s a squad of Green Berets, a professional kitchen, a project team, or a family, works well when everyone changes their role on a whim-basis. We can’t all be leaders, there must be followers. We can’t all be followers, or we will all be lemmings. We can’t switch our role mid-track, because when crisis situations occur, we’re out of position or we’re unsure and ultimately, we’re unable to execute.

However, an organization needs to support the individual value of each contributor, whatever their role is, and that’s where the above quote comes in.  While this discussion has been about the “product management” function, the success of product management is fully intertwined with the success of every single function within IT.

Therefore, product management is not a separate entity from project management or business analysis (or development, QA, infrastructure, production support, PPQ, et al.). Together, all together, they are IT.

When meeting with business users, while it is product management who may do that (or business analysis), it is not one group versus “the rest of IT”. It’s simply IT. When an executive steering committee is held by a project manager, it is not project management directing over, or instead of, “the rest of IT”, it is simply IT. When a project succeeds or fails it is not on the back of one function, it is not due to the abilities or skills or heroics of one function – it is IT.

The overall challenge is to take the above material and determine how practically to detangle the role overlap, to align the product and project lifecycles, and to populate these different functions with the right people resources. The ability to instantiate a valuable product management function that can drive the skillful utilization of technology assets within an organization is solely based on the ability, as a technology organization, to work as one, single, coordinated body.