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.
Are You Just Building “Faster Horses”?
Most Product Managers have, at one time or another, heard the apocyphal quote often attributed to Henry Ford, “If I asked my customers what they wanted, they’d have said a faster horse.” And when we hear the line, we laugh because there’s no way that we would do such a thing — the “faster horse” is a fictional thing that we’d never actually spend out time and effort working on. We slap each other on the back, smile, and then go back to our office where all too often we return to working on the “faster horse” that we’ve deluded ourselves into thinking is innovative and fresh. It’s an unfortunate fact that much of what we do really is just delivering faster horses, giving our customers what they say they want (or worse, what sales tells us they say they want), and not digging deep enough to uncover the real need, problem, and desire that’s driving the request.
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…
“Agile” is More Than a Buzzword: Continuous Improvement
There’s more to being Agile than just blindly following the rules and processes of any specific methodology. One of the core components of effective Agile practice is internalizing the concept of continuous improvement. As I’ve touched on in other articles, Agile is a direct descendant of the concepts originating in the lean manufacturing movements of the late 1940s and early 1950s. And the single most important part of this ancestry is the focus on empowering and entrusting the people who do the work with setting their own destiny and with challenging each other to improve their practices on a regular basis.
10 Questions with Stephen Cognetta
One of the best things about my blog and other activities is to meet new and interesting people in the Product Management community. Today I’m happy to present the latest in my 10 Questions series, featuring none other than Stephen Cognetta. His latest project is an ambitious online Product Management interview course that was launched just last month. Stephen’s a really great guy, and a strong voice in Product Management; in his own words…
Stephen Cognetta is the founder and CEO of PMLesson, the best online PM course focused on practice-based learning. Stephen is passionate about mental health and has also founded HackMentalHealth, the world’s largest community of mental health + technology advocates. Stephen is a minimalist and owns under 115 items.
Without further ado, here’s his installment of 10 Questions with the Clever PM!
Accepting Uncertainty is the Key to Agility
I’m often asked what the key to being “agile” really is, and over the years I’ve managed to come up with a clear and concise answer: accepting uncertainty is the key to agility. It is perhaps the single most fundamental culture change that companies must go through when making a true transition to Agile development, and it’s often the biggest stumbling block that prevents them from fully becoming agile. You can see this in so many anti-patterns of Agile development: long-term, specific roadmaps; set dates and forced marches; iterations that are dictated, not created by and for the teams; and so many others. All of these behaviors stem from an organizational inability to accept that there are things that we don’t know about the work we’re trying to do, and that the best way to drive out that uncertainty is not by layering analysis and conjecture over it, but rather accepting it and moving forward, driving it out as we go along.
“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…
- 1
- 2
- 3
- …
- 8
- Next Page »