A common theme in online discussions and forums around Product Management lies in how to level up our skills and be a better Product Manager. While there are a lot of different options available, just as there are as many different aspects of Product Management to focus on, there are some very specific areas that any given Product Manager can assess themselves in and decide what next steps they want to take to become a better Product Manager.
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.
There’s a term that gets floated around the Agile world by what I like to call the “textbook Scrummers” that really bugs the crap out of me, so much that I decided to write an article about the concept, and why I think it’s a wrong-headed, anti-agile concept. The concept is known as “ScrumBut” (a shortened form of “We do Scrum, but…”) and as the folks at Scrum.org describe it:
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum.
In theory, this concept sounds harmless — after all, Scrum is a very specific methodology, with specific ceremonies and deliverables that are designed to achieve specific goals and specific benefits. The problem lies in the fact that these methods are not the only way to achieve those goals, though the companies who provide Scrum training would be loathe to admit it. Here are a few reasons why “ScrumBut” really isn’t as bad as those “textbook Scrummers” might have you believe…
One of the common struggles that Product Managers are faced with is figuring out how to be “agile” while still managing to a vision or strategy that’s been established by the Executives or Board. The important thing to remember is that strategy and agility are not in conflict with one another — if a strategy is properly formed, it’s a long-term view of where you’re going, and not specific enough to tie your hands when approaching the execution side of things. But that doesn’t mean that there aren’t tensions to be found in such a situation. Here are some thoughts on managing agility while executing against long-term plans…
There’s always a fine balance to be found between making sure that your product is as buttoned-up as possible when it ships and the small (sometimes large) sacrifices that we have to ask our technical teams to make in order to just get the damn thing out the door. Within this gap lies the dreaded concept of “technical debt” – the ever-growing list of things that you know you probably shouldn’t have done or that you should have done, but that have way to the reality of getting product out to market. The good news? It’s not always bad. The bad news? Play too fast and loose with it and it will come back to bite you in the ass.
I’ve talked before about the dangers of a “cargo cult” mentality when it comes to Agile practices, but in this instance I’m going to take a Devil’s Advocate position, at least it will appear that way. All too often, people and companies start their Agile transitions with training about the “theory” of Agile — what it means, how it should work, what glorious and wonderful benefits are, and to attempt to indoctrinate people into concepts that may be entirely foreign to them and how they’ve done their work in the past. The problem is, nobody really cares about theory — and all too often the theoretical underpinnings are lost as soon as people get back to their desk and start their next day of work. Here, however, I’m going to propose a plan to implement Agile practices without the theory, and without creating a “cargo cult” mentality where you’re just going through the motions without understanding why…
For the second installment of my “10 Questions With…” I reached out to one of my mentors in the PM/Consulting space, Rich Mironov. I met Rich many years ago at ProductCamp Seattle, where he was giving a presentation about the struggles and challenges of the role that really spoke deeply to me and where I was in my career. Over the years, when he’s passed through town I’ve tried to maintain a connection, bouncing ideas off of him and mining his depths of experience for pearls of wisdom to help me grow as a Product Manager. I’m happy to present his 10 questions here, and for those of you who don’t know him, here’s a quick bio:
Rich is a 30-year product management veteran based in San Francisco. He’s an unrepentant blogger at www.mironov.com, author of The Art of Product Management, and coach/consultant to product management teams and startup executives. On occasion, he parachutes into software companies as interim VP Products. He thinks a lot about the strategic and organizational challenges of running product management teams.