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.
I find it entertaining when people talk about how Agile and Lean and Kanban are all relatively new, untested, and revolutionary concepts. That’s because they’re none of those things — they’re simply descendants of ideas and concepts that have existed in manufacturing contexts for a half-century or more, just pitched in a different way, at a different time, to a different audience. What we talk about now is just an evolutionary adoption of principles of line production that were brought into being by W. E. Deming and his contemporaries at the end of World War II — the concepts of identifying and reducing waste, focusing on just-in-time stock-keeping, and narrowly focused on doing only the work needed to move a product to the next step of the line. Even the empowerment of individuals and teams owes a great bit of gratitude to the Toyota Production System and it’s focus on granting every line worker the power to stop the entire process if there was something wrong or something to improve upon. I think that it’s past time that we not only acknowledged this history but embraced it — and leveraged the long history of success in that domain over into our own work.
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).
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.
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.