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…
Three Steps to Break Into Product Management
Product Management is a hot role in the current market, partly because there are companies realizing the importance of the role, and partly because everyone seems to think that they can do the job. Without opining on either of those driving forces, in my experience there are three key things that any candidate can do to optimize their chances of actually snatching a Product Management role: assessing your skills, positioning your experiences, and pitching yourself effectively. If you can master these three key components, you’ll be best positioned to take your next role in Product Management — no matter where you’re coming from.
The Importance of Knowing What You Don’t Know
As Product Managers, we’re called on a lot to weigh in on questions, considerations, and issues related to our market, our customers, and our products. And we’re often pressured to provide opinions either with or without sufficient data to feel entirely comfortable about drawing conclusions that we know people will rely on and act on — regardless of how carefully we couch our words. It’s par for the course, to some extent, but the more prevalent such requests become, the more we might begin to lose sight of the hazards of engaging in such speculation, and start to leap to our own conclusions without doing our due diligence, even when we do have the time to do so. After all, if we’re truly experts on our market, customers, and products, then we have license to make such gut decisions and skimp on the data collection. WRONG. Part of our job, indeed our necessary role in the organization, is to push for truly data-guided and data-driven decisions — especially when the conclusion isn’t crystal clear (and often when it is). We need to be comfortable stopping the train, or at least slowing it a bit, to do some basic fact-checking before we make decisions that can literally affect the lives and livelihoods of our team members. We owe it to them, and to ourselves, to understand when we’re stepping out of our “known knowns” and into the territory of “known unknowns” (to blithely steal a classic from Donald Rumsfeld).
Don’t be Afraid to Admit You’re Wrong!
One of Amazon’s prized leadership principles is “Be right, a lot.” And we should certainly strive for that as Product Managers, no matter what company we work for, or what product we’re working on. But there’s a corollary to that statement that’s equally important — that you’re not going to be right all the time. And that’s a good thing, believe it or not. Making mistakes is part of the game that we play on a daily basis, and it’s only through making these mistakes that we learn, we grow, and we understand that we’re willing to take the chances needed to truly innovate! If you’re not wrong at least part of the time, you’re either a certifiable genius who outranks even the Elon Musks and Bill Gates of the world — or you’re not truly taking chances.
10 Questions: Greg Hartrell
A few weeks ago, I was perusing Quora as I often do, and came across a really great and insightful answer describing the differences between a “good” and “bad” roadmap by Greg Hartrell. The answer was so good that I couldn’t help but reach out him, and invite him to share some of his insights here on my blog. Here’s a bit about Greg in his own words…
Greg Hartrell is a product leader with a 15 year history helping large teams build high performing software products and businesses. At Google, he heads product for Google Play Books and previously led the creation of their mobile game services. Before that, he was VP of Product Development at Capcom/Beeline, and a product leader for 8 years at Microsoft for Xbox Live/360 and Windows.
Looking Back to Look Forward — Understanding Retrospectives
There’s a tool in the Scrum toolbelt that is so utterly critical to success yet so fundamentally misunderstood by far too many development teams, Scrum Masters, and Product Owners. I’m talking, of course, about the Sprint Retrospective. I’ve seen it time and again, teams that are able to hit all the right notes in their standups, reviews, and planning sessions — but who wind up botching their Retrospectives in such a horrible fashion that they miss out on the single most important part of agile product development, continuous improvement. Certainly, it’s never fun to take time out of our day to look back and discuss what went wrong in the past two weeks — much less try to come up with new things to try on a sprint-by-sprint basis. But it’s the single most important part of the culture that we’re trying to build — the culture of agility, of adjusting, of improving…of change.
- Next Page »