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.
Prioritization is More Art Than Science
A very common challenge faced by Product Managers of all experience levels is understanding and implementing some form of repeatable process around prioritization. Some people take a very light approach, making decisions based on their own experience, data, and beliefs about the direction of the product. Others take a much more rigorous approach, applying scorecards and “objective” measures across a plethora of different possible metrics. I’m here to tell you, there’s nothing wrong with either of those approaches, but it’s also become clear to me in my years as a Product Manager that there’s no “silver bullet” to ensure that your prioritization decisions will be right more often than they’re wrong, and placing too much value in systems and scores often just results in a false sense of security that the “process” was right, when digging in you’ll find that those “objective scores” are nothing more than a system to be gamed. There are, however, three things that I think every prioritization system needs to take into account. So, without further ado, let’s discuss value, difficulty, and instinct…
Data v. Opinion: The Ultimate Battle
“Agile” is More Than a Buzzword: Three Truths Behind the Manifesto
It’s become rather commonplace lately for people to dismiss “Agile” out of hand as an industry buzzword with no meaning or substance to it. And in some ways, the term has earned that reputation — mostly from people who use it regularly without really knowing what it means or how it changes an organization — or more accurately, how an organization must change to be Agile. And while there will always be those who abuse such terms, mostly out of ignorance rather than malice, it’s important to remember that “Agile” is a word with meaning, substance, and history behind it. There’s a good reason why the Agile Manifesto begins with the words, “We are uncovering better ways of developing software by doing it and helping others do it.” These words ring true because they aren’t an end in and of themselves, they don’t attempt to prescribe or proscribe any specific approach, and they accept that there is fluidity in what we do and how we do it. Truly embracing “Agile” requires that we hold certain truths to be universal…
Five Differences Between a Junior PM and a Senior PM
Even though it’s been around as a formal role in software organizations for nearly 20 years (or more, depending on who you talk to), Product Management still struggles with a lot of definition problems — what is the role, how do we grow, when do we get promoted and to where, etc. One of the common issues that we run into are companies who don’t have any form of structure around their product teams, who struggle to define the actual differences between their “associate”, “general”, and “senior” Product Managers without simply resorting to the amount of time they’ve been in the role. As anyone with extensive experience in the profession can tell you, how long you’ve been doing the job has little to no bearing on your actual ability to do the job — you can work for 10 years practicing all sorts of bad behaviors that have resulted in zero growth as a Product Manager. Similarly, you can go deep and hard for 2-3 years and come out the other side as a true product leader and influencer, capable of taking on much more advanced products and projects than your companions. Here are a few of the common differences that I think draw dividing lines between a “junior” Product Manager and a “senior” Product Manager, where age is not the most important factor…
Assumptions, Risks, and Constraints – The Keys to Success
One of the most important parts of being a Product Manager is making sure that your stakeholders and developers understand not only what you’re trying to do, but the surrounding circumstances in which you’re trying to do it. Often, this is a matter of discussing and managing scope; at other times, it’s making sure that people understand the schedule and resources working on the improvement; and at still other times, it’s ensuring that what comes out at the end of an iteration is what everyone wanted at the beginning of the iteration. But there’s a larger set of considerations that are of key importance to aligning your teams on — because they significantly impact the overall success of what we’re trying to do. All too often we ignore these three components to our peril, and when we do there’s an even chance that they’ll come back to bite us in the ass…
You’re Already a Product Manager…
One of the most common questions I encounter in my work as The Clever PM is a simple one — “How do I become a Product Manager?” And, while the specifics depend greatly on the individual person, where they’re at in their careers, and what companies they want to break into, one of the things that I’m always telling people is that it’s likely that they already have the skills that they need. The best and worst part about being a Product Manager is that the role is often a “jack of all trades” role — filling in where there are gaps in the organization, ranging from the strongly strategic to the severely tactical. No matter where you sit in your organization, chances are good that with the right perspective and point of view, you can likely position the things you do to fit some definition of “Product Manager”.
[Read more…]
- 1
- 2
- 3
- …
- 5
- Next Page »