I was called into a meeting with a team here in the office a couple weeks ago because they told me they had a “question” about the estimations that they were doing. As we started talking, it became immediately apparent what the problem was, they were getting into arguments about whether their estimates were “too big!” Apparently, someone had told them that they “couldn’t” have any stories that were above a certain value, or at least that’s how they took the directions they were given. I stopped them for a minute and had a quick discussion about the reasons why we estimate stories, and why it’s incredibly important for the story points to reflect the size the team thinks the work is, regardless of what other people “want” them to do. I walked away to leave them to their work, and was entirely unsurprised when I saw some 20-pointers land on the backlog. Far too many teams suffer from some malady similar to that of this team — they forget why we’re asking them to estimate, so they start to engage in anti-patterns that undercut the very purpose for which estimation exists. In a follow-up conversation with another member of our Product Team, I started to think about how to describe Story Points as something other than “estimates” — and I came up with the idea of them as a “signalling tool”…
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.
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…
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.
Everyone in tech has seen the word, repeated ad nauseum as the “silver bullet” for everything from go-to-market timing to quality to product discovery. But like many terms bandied about by those both within and on the periphery of Product Management, the term “iteration” often comes with connotations or meanings attached to it that aren’t really quite right — almost to the point where the word itself begins to lose its meaning and becomes a “cargo cult” phrase without any real “there” there. In this post, I want to explore what I think are five common myths about iteration that if busted will let us renew the meaning of the word and make it something worthwhile in our profession.
Back in 2015, after about a year into my work on this blog, I put together a reading list that encompassed the fundamental books that I thought every Product Manager should read — and I still stand by the list: A Product Management Reading List. But, that was almost two years ago and a lot of good books have crossed my path between then and now. So, without further ado, I give you an updated list of PM reading materials for you to peruse to your hearts’ content (and, as always, there are no referral codes on these books, and only one was provided to me free of charge — noted in its listing).
One of the ongoing challenges that we face as Product Managers is that we’re primarily charged with predicting customer and user behavior. We’re constantly asked to come up with new ideas, new features, and new designs that we “know” will delight our users, or at the very least satisfy them. But the fact is, predicting human behavior is incredibly difficult — there are many thousands of people who have spent hundreds of years trying to figure out why people do what they do (they’re called psychologists, sociologists, and anthropologists), and we’re still making educated guesses at best. So, what are some of the challenges that we face?