A common question posed to Product Managers in organizations interested in or transitioning into Agile is, “How do we know that we’re Agile?” Because agility is a cultural value, there’s no pre-determined checklist of things that one can step through and certify your company as 100% Organic Agile. There are, however, indicators that we look at to determine whether or not the company, a team, or even an individual, is thinking and acting in an Agile way. Here are a few key indicators that you can use to weigh your assessment of how agile you, your team, or your company are…
There are a lot of potential pitfalls that threaten our success as Product Manager — but by far the worst, in my opinion, is falling too much in love with your own ideas, whether those are problems, solutions, or even assumptions about the market and our customers. While I think they take it a bit to the extreme, Pragmatic Marketing does have a point when they say, “Your opinions, while interesting, are irrelevant.” It’s in our nature to make assumptions and inferences from what we see going on around us — to create plans in the face of uncertainty and to identify potential opportunities that others are missing. But we do so at the very real danger of drinking our own product’s Kool-Aid and thinking that we have the one true solution and the one truth in the market. But in reality, that’s never the truth, and we need to check ourselves every single day against this danger.
Of all of the teams that Product Managers must deal with on a regular basis, I really can’t think of any that have a worse reputation amongst our kin than Sales teams. Common tropes that I hear when talking about Sales teams with other Product Managers include things like “they don’t understand the product” or “they make commitments we can’t follow up on” or even “they just lie to make their commission.” And while each of these statements has a kernel of truth buried inside it, much of the responsibility for these failures on the part of the Sales team can be traced back or shared by the Product team itself. I personally believe that it’s absolutely essential for a successful Product Manager to have a strong and productive working relationship with their Sales team, and without that it’s nearly impossible to provide the kind of holistic guidance that separates a “good” Product Manager from a “great” one.
This is the first in what I hope to be a series of PM 101 posts, wherein I focus on some fundamentals of Product Management. For this first article, I’ve chosen a topic that’s near and dear to my heart, as well as one that’s been raised several times during my teaching sessions at General Assembly — how should Product Managers work with Designers. Now, to clarify I’m using “Designer” as a catch-all term to include everyone involved in the User Experience, User Interface, and Human Interactions side of the product equation — basically, the people who are trained to define how the user interacts with our product in order to achieve their goals. With that established, let’s explore some common issues and potential paths to success…
A very common topic of discussion amongst Product Managers in general, and Agile practitioners in particular, involves the comparison of different forms of process and project management. By far the most prominent and popular of these are Kanban and Scrum. And, much to my own personal dismay, often these discussions wind up devolving into some form of “religious war” between fanatical fundamentalists on either side — insisting simply and without substance that their way is the best way.
The simple fact is that one is not necessarily better than the other — when, how, and where you use either of these approaches depends greatly on what problems you’re trying to solve, what kind of culture you have or want to have, and how the people you have doing the actual work want to manage themselves. To say, in broad strokes, that either Kanban or Scrum is objectively “better” than the other misses the point entirely. Both are equally good and equally bad, depending on the circumstances.
When we say that Product Managers “lead through influence,” most people think of building rapport with the execution teams to ensure that you have the personal and professional leverage required to get them to do something without challenging things for their own reasons. But that’s really only a small piece of the overall leadership puzzle, and in many ways it’s also the easiest part — assuming that you know something about the market, that you know something about the users, and that you know something about the problems they’re facing, most of the “management” of delivery teams will come rather easily over time.
Where things get trickier, and where many of the career land mines lay for the unwary Product Manager, are those who sit above you — those in leadership positions within the organization. They often have (or claim to have) more product knowledge than you, more market knowledge than you, more customer knowledge than you, and more direct authoritative power than you. Knowing and understanding how to build your own relationships with your leadership team is an essential skill for the successful Product Manager, and here are a few tips that you can use to ensure that you’re growing your influence among the leadership team and not ceding your limited authority to that team.
Awhile back, I got into a rather heated discussion with someone who was a firm believer in “textbook Scrum” and insisted that because the Product Owner is part of the Scrum Team (according to the biblical Scrum Guide) that they simply must be involved in every retrospective with the team, no matter what. This discussion reminded me of the trap that many people fall into when they shift from traditional, structured, waterfall or stage/gate approaches into Agile development practices — they assume that there’s one process to rule them all, one way to do things, and anyone who does anything different is a heretic and deserves to be burned at the stake for even suggesting that sometimes it might be better for the team as a whole if the Product Owner isn’t invited to a particular retrospective.
Now, don’t get me wrong — I think that Product Owners, in general, should be very involved with every aspect of their teams’ work — from stand-ups to demos to retros, and everything else in between. I think that the standard practice should be that the Product Owner is invited to the retrospective as an observer and occasional active participant. But I do not believe that anything in the Scrum Guide or any other alleged “definition” of the right way to do things should be followed to the detriment of the teams’ success and improvement.
Dogmatic application of any standard process is inherently anti-Agile, for the following reasons…