There’s a rather annoying trend that’s been showing up within both job postings and resumes that’s just crawled under my skin in a way similar to the “ninja” and “rockstar” appellations that developers have adopted. The description that I’m talking about is that of the “full stack” product manager. Now, i totally get where this comes from — in the world of development, there are clear distinctions between developers who focus on the backend systems, the middle tier of integration and business logic, and the actual customer-facing user experience. This is because the skillsets for each of these isn’t necessarily directly transferable to another area — especially with a junior developer who generally excels at one of the three areas, and isn’t quite as competent at the other two. Now, it’s entirely natural for a developer to grow in those lackluster areas over the course of their career, to the point where they might legitimately be called a “full stack” developer. But the same just isn’t true for Product Managers — primarily because we don’t really have anything close to a clearly defined “stack” that we can master. Let’s take a look at what this means for us…

Let’s face it, technical debt is something that every Product Manager has to deal with on a constant basis — whether it’s making snap decisions that unblock your team so that they can keep working, short-cutting an ideal architectural solution because you have time-to-market pressures, or deciding to put off working on bugs found after a story’s been closed. While the common wisdom may be that you should never take on technical debt, the real world intrudes on such a fantasy each and every day, and if we don’t want to wind up in a death march that never sees the light of day, sometimes we have to make the choice to sacrifice some long-term stability in exchange for short-term gains. But how do you determine when there’s too much technical debt, or when the specific item of debt is too much to bear? That’s what we’re going to discuss today…

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”…

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.

Many companies struggle with the challenges of reconciling the need for strategic planning and the desire to execute in an “agile” or Agile fashion. Generally speaking, this is because they’re stuck with the perspective that a “roadmap” must be a set of promises regarding what’s to be delivered, and not merely a strategy that will and must change over time. Being “agile” requires that we accept the unknowns in the world — and what’s more unknown than what the market is going to look like in 2 years? Therein lies the folly in trying to perform traditional roadmap planning and expecting to be able to be “agile” in your execution. But, there are some easy ways to change your perspective on roadmaps and maintain the balance between strategy and execution.

Product Managers sometimes have a bad reputation when it comes to Development teams — and we often unintentionally earn these reputations, by the way that we work with them. There are, however some things that Product Managers can do to build a strong relationship with their development teams — something that is, in fact, essential to the success of the product and your company as a whole. Here are five tips that you can use to ensure that you have the best relationship possible with your development teams:

Several times in my career, I’ve joked to someone or another that my next job title will be “Senior Cat Herder” rather than “Senior Product Manager” — and for good reason. Cats, for all of their cuddly cuteness, are independent problem solvers, much like most of the better developers that I’ve worked with.

Add to the problem the fact that as a Product Manager we typically don’t have any direct authority over our development teams — while we can prioritize the work that they’re charged with doing, and we can (sometimes) influence the way in which they build their solutions to the problems that we’ve stated, we lack the kind of direct management influence that lends itself to “control” over those teams. And, when a Product Manager who doesn’t have such authority oversteps his or her boundaries, and becomes a directive manager of those development and testing teams, it’s almost inevitable that it backfires, amidst charges of “micromanagement” and “you’re not my boss!”

And, ultimately, they’re right – you’re not their boss. You’re their colleague. Like it or not, you’re a fellow cat, not some pack leader of a wolf clan.