Archives for March 2015

Product Managers sit in a very unique position in most companies — they have their hands in almost every cookie jar in the whole organization. From Sales to Marketing to Services to Development to Finance, at some point the Product Manager will directly impact each and every single function within the organization (assuming it’s being done right). While many people take this as an indication of the classic belief that a “jack of all trades” must be a “master of none,” the “trade” of a Product Manager is leading through influence, and in building and trading in social capital.

By virtue of these contacts, however, there’s another opportunity that Product Managers often have which is not generally available to those in tightly siloed, functional positions. Because Product Managers become masters of communication and translation, they also learn a little bit about a lot of things. And, in doing so, they become not only a hub around which the product itself turns, but also a valuable resource for teams to learn more about the product, the process, and other teams’ interests. All it takes is a little personal interest and willing participant, and suddenly you’re a mentor!

There’s a classic aphorism used in discussions about listening and communication that’s important for every Product Manager to think about when engaging with customers, prospects, or even stakeholders and developers:

We have two ears and one mouth, so we should listen twice as much as we speak.

I know, it sounds pithy and trite, but there’s a lot of truth to be found in that one sentence, and a lot of benefit that can come from engaging in active listening with those around you, both in life and in work.

Of all the things that I’ve learned over the past 15 years of being a Product Manager, the one thing that sticks with me wherever I go, whatever I’m doing, is the simple fact that success is something that is enabled (or challenged) by the culture of the organization that is trying to achieve it. It doesn’t matter how well you know the market; it doesn’t matter how tightly defined your strategic goals are; it doesn’t matter how much talent you have in the organization to execute with — if the culture of the company isn’t one that empowers, entrusts, and instills responsibility in the people and the product to be successful, at best you’re wind up treading water…at worst you’ll wind up being bought or sold by a competitor.

The good news is that the one consistent aspect of Product Management across nearly all organizations allows us to be the focal point for pivoting the company one way or the other in this regard — the fact that we lead through influence and not position provides us with a unique ability (and perspective) to help the company swing back toward a culture of success when it’s gone too far the other direction. Doing so requires establishing a culture of empowerment, trust, opportunity, and responsibility — the building blocks to a culture of success.

One of the primary predictors of successful Product Managers that I’ve seen in my time is the amount of curiosity that they are willing to express in their work and in their lives. This makes a lot of sense when you think about it, given that Product Management is all about having a broad swath of experience and ability from which to pull in their daily lives. A well-rounded person is nearly always more likely to be a more effective Product Manager than someone who strictly focuses on one or two disciplines.

Here are some of the reasons you, as a Product Manager, should be as curious as possible…

The folks at Pragmatic Marketing have a popular saying in their training and materials — “Your opinion, while interesting, is irrelevant.” For the most part, they’re absolutely right — the point that they’re making is that, while you as a Product Manager may have knowledge of the market and of the users, you yourself are not the market, nor are you your users. Rather, you have an opinion that’s just as valid as any other opinion in your company — no better and no worse. The assertion is that your decisions need to be based on objective data, nor subjective feelings — on research and testing and reports that you can glean from the actual usage of your product or your actual users.

The problem is, while that’s a good rule of thumb, and when such data is available, it’s absolutely necessary when making decisions. But we also know, as Product Managers, that such data isn’t always available, or it’s very costly to obtain, or you have to make a decision on the fly.

Earlier this week, I discussed the common misunderstandings related to the first two statements made in the Agile Manifesto — Individuals and Interactions over Processes and Tools, and Working Software over Comprehensive Documentation. In that discussion, I focused on how important it is to remember that the Agile Manifesto itself was written largely in response to traditional “Waterfall” methods of product design and development. There was never any intent on the part of those who created the Manifesto to shift the focus entirely to the “left side” of the spectrum — but rather to propose a spectrum that was more responsive to change and that could accelerate the delivery of value to interested stakeholders. While these original concepts have brought forth many different specific approaches, the fundamental purpose of the Manifesto remains important in understanding when, where, and how to implement such practices, and why you should do so.

One of the issues that Product Managers commonly face when engaging with teams who claim to be, or who want to be, “Agile” is that most people have never really take the time to actually research the origins of the Agile movement, the principles upon which it is based, or even the histories of the specific practices that have grown from these principles. All too often, teams and companies begin their way down a transition to Agile practices as blindly as a bat fluttering out of its cave into the sunlight.

The fact is, there is a long and storied history to be found, and one of the best places to start is by reviewing the Agile Manifesto, which in many ways was the first coordinated effort to coalesce a variety of different approaches under a single set of guiding principles. After a few online conversations, I thought it might be useful to present a few common misinterpretations of the Agile principles and explain why they’re incorrect. To start with today, I’m going to dig on on the first two statements in the Agile Manifesto: