I’ve always been a big fan of the concept of a “core competency” or “distinctive competency” — the one thing that you, your product, or your company does better than anyone else, and that is difficult to easily replicate. Unfortunately, I find that far too few organizations really understand, at a deep level, what this is — or worse, believe they do but when pressure tested the belief fails to live up to expectations. For some organizations, their core competency is obvious — Amazon has a clear competency in logistics, Zappos has a clear competency in customer service, Google has a clear competency in paid advertising. But for others it’s not so simple. Understanding and being able to articulate your core competencies is essential to success as a Product Manager, and as a product or a company as a whole.
One of the challenges that we commonly run into as Product Managers is the battle between opinions and data. And though it would be nice to pretend that data always wins, and that there’s always truth in Jim Barksdale’s famous quote, “If we have data, let’s look at data. If all we have are opinions, let’s go with mine,” we know from practical experience that this is simply not the case. Let’s talk about some common situations where data bends to opinion… [Read more…]
I’m often asked by in both formal and informal discussions whether I think that Product Managers are stuck in whatever industry they start in, and if not how to break into a new one. And through all the years of having these discussions I’ve determined that the vast majority of the skills that make someone a great Product Manager are entirely portable between companies, products, and industries. You can learn a new product pretty easily, assuming that you have an organization with a good onboarding process. You can learn the market pretty quickly, assuming that the company has some internal experts already there to learn from. And you can learn the politics of the organization by just paying a small iota of attention in your first 30-60 days in the organization. None of those things are directly determinative of success as a Product Manager — what is determinative is the soft skills that you bring along with you, your approaches to problem solving and consensus-building. To that end, here are three key skills that any Product Manager should leverage no matter where they are and no matter where they want to go.
A couple years ago I ran across a blog post by Paul Jackson where he mentioned in passing the idea of a tension between “default ship” cultures in relation to corporations versus startups. For some reason, those two ends of a spectrum have stuck with me ever since, and after struggling with some culture change in my day-to-day job recently, I thought that it was an interesting subject that deserved a little more attention and dissection. Because, even though Paul positioned it as a startup v. corporate culture issue, my feeling is that it goes much deeper than that and is a topic that every Product Manager should be aware of and have their eyes out for — you never know when the “default delay” police will come knocking on your product’s door…
While Product Managers have a great many tools in their belt to use when working internally with stakeholders or externally with customers, there’s one tool that seems to elude so many of us. That tool is silence. When you’re talking with someone and trying to get them to say what’s really on their mind, what’s underlying the things that they’re telling you overtly, silence can be one of your best tools for figuring out what they’re really thinking, what problems they really have, and what’s really motivating them. Silence can be an amazing tool when used properly and in the right circumstance — it essentially forces the other person to fill in the gaps of conversation, and when they do it’s usually with something that comes from the subliminal thought processes rather than the conscious ones. In my constant effort to empower Product Managers everywhere, here are some thoughts on using silence effectively…
A recurring challenge that many Product Managers face is coping with stakeholders who attempt to block our efforts, either covertly or overtly. Sometimes these situations arise due to simple miscommunication, but other times they’re power plays, the results of internal politics, or even caused by grudges held from previous slights — real or imagined. To excel in Product Management, one must not only deal with these blockades as they arise, but you need to predict when, where, and how they’re likely to come up so that you can head them off before they even become an issue. To do that, though, we have to try to figure out what the most common reasons are for stakeholders to actively or passively interfere — and that’s what the Clever PM is here to share with you. In this first installment I’m going to focus on overcoming passive resistance, and we’ll address more active resistance in a future piece.
If you’ve been reading this blog for awhile, you’ve probably noticed that accepting uncertainty is a a recurring theme when it comes to Agile and agility. While it’s never stated outright as a “value” in either the Agile Manifesto or the Twelve Principles of Agile, the concept itself underlies many of the points made in those documents. In my opinion, it’s the primary cultural distinction between organizations that still cling to the old, outdated “waterfall” approaches. Waterfall creates a false sense of security by defining everything possible up-front. Agile accepts that we don’t always know everything, and that new information will not only be discovered, but might alter the path. Here are a few specific reasons why accepting uncertainty is essential for teams to be successful.