Sometimes an idea just strikes me out of the blue and sounds interesting enough to sit down and write a little bit about. This is one of those posts, spurred on by a discussion I had today with a newly-hired Product Manager with almost as much experience as me. As we were talking about our past experiences, where the current company is at, and how we can work together to improve some of the practices and procedures throughout the organization, I started to think about all the different things it is that we actually do as Product Managers, and all of the hats that I’ve worn in the past. These are some thoughts on a few of these hats…
Why Does Agility Matter?
We tend to take the fact that agility is important as a given, when the reality is that not everyone in the business world has reached the same conclusion. Thus, it’s important sometimes to take a step back and examine why agility actually matters, so that when we’re faced with people who aren’t as convinced as we are, we have salient points that we can raise to help them understand the value that agility brings with it. Here are a few important things to remember when thinking about why agility is important in our jobs…
10 Questions: Suzanne Abate
One of the benefits of teaching with General Assembly has been to build my network of talented, knowledgeable, and experienced Product Managers, not just in the Seattle area, but around the country and the world. One of my more recent connections was with Suzanne Abate, an LA-based product management coach who caught my eye with her latest project, 100 Product Managers — wherein she’s collecting the stories, advice, and experience of 100 product managers of all shapes, sizes, and backgrounds. Here’s what she says about herself:
Suzanne Abate is a seasoned product coach who has developed hundreds of digital products for clients like Jaguar Land Rover, Best Buy, and Warner Brothers, and helped dozens of startups go from idea to execution. She is the Co-Founder of The Development Factory, an LA-based product consultancy, and Chief Product Officer of 100 Product Managers, a free online resource and weekly podcast for new and aspiring product managers. Suzanne has been teaching part-time with General Assembly since 2015, bringing product management training and classroom fun to new students and enterprise teams alike.
And, without further ado…Suzanne’s responses to my 10 questions!
Stakeholders: Overcoming Passive Resistance
A recurring challenge that many Product Managers face is coping with stakeholders who attempt to block our efforts, either covertly or overtly. Sometimes these situations arise due to simple miscommunication, but other times they’re power plays, the results of internal politics, or even caused by grudges held from previous slights — real or imagined. To excel in Product Management, one must not only deal with these blockades as they arise, but you need to predict when, where, and how they’re likely to come up so that you can head them off before they even become an issue. To do that, though, we have to try to figure out what the most common reasons are for stakeholders to actively or passively interfere — and that’s what the Clever PM is here to share with you. In this first installment I’m going to focus on overcoming passive resistance, and we’ll address more active resistance in a future piece.
Why “Scrumbut” Shouldn’t Be a Bad Word
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…
- « Previous Page
- 1
- 2
- 3
- 4
- 5
- 6
- …
- 13
- Next Page »