It’s become rather commonplace lately for people to dismiss “Agile” out of hand as an industry buzzword with no meaning or substance to it. And in some ways, the term has earned that reputation — mostly from people who use it regularly without really knowing what it means or how it changes an organization — or more accurately, how an organization must change to be Agile. And while there will always be those who abuse such terms, mostly out of ignorance rather than malice, it’s important to remember that “Agile” is a word with meaning, substance, and history behind it. There’s a good reason why the Agile Manifesto begins with the words, “We are uncovering better ways of developing software by doing it and helping others do it.” These words ring true because they aren’t an end in and of themselves, they don’t attempt to prescribe or proscribe any specific approach, and they accept that there is fluidity in what we do and how we do it. Truly embracing “Agile” requires that we hold certain truths to be universal…

A couple years ago I ran across a blog post by Paul Jackson where he mentioned in passing the idea of a tension between “default ship” cultures in relation to corporations versus startups. For some reason, those two ends of a spectrum have stuck with me ever since, and after struggling with some culture change in my day-to-day job recently, I thought that it was an interesting subject that deserved a little more attention and dissection. Because, even though Paul positioned it as a startup v. corporate culture issue, my feeling is that it goes much deeper than that and is a topic that every Product Manager should be aware of and have their eyes out for — you never know when the “default delay” police will come knocking on your product’s door…

There are a lot of different hats we wear as Product Managers, which means that there are a great many opportunities for us to do the right thing, at the right time, for the right people. But the inverse of that is also true — by virtue of wearing so many hats, there are a lot of opportunities for us to do the wrong thing, at the wrong time, for the wrong people. These anti-patterns have a tendency to sneak up on us and bite us when we’re least expecting it, and therefore least prepared for them. But by being aware of them, we can keep our eyes open and try to avoid them if we spy them sneaking up on us in our rear-view mirror. This is far from an exhaustive list, but I’ve compiled five mistakes that Product Managers often make that set us up for almost inevitable failure.

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.

One of the more common challenges that growing companies face is balancing the needs and goals of the company with the needs and goals of its employees. And, unfortunately, all too often decisions are made with a business perspective that don’t take into account the potential effects on the personnel side of the equation. The simple fact is, people will do what we incent them to do and what we reward them for far more often than they will do what we want them to do, if there is any misalignment between the two. This applies across the business — from high-level executives to entry-level employees, and even out to our products — how we position, package, and price our products can often drastically affect how people will perceive and use the product.

While people always seem to nod their heads when you tell them this, it’s rather insane to realize just how often we create competition between these two things. Here are some things to consider when you’re trying to figure out how to get people to do what you want, or why they’re not doing what you expected.

Many people are aware of the famous quote from Peter Drucker, “What gets measured, gets managed.” But what people don’t often consider is that what’s being measured and managed might actually not matter at all at the end of the day. When we measure things that don’t actually drive us to improve, we’re just acting like a cargo cult — going through the motions and expecting something magical to happen that never will. Instead of just picking some popular or standard metric, we should instead make sure that we understand what direction our measurements are going to give us, and what change they’re going to drive in our behavior or in our products. Only by being thoughtful and deliberate in our choices will we find the right metrics to use and rely on in our choices.

Here are a few things to watch out for and to take into account when considering what metrics we want to put into place…

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?