Archives for October 2015

It seems that lately Agile (and Scrum in particular) have become the latest targets of non-stop complaints and criticism in the Product Management and Development worlds. I’ve read articles that talk about how “Agile is destroying the business” or where “Scrum is a career-limiting methodology that only creates generalists.” Neither of these are necessary conclusions from the data provided, nor are they necessarily a reflection of weaknesses of the Agile principles or of a specific methodology — more often than not, they’re a reflection of a certain culture or work environment that itself is fighting against the fundamental tenets of Agile and Scrum.

If you’re one of those people for whom either Agile or Scrum doesn’t seem to be working, here are some hard questions to ask yourself and your organization — “The fault…is not in our stars. It is ourselves…”

To be subjective, or to be objective, that is the question, and the best product managers already know the correct answer is “both.”

As product managers, we constantly face situations where the unknowns outnumber the knowns that we can rely on. It’s our job to drive out that uncertainty and ensure that both people and efforts align toward a common objective. Sometimes these discussions flow smoothly, as the goalposts that we set can be quickly and easily agreed upon – things like providing a quality user experience, solving valuable problems for our customers and our market, and introducing competitively differentiating capabilities are hardly controversial.

What does become controversial, however, is how we go about those things as a team, what exactly we should do, and who we should be building those products for. And when those discussions come up, it’s inevitable that everyone at the table will have different ideas about what those things are – and, unfortunately, the vast majority of those ideas will not be based on hard data. Hence why we, as Product Managers, need to make it our business to ensure that we’re bringing data to the table as we represent and advocate for our customers and our market in those conversations; to do so, we must provide stakeholders with the right mix of qualitative insight and quantitative data that will not only help win them over to our preferred course of action, but also minimize the risk of later changes of course.

I’ve noticed a decent amount of discussion lately on LinkedIn and other areas regarding the difference between Product Owners and Product Managers when it comes to Agile development practices. The confusion largely stems from the fact that textbook Scrum has a very specific definition of the Product Owner role, but has nothing at all to say about the Product Management role, which is entirely understandable, since Scrum concerns itself with the execution of product development by engineers and not with the ideation of product by the business side of the equation. This simply means that we can’t just take textbook Scrum and expect that it provides us with a comprehensive set of guidelines for how to run our business, because it was never conceived of as such.